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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не забывайте: «Сложность — враг безопасности».

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

Добавлен:

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

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

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

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

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

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