Ответ 1

У Дэна Камински есть хороший набор рекомендаций для обновления:

Чтобы преуспеть, пакет обновления должен быть:

• Подпись.
• Подписано вами.
• Подписанный вами, используя правильный EKU (Использование расширенного ключа)
• Подпись с помощью невозвращенной подписи
• Будьте тем же продуктом
• Будь новой версией

Из вашего описания в этом вопросе, кажется, что у вас есть первые 3.

Ответ 2

Создав собственный развертыватель в корпоративной среде, вот несколько примеров использования, которые мне нужно было адресовать:

• поддержка цифровой подписи

• поддержка всех типов прокси. Некоторые крупные корпуса имеют сложные конфигурации прокси (например, с использованием сценариев конфигурации прокси). Вы должны поддержать все эти.

• поддержка шифрования. Вероятно, ваши клиенты захотят использовать развернутые файлы на веб-сервере и не хотят управлять какой-либо проверкой подлинности или контролем доступа; но они не хотят, чтобы неавторизованные пользователи загружали двоичные файлы. Простым решением является шифрование двоичных файлов и их развертывание.

• поддержка дополнительных дополнительных шагов. Обычно корпоративным клиентам не очень удобно пользоваться автоматически развернутыми инструментами. Они хотят большего контроля. Как правило, позволяя им выполнять настраиваемые этапы (например, антивирусные проверки и т.д.), Поможет

• поддержка различных версий программного обеспечения на основе потребительской идентичности. Это часто необходимо в корпоративных средах, когда вы хотите быстро обновить копии конкретного потребителя (исправить ошибку или добавить дополнительную функцию), не запуская весь ваш процесс Q & A (в этой ситуации вы хотите ограничить обновление этого конкретного потребителя)

• поддержка ограниченных ситуаций привилегий. Помимо того, что вашим пользователям не хватает доступа администратора к компьютеру, крупные корпорации часто используют специальные инструменты, чтобы ограничить то, что вы можете сделать. Будьте готовы к развертыванию в пользовательской папке (или даже в временной папке), а не в классических "программных файлах".

• ваш инструмент должен быть подписан сильным центром сертификации.

Что касается упомянутой вами атаки MITM, ее легко решить с помощью публичной криптографии (как отмечено неизвестно)

Ответ 3

Ну, вы можете попытаться предотвратить MITM, если ответ "без обновления версии" также включает отметку времени (& подпишитесь). Затем, если проходит месяц (или независимо от вашей политики) без изменения версии и обновления временной отметки, вы отказываетесь запускать программное обеспечение или всплываете диалоговое окно предупреждения, информирующее пользователя о возможной атаке MITM.

Не решает проблему, что делать, если ваш сервер опускается - предположительно, вы относитесь к нему так же, как к изменению временной метки.

Ответ 4

Не значит быть троллем здесь, но вы пытаетесь решить уже решенную проблему. Использование SSL было бы намного лучшим выбором. Это решит все проблемы, перечисленные в вашем вопросе.

Я понимаю, что эта система может быть полезна для людей, которые не могут предоставить сертификат SSL, но каждый, кто может ее получить, должен решить проблему.

Не забывайте: "Сложность - это враг безопасности".

Ответ 5

Как дополнение, добавьте контрольную сумму MD5 в загруженный файл, в противном случае, хорошо выглядите:) - справедливый комментарий ниже.

Добавлено:

Единственная дополнительная вещь, которую я вижу здесь, - это вникать в такие вещи, как обфускание кода или архивирование установочного файла и блокировка архива, а затем после его загрузки, разблокировка. Такого рода вещи. Однако я думаю, что то, что вы делали в настоящее время, должно быть 100%.

Единственный раз, когда нужно больше, - это когда приложение является очень сложным комплексом безопасности. Прямо сейчас вы предотвращаете несанкционированное использование DLL и доказательство происхождения, которое для автоматического обновления должно быть достаточно.

Ответ 6

Так что я не понимаю, загрузчик проверяет, что манифест - тот, который он ожидает, через подпись, делает ли он то же самое для фактических патчей, которые он устанавливает?

Ответ 7

В этом посте есть очень хороший комментарий и решение. Но я полностью согласен с доктором. зло. Вы должны использовать SSL-соединение для обновления, и сертификат должен быть сохранен (построен на) в клиенте. Таким образом, вы можете убедиться, что клиент не примет фальшивый сертификат. Я думаю, что это эффективно иммунизирует клиента от атаки MiTM.

ПРИМЕЧАНИЕ. Если клиент может принять несанкционированный сертификат, атака MiTM может быть успешной, поэтому не предоставляйте эту возможность клиенту.

Изменить: я думаю, что SSL-сертификат может быть сам подписан в этом случае.