Если я просматриваю сайт с неподписанным или самоподписанным сертификатом SSL, мой браузер выдает мне предупреждение. Тем не менее, тот же браузер без проблем позволяет отправлять учетные данные через незащищенные страницы.
Почему самоподписанный сертификат считается хуже, чем отсутствие сертификата?
Есть много людей, которые считают, что эта система сломана.
Вот логика, почему ваш браузер выдаст вам такое тревожное предупреждение, когда сертификат SSL недействителен:
Одной из первоначальных целей проектирования инфраструктуры SSL было обеспечение аутентификации веб-серверов. По сути, если вы заходите на сайт www.bank.com, SSL позволяет отвечающему веб-серверу доказать, что он действительно принадлежит вашему банку. Это мешает самозванцу манипулировать DNS или использовать другой метод для ответа злонамеренного сервера.
"Доверие" к SSL обеспечивается тем, что доверенная третья сторона (такие компании, как VeriSign и Thawte Consulting) подписывают сертификат, указывая на то, что они подтвердили, что он принадлежит тому, кто это говорит (теоретически, посещая ИТ-администратора в человек или другой метод, который создает прямое доверие, хотя свидетельства показывают, что они на самом деле довольно слабы в этом - все, что требуется для получения подписанного сертификата SSL, часто это число 800 и немного актерского мастерства).
Таким образом, если вы подключаетесь к веб-серверу, который предоставляет сертификат SSL, но не подписан доверенной третьей стороной, теоретически это может означать, что вы общаетесь с обманщиком, который притворяется сервером, принадлежащим другой организации ,
На практике самоподписанный сертификат обычно означает, что организация, на которой работает сервер, решила не платить за подписанный сертификат (они могут быть довольно дорогими, в зависимости от того, какие функции вы хотите) или не обладала техническими знаниями для его настройки ( некоторые решения для малого бизнеса предлагают механизм однократного щелчка для самоподписанного сертификата, но получение доверенного сертификата требует дополнительных технических шагов).
Я лично считаю, что эта система сломана, и что общение с сервером, не обеспечивающим шифрование, намного опаснее, чем общение с сервером, предлагающим SSL с самозаверяющим сертификатом. Есть три причины, по которым браузеры не ведут себя так:
Отправка учетных данных от страницы к странице в основном делает 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.
