Мне казалось, что .net не хватает простой защищенной автоматической библиотеки обновлений, поэтому я кое-что реализовал и разместил здесь. Прежде чем кто-либо подумает об использовании библиотеки, я увлекся процессом обновления, чтобы получить немного экспертную оценку.
У Дэна Камински есть хороший набор рекомендаций для обновления:
Чтобы преуспеть, пакет обновления должен быть:
Из вашего описания в этом вопросе, кажется, что у вас есть первые 3.
Создав собственный развертыватель в корпоративной среде, вот несколько примеров использования, которые мне нужно было адресовать:
поддержка цифровой подписи
поддержка всех типов прокси. Некоторые крупные корпуса имеют сложные конфигурации прокси (например, с использованием сценариев конфигурации прокси). Вы должны поддержать все эти.
поддержка шифрования. Вероятно, ваши клиенты захотят использовать развернутые файлы на веб-сервере и не хотят управлять какой-либо проверкой подлинности или контролем доступа; но они не хотят, чтобы неавторизованные пользователи загружали двоичные файлы. Простым решением является шифрование двоичных файлов и их развертывание.
поддержка дополнительных дополнительных шагов. Обычно корпоративным клиентам не очень удобно пользоваться автоматически развернутыми инструментами. Они хотят большего контроля. Как правило, позволяя им выполнять настраиваемые этапы (например, антивирусные проверки и т.д.), Поможет
поддержка различных версий программного обеспечения на основе потребительской идентичности. Это часто необходимо в корпоративных средах, когда вы хотите быстро обновить копии конкретного потребителя (исправить ошибку или добавить дополнительную функцию), не запуская весь ваш процесс Q & A (в этой ситуации вы хотите ограничить обновление этого конкретного потребителя)
поддержка ограниченных ситуаций привилегий. Помимо того, что вашим пользователям не хватает доступа администратора к компьютеру, крупные корпорации часто используют специальные инструменты, чтобы ограничить то, что вы можете сделать. Будьте готовы к развертыванию в пользовательской папке (или даже в временной папке), а не в классических "программных файлах".
ваш инструмент должен быть подписан сильным центром сертификации.
Что касается упомянутой вами атаки MITM, ее легко решить с помощью публичной криптографии (как отмечено неизвестно)
Ну, вы можете попытаться предотвратить MITM, если ответ "без обновления версии" также включает отметку времени (& подпишитесь). Затем, если проходит месяц (или независимо от вашей политики) без изменения версии и обновления временной отметки, вы отказываетесь запускать программное обеспечение или всплываете диалоговое окно предупреждения, информирующее пользователя о возможной атаке MITM.
Не решает проблему, что делать, если ваш сервер опускается - предположительно, вы относитесь к нему так же, как к изменению временной метки.
Не значит быть троллем здесь, но вы пытаетесь решить уже решенную проблему. Использование SSL было бы намного лучшим выбором. Это решит все проблемы, перечисленные в вашем вопросе.
Я понимаю, что эта система может быть полезна для людей, которые не могут предоставить сертификат SSL, но каждый, кто может ее получить, должен решить проблему.
Не забывайте: "Сложность - это враг безопасности".
Как дополнение, добавьте контрольную сумму MD5 в загруженный файл, в противном случае, хорошо выглядите:) - справедливый комментарий ниже.
Добавлено:
Единственная дополнительная вещь, которую я вижу здесь, - это вникать в такие вещи, как обфускание кода или архивирование установочного файла и блокировка архива, а затем после его загрузки, разблокировка. Такого рода вещи. Однако я думаю, что то, что вы делали в настоящее время, должно быть 100%.
Единственный раз, когда нужно больше, - это когда приложение является очень сложным комплексом безопасности. Прямо сейчас вы предотвращаете несанкционированное использование DLL и доказательство происхождения, которое для автоматического обновления должно быть достаточно.
Так что я не понимаю, загрузчик проверяет, что манифест - тот, который он ожидает, через подпись, делает ли он то же самое для фактических патчей, которые он устанавливает?
В этом посте есть очень хороший комментарий и решение. Но я полностью согласен с доктором. зло. Вы должны использовать SSL-соединение для обновления, и сертификат должен быть сохранен (построен на) в клиенте. Таким образом, вы можете убедиться, что клиент не примет фальшивый сертификат. Я думаю, что это эффективно иммунизирует клиента от атаки MiTM.
ПРИМЕЧАНИЕ. Если клиент может принять несанкционированный сертификат, атака MiTM может быть успешной, поэтому не предоставляйте эту возможность клиенту.
Изменить: я думаю, что SSL-сертификат может быть сам подписан в этом случае.