Должны ли сокеты быть защищены - PullRequest
0 голосов
/ 17 ноября 2009

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

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

При таком простом общении необходимо беспокоиться о SSL или других мерах безопасности?

Я пишу сервер обновлений и клиент на C #, и я впервые работаю с Sockets в C #.

Ответы [ 3 ]

2 голосов
/ 17 ноября 2009

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

Когда клиент, который интересуется необходимостью обновления, пытается связаться с www.yourdomain.com, операционная система отправит DNS-запрос на поиск IP-адреса, связанного с этим именем. Клиентский DNS-запрос будет отправлен на любой DNS-сервер, настроенный на этом клиенте. Например, клиентский DNS-сервер может быть их беспроводным маршрутизатором, который, в свою очередь, настроен для связи с DNS-сервером ISP. Сервер провайдера связывается с корневым органом, который направляет запрос на ваш «авторитетный» DNS-сервер. На этом этапе в обычном (не взломанном) сценарии DNS-сервер, с которым клиент сначала установил связь, получает и кэширует ответ. Этот ответ в свою очередь отправляется клиенту, удовлетворяя запрос на сопоставление имени с IP-адресом.

Цель обращения к ближайшему DNS-серверу состоит в том, чтобы позволить этому серверу кэшировать ответ, чтобы последующие поиски с тем же именем возвращались быстро и без генерации трафика вне сети. Этот кеш может быть слабым местом. Если злоумышленник «отравляет» кеш DNS, который будет запрашиваться, он может эффективно «перехватить» ваше сопоставление имени и IP-адреса с точки зрения клиента, использующего этот кеш.

Поддельный сервер может затем сообщить клиенту об «обновлении» до программного обеспечения «троянский конь».

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

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

Приведенный выше ответ оставляет в стороне тот факт, что недавно был обнаружен SSL , уязвимый для атак "человек посередине". Это будет исправлено различными реализациями SSL достаточно скоро, и я действительно упомяну об этом только мимоходом. , Не о чем беспокоиться, и дело в том, что SSL разработан именно для предотвращения атак, описанных мной.

0 голосов
/ 19 ноября 2009

Зависит от вашей цели. Если вам нужно соединение, которое трудно перехватить третьей стороне, то используйте шифрование / SSL. Если вы отправляете информацию, где сетевые ресурсы или ресурсы обработки являются дорогостоящими, вы можете пересмотреть решение об использовании безопасного канала. Если вы отправляете информацию на / с мобильных устройств, методы шифрования / дешифрования [от хорошего к лучшему] являются очень дорогостоящими и замедляют способность вашего приложения обмениваться данными. Кроме того, если вы пытаетесь отправить информацию, которая является достаточно интенсивной или интенсивной (например, видео или аудио + видео потоки) с шифрованием, уменьшите скорость передачи до доли, которую вы могли бы без нее.

0 голосов
/ 19 ноября 2009

Краткий ответ: Я бы определенно использовал здесь SSL - вы хотите быть уверены, что Ответ («да, новая версия - и вот оно») пришел от ВАС, а не от злоумышленника.

Да, и еще один момент: с точки зрения «потраченного времени» SSL в основном бесплатен для разработчика: хотя вам придется заплатить и установить сертификат SSL на своем сервере, клиент - дополнительная работа в основном равна нулю (например, используйте https://, вместо http://).

EDIT: Хотя упоминается в комментариях, нет необходимости тратить много денег на сертификат SSL. Например, GoDaddy продает сертификаты SSL по цене от 9 до 12 долларов (в зависимости от сегодняшнего предложения). Несмотря на то, что вам может показаться представителю Verisign, просто нет веской причины тратить сотни долларов на SSL-сертификат «фирменного знака»: современные браузеры имеют надежный список корневых ЦС, в который входят эти дешевые парни SSL-сертификатов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...