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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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