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

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

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

19
задан 10.07.2010, 03:14

5 ответов

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

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

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

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

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


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

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

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

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

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

6
ответ дан 07.12.2019, 10:19

Соединения, которые защищаются https://протокол, обозначаются браузером, который будет "защищен". Например, немного Замка показывают, или части URL отмечены в зеленом.

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

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

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

3
ответ дан 07.12.2019, 10:19

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

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

1
ответ дан 07.12.2019, 10:19

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

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

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

Miro A записал:

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

Это также неправильно, поскольку поля пароля являются специальными тегами HTML, например. К тому же маркировки как "имя пользователя" и "пароль" также предают большую свою чувствительность. Это было бы совершенно выполнимо, чтобы браузеры приняли этот вид информации во внимание.

4
ответ дан 07.12.2019, 10:19

Теги

Похожие вопросы