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

4932
Macha

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

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

18

7 ответов на вопрос

15
jcrawfordor

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

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

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

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

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

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

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

  1. Незашифрованные сообщения являются нормой в Интернете, поэтому, если браузеры заставили вас щелкнуть предупреждение для просмотра веб-сайтов, не предлагающих шифрование, вы быстро разозлитесь и отключите предупреждение.
  2. Из-за тяжелых предупреждений для клиентов ненормально видеть самозаверяющий сертификат на производственном веб-сайте. Это устанавливает самосохраняющуюся систему: самоподписанные сертификаты являются подозрительными, потому что они редки, они редки, потому что они подозрительны.
  3. Это циничное звучание меня, но есть компании, которые стоят, чтобы сделать много денег от подписания сертификатов SSL ( кашель Verisign кашля ), поэтому они используют технические документы (термы ИТ означают «долго и нудно рекламу») и другие издания реализовать идею о том, что неподписанные сертификаты опасны.
Без цепочки доверия, которую вы получаете с подписанным сертификатом CA, а не с самоподписанным, невозможно проверить, что сервер, к которому вы подключаетесь, тот, кто говорит, что это так. Самозаверяющие сертификаты опасны в том смысле, что они не предоставляют пользователю никаких средств для проверки того, что передаваемые ими данные достигают пункта назначения, который, как они говорят, есть. Люди начинают учиться искать «https» при выполнении защищенных транзакций, поэтому большое предупреждение о недействительном или самозаверяющем сертификате гарантируется на 100%, поскольку они теряют одно из главных преимуществ SSL. MDMarra 13 лет назад 5
Я бы не сказал «сломан». Я думаю, что дополнение Firefox Certificate Patrol намного ближе к правильной реализации сертификатов и управлению доверием, чем по умолчанию. Тем не менее, по умолчанию лучше, чем полное игнорирование трастовых сетей. Slartibartfast 13 лет назад 0
@MarkM, правда, самоподписанные сертификаты, у вас нет цепочки доверия. Однако невозможно проверить, что передаваемые данные достигают определенного пункта назначения по стандартному протоколу http. По крайней мере, с самозаверяющим https вы знаете, что соединение с сервером зашифровано, что лучше, чем вообще отсутствие шифрования. Люди действительно ищут https сейчас, но на самом деле было бы лучше, если бы все было https, а для сайтов, нуждающихся в дополнительной проверке, пользователи могли бы вместо этого искать сертификат EV и т. Д. Безопасность все равно была бы лучше, если бы по умолчанию использовались самозаверяющие https. nhinkle 13 лет назад 0
@nhinkle - HTTPS имеет дополнительное подслушивание на веб-сервере, в первую очередь, поэтому он никогда не будет стандартом, не говоря уже о нагрузке, которую он будет оказывать на ЦС. Во-вторых, в обычном HTTP, где есть HTTPS, нет никакого значения безопасности, что делает опасными ненадежные конфигурации HTTPS. MDMarra 13 лет назад 0
@MarkM - я чувствую, что аутентификация не должна рассматриваться как основное преимущество SSL. У меня нет данных для резервного копирования, но я думаю, что гораздо больше инцидентов безопасности происходит из-за данных, передаваемых по незашифрованным соединениям (например, инженер безопасности Facebook, у которого украли пароль - они перехватили пароль от сети Wi-Fi) , так как вход в Facebook не зашифрован), чем через MitM или атаки-мошенники, которые относительно намного сложнее реализовать. Как я уже отмечал, акцент на аутентификацию по шифрованию в SSL - именно то, что создает эту ситуацию. jcrawfordor 13 лет назад 3
@jcrawford - Аутентификация является таким же преимуществом SSL, как и безопасная передача данных. Они идут рука об руку в инфраструктуре открытых ключей. Я ни в коем случае не говорю, что незашифрованное соединение более безопасно, чем соединение с самозаверяющим сертификатом, но незашифрованное соединение не претендует на безопасность. SSL-соединение делает. Именно по этой причине ДОЛЖНО отображаться предупреждение, если SSL-соединение не имеет проверяемой цепочки доверия для его проверки. Тот факт, что SSL существует ТОЛЬКО для обеспечения безопасности, означает, что, если есть возможная проблема с ним, единственное, что нужно сделать, это предупредить. MDMarra 13 лет назад 0
@MarkM - хотя определенно есть накладные расходы, что является законным поводом для беспокойства, использование неподписанных сертификатов не окажет никакого влияния на CA, особенно потому, что CA не будет использоваться для самозаверяющего сертификата. Кроме того, для организаций с достаточной мощностью это не проблема - учтите, что Google по умолчанию использует https для gmail и некоторых других служб. Я понимаю вашу точку зрения, что без аутентификации полезность SSL ухудшается. Текущая модель не очень хорошо разработана. Что нам действительно нужно, так это стандартный зашифрованный протокол и аутентифицированный протокол для более безопасного использования. nhinkle 13 лет назад 1
Кроме того, есть доказательства того, что нынешняя модель не так безопасна, как нам хотелось бы верить. Существует так много доверенных ЦС, что решительный злоумышленник может найти ЦС где-нибудь, готовый подписать поддельный сертификат для них. В некоторых ЦС поступали сообщения о неправомерных действиях, и надзор за ними был очень слабым. Хотя это более безопасно, чем отсутствие ЦС, текущая часть аутентификации SSL также нарушена. nhinkle 13 лет назад 0
@nhinkle - Он существует, он называется SSL ... Возможно, вам и @jcrawfordor стоит ознакомиться с PKI и его реализацией X.509. Ни в коем случае не унижать никого из вас, но я чувствую, что между нашими пунктами есть разногласия, основанные на факте, что ни один из вас, кажется, не понимает, как на самом деле работает SSL / TLS. MDMarra 13 лет назад 0
@nhinkle - Прежде всего, веб-браузер должен доверять ЦС, чтобы его сертификат действовал. Я не могу создать случайный центр сертификации и подписать сертификаты, чтобы они были действительными. Я должен показать, что я пользуюсь авторитетом в Mozilla, Microsoft, Apple и т. Д., И они добавляют мой корневой сертификат в список доверенных браузеров. Корневым центрам сертификации удаляют корневой сертификат из списков доверенных лиц, если они обнаруживают, что делают что-то неясное. Это означает, что ВСЕ сертификаты, выданные от них, будут недействительными. Это означает конец этой компании. Доверенный CA мошенническим путем подписывает сертификаты и ставит под угрозу их бизнес, будет крайне редким случаем. MDMarra 13 лет назад 0
@MarkM Вопрос, который поднимает NRHinkle о том, что текущая система небезопасна, является верным. Правда в том, что со стороны поставщиков браузеров недостаточно строгого надзора за ЦС, чтобы гарантировать их разумное поведение, и растет озабоченность по поводу поврежденных ЦС, поскольку Internet Explorer распознает более 100 ЦС, многие из которых очень малы. предприятия или небольшие правительственные учреждения сомнительной стабильности. Существуют доказательства того, что правоохранительные органы уже используют этот факт для создания поддельных сертификатов SSL (http://goo.gl/JotS, http://goo.gl/ynwl). jcrawfordor 13 лет назад 0
Большее значение моей точки зрения, и NRHinkle прямо сказал об этом, заключается в том, что мы должны начать рассматривать шифрование и аутентификацию как отдельные цели и позволять им достигаться по отдельности. Вот основные недостатки системы SSL прямо сейчас: 1) Мы считаем, что шифрование и аутентификация неразрывно связаны - чтобы достичь одного, нужно достичь другого. Предоставление только одного является «подозрительным». 2) Аутентификация должна быть получена от ограниченного числа в первую очередь коммерческих CA. Как правило, центры сертификации либо очень дороги (Verisign и т. Д.), Либо очень сомнительны (NameCheap и т. Д.) jcrawfordor 13 лет назад 4
6
Miro A.

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

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

Достаточно справедливо для меня. dag729 13 лет назад 0
На самом деле, я вспоминаю, что по крайней мере старые версии Netscape Navigator * выдавали * предупреждение для каждого незашифрованного POST. Конечно, все отключили их через пять минут, так что, я думаю, именно поэтому они их вынули ... sleske 13 лет назад 0
3
usermac75

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

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

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

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

3
ufotds

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

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

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

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

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

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

1
Slartibartfast

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

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

Разве не так легко выдать себя за банк, если у вас есть доступ к компьютеру пользователя и изменение его сертификатов? Если компьютер пользователя не изменяется, веб-браузер не сможет изменить URL-адрес веб-страницы, чтобы заявить, что он является банком; и если они получат очень похожий URL, они все равно смогут получить сертификат для этого веб-сайта, и пользователю будет все равно, кем подписана веб-страница, он просто увидит, что это https, и, надеюсь, заметит, что URL-адрес не является URL их банка ... Dmitry 7 лет назад 0
The benefit of SSL is not trust that the website is who you think they are(This is impossible since a 3rd party application can alter your certificates, or the bank can get hacked); but rather trust that the communication between you and whoever the site thinks it is, is only between you two and nobody else can make sense of that communication. Not having a certificate is worse than having a self signed one because it doesn't matter who you're talking to, what matters is that nobody else should be able to intercept what you're saying. Dmitry 7 лет назад 0
Кроме того, как пользователь, я действительно знаю, кто такой Verisign и почему я должен доверять им? Разве их интерес к продаже сертификатов выше, чем то, что владельцы сертификатов несут ответственность за неправомерное использование отправленной им информации? Dmitry 7 лет назад 0
0
David Schwartz

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

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

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

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

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

-1
Cmazay

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

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

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