Почему неподписанный сертификат SSL считается хуже, чем сертификат без SSL?


19

Если я просматриваю сайт с неподписанным или самоподписанным сертификатом SSL, мой браузер выдает мне предупреждение. Тем не менее, тот же браузер без проблем разрешает отправку учетных данных по незащищенным страницам.

Почему самоподписанный сертификат считается хуже, чем отсутствие сертификата?

Ответы:


16

Есть много людей, которые считают, что эта система сломана.

Вот логика, почему ваш браузер выдаст вам такое тревожное предупреждение, когда сертификат SSL недействителен:

Одной из первоначальных целей проектирования инфраструктуры SSL было обеспечение аутентификации веб-серверов. По сути, если вы заходите на сайт www.bank.com, SSL позволяет отвечающему веб-серверу доказать, что он действительно принадлежит вашему банку. Это мешает самозванцу манипулировать DNS или использовать другой метод для ответа злонамеренного сервера.

«Доверие» к SSL обеспечивается тем, что доверенная третья сторона (такие компании, как VeriSign и Thawte Consulting) подписывают сертификат, указывая на то, что они подтвердили, что он принадлежит тому, кто это говорит (теоретически, посещая ИТ-администратора в человек или другой метод, который создает прямое доверие, хотя свидетельства показывают, что они на самом деле довольно слабы в этом - все, что требуется для получения подписанного сертификата SSL, часто это число 800 и немного актерского мастерства).

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


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

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

  1. Незашифрованные сообщения являются нормой в Интернете, поэтому, если браузеры заставили вас щелкнуть предупреждение для просмотра веб-сайтов, не предлагающих шифрование, вы быстро разозлитесь и отключите предупреждение.
  2. Из-за страшных предупреждений для клиентов ненормально видеть самозаверяющий сертификат на производственном веб-сайте. Это устанавливает самосохраняющуюся систему: самоподписанные сертификаты являются подозрительными, потому что они редки, они редки, потому что они подозрительны.
  3. Это циничное звучание меня, но есть компании , которые стоят , чтобы сделать много денег от подписания сертификатов SSL ( кашель Verisign от кашля ), поэтому они используют технические описания (ИТ термин , означающие «утомительную рекламу») и другие издания реализовать идею о том, что неподписанные сертификаты опасны.

5
Без цепочки доверия, которую вы получаете с подписанным сертификатом CA, а не с самоподписанным, невозможно проверить, что сервер, к которому вы подключаетесь, тот, кто говорит, что это так. Самозаверяющие сертификаты опасны в том смысле, что они не предоставляют пользователю никаких средств для проверки того, что передаваемые ими данные достигают пункта назначения, который, как они говорят, есть. Люди начинают учиться искать «https» при выполнении защищенных транзакций, поэтому большое предупреждение о недействительном или самозаверяющем сертификате гарантируется на 100%, поскольку они теряют одно из главных преимуществ SSL.
MDMarra

Я бы не сказал «сломан». Я думаю, что дополнение Firefox Certificate Patrol намного ближе к правильной реализации сертификатов и управлению доверием, чем по умолчанию. Тем не менее, по умолчанию лучше, чем полное игнорирование доверенных сетей.
Slartibartfast

4
@MarkM - Мне кажется, что аутентификация не должна рассматриваться как основное преимущество SSL. У меня нет данных для резервного копирования, но я думаю, что гораздо больше инцидентов безопасности происходит из-за данных, передаваемых по незашифрованным соединениям (например, инженер безопасности Facebook, у которого украли пароль - они перехватили пароль от сети Wi-Fi) , поскольку вход в Facebook не зашифрован), чем с помощью MitM или мошеннических атак, которые относительно намного сложнее реализовать. Как я уже отметил, акцент на аутентификацию по шифрованию в SSL - именно то, что создает эту ситуацию.
jcrawfordor

1
@MarkM - хотя определенно есть накладные расходы, что является законным поводом для беспокойства, использование неподписанных сертификатов не окажет никакого влияния на CA, особенно потому, что CA не будет использоваться для самозаверяющего сертификата. Кроме того, для организаций с достаточной мощностью это не проблема - учтите, что Google по умолчанию использует https для gmail и некоторых других служб. Я понимаю вашу точку зрения, что без аутентификации полезность SSL ухудшается. Текущая модель не очень хорошо разработана. Что нам действительно нужно, так это стандартный зашифрованный протокол и протокол с проверкой подлинности для более безопасного использования.
nhinkle

5
Большее значение моей точки зрения, и Н.Р.Хинкл прямо сказал об этом, заключается в том, что нам нужно начать рассматривать шифрование и аутентификацию как отдельные цели и разрешать их достижение отдельно. Вот основные недостатки системы SSL: 1) Мы считаем, что шифрование и аутентификация неразрывно связаны - чтобы достичь одного, нужно достичь другого. Предоставление только одного является «подозрительным». 2) Аутентификация должна быть получена от ограниченного числа в первую очередь коммерческих CA. В общем, CA либо очень дорогие (Verisign и т. Д.), Либо очень сомнительные (NameCheap и т. Д.)
jcrawfordor

6

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

Использование безопасного канала указывает на намерение программиста защитить передачу. В этом случае использование самозаверяющего сертификата является очень правильным решением.


Достаточно справедливо для меня.
dag729

В самом деле, я помню , что по крайней мере старые версии Netscape Navigator сделал всплывающее предупреждение для каждого незашифрованном POST. Конечно, все отключили их через пять минут, так что, я думаю, именно поэтому они
вынули

4

Я не могу комментировать, поэтому я опубликую эту информацию, которая дополняет правильную информацию о пользователе 40350.

Тем не менее, тот же браузер без проблем разрешает отправку учетных данных по незащищенным страницам.

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

Миро А написал (а):

Отправка учетных данных от страницы к странице в основном делает HTTP POST. Нет ничего особенного в отправке учетных данных по сравнению с отправкой, например, условия поиска через POST

Это также неверно, так как поля пароля представляют собой специальные HTML-теги, например. Кроме того, такие ярлыки, как «имя пользователя» и «пароль», также предают много их чувствительности. Для браузеров было бы вполне возможно принять во внимание такую ​​информацию.


3

Соединения, защищенные протоколом https: //, указываются браузером как «защищенные». Например, отображается небольшой значок замка или части URL-адреса помечены зеленым цветом.

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

Если он не использует https: //, пользователь должен знать, что введенные данные не защищены, и сайт, на котором он работает, может быть навязан.

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


1

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

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


Разве не так легко выдать себя за банк, если у вас есть доступ к компьютеру пользователя и изменение его сертификатов? Если компьютер пользователя не изменяется, то веб-браузер не сможет изменить URL-адрес веб-страницы, чтобы заявить, что он является банком; и если они получают очень похожий URL, они все равно могут получить сертификат для этого веб-сайта, и пользователь не будет заботиться о том, кем подписана веб-страница, он просто увидит, что это https, и, надеюсь, заметит, что URL-адрес не является URL их банка ...
Дмитрий

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

Кроме того, как пользователь, я действительно знаю, кто такой Verisign и почему я должен доверять им? Разве их интерес к продаже сертификатов выше, чем то, что владельцы сертификатов несут ответственность за неправильное использование информации, которую вы им отправляете?
Дмитрий

0

Многие веские причины были перечислены. Вот еще один:

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

Вот реалистичный пример. Скажем, я продавец, и у меня есть ссылка «Pay PayPal». Вы нажимаете на это, и я знаю. Я перенаправляю вас в PayPal и позволяю вам получить законную, безопасную страницу PayPal. Если я смотрю вашу сеть, я знаю, что это будет ваш первый запрос от PayPal, и вскоре после этого вы отправите свой пароль. Поэтому я MITM, submitсодержащий ваш адрес электронной почты и пароль, заменяя мой самозаверяющий сертификат для PayPal.

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

И, конечно же, если вы введете httpsвручную, он должен предупредить вас. Потому что вы ожидаете, что это будет безопасно.


-1

Когда человек в середине атаки выполняется на веб-сайте https: //, предупреждение является лишь указанием на что-то неправильное для обычного пользователя. Поэтому это очень важная часть безопасности HTTPS.

Хороший вопрос, почему частично небезопасное шифрование не является возможным примером по HTTP.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.