Автоматическое обновление: это безопасно?

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

Добавлено:

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

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

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

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

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

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

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

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

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

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

Well, you can try to prevent MITM by having the "no version update" response also include a timestamp (& be signed). Then if a month goes by (or whatever your policy is) with no version change and no timestamp update, then you refuse to run the software or pop-up a warning dialog informing the user there might be a MITM attack.

Doesn't solve the problem of what to do if your server goes down - presumably you treat it the same as a no timestamp change.

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

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

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

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

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

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