Ответ 1
Примечание. Я написал свой первоначальный ответ очень поспешно, но с тех пор это превратилось в довольно популярный вопрос/ответ, поэтому я немного расширил его и уточнил.
Возможности TLS
"SSL" - это имя, которое чаще всего используется для ссылки на этот протокол, но SSL конкретно относится к проприетарному протоколу, разработанному Netscape в середине 90-х годов. "TLS" - это стандарт IETF, основанный на SSL, поэтому я буду использовать TLS в своем ответе. В наши дни все шансы, что почти все ваши безопасные подключения в Интернете действительно используют TLS, а не SSL.
TLS имеет несколько возможностей:
- Шифровать данные вашего уровня приложения. (В вашем случае протокол прикладного уровня - HTTP.)
- Аутентификация сервера клиенту.
- Аутентификация клиента на сервер.
# 1 и # 2 очень распространены. # 3 встречается реже. Кажется, вы фокусируетесь на # 2, поэтому я объясню эту часть.
Аутентификация
Сервер аутентифицируется клиентом с использованием сертификата. Сертификат представляет собой блок данных [1], содержащий информацию о веб-сайте:
- Доменное имя
- Открытый ключ
- Компания, которая ей владеет
- Когда он был выпущен
- Когда он истекает
- Кто его выдал
- Etc.
Вы можете добиться конфиденциальности (№ 1 выше), используя открытый ключ, включенный в сертификат, для шифрования сообщений, которые могут быть дешифрованы только соответствующим закрытым ключом, который должен быть сохранен на этом сервере безопасно. [2] Позвольте назвать эту пару ключей KP1, так что позже мы не смутимся. Вы также можете проверить, совпадает ли имя домена в сертификате с сайтом, который вы посещаете (№ 2 выше).
Но что, если противник может изменять пакеты, отправленные на сервер и с сервера, и что, если этот противник изменил сертификат, который вам был представлен, и вставил свой собственный открытый ключ или изменил любые другие важные детали? Если это произошло, противник может перехватывать и изменять любые сообщения, которые, по вашему мнению, были надежно зашифрованы.
Чтобы предотвратить эту атаку, сертификат криптографически подписан другим закрытым ключом таким образом, что подпись может быть проверена любым, у кого есть соответствующий открытый ключ. Позвольте называть эту пару ключей KP2, чтобы было ясно, что это не те ключи, которые использует сервер.
Органы сертификации
Итак, кто создал KP2? Кто подписал сертификат?
Упрощение упрощения, центр сертификации создает KP2, и они продают услугу с использованием своего закрытого ключа для подписания сертификатов для других организаций. Например, я создаю сертификат, и я плачу компании, такой как Verisign, чтобы подписать ее своим личным ключом. [3] Поскольку никто, кроме Verisign, не имеет доступа к этому закрытому ключу, никто из нас не может подделать эту подпись.
И как я лично получу открытый ключ в KP2, чтобы проверить подпись?
Хорошо, что мы уже видели, что сертификат может содержать открытый ключ, а компьютерные ученые любят рекурсию - так почему бы не поместить открытый ключ KP2 в сертификат и не распространить его таким образом? Сначала это звучит немного сумасшедшим, но на самом деле именно так оно и работает. Продолжая пример Verisign, Verisign выдает сертификат, который содержит информацию о том, кто они, какие типы вещей они могут подписать (другие сертификаты) и их открытый ключ.
Теперь, если у меня есть копия этого сертификата Verisign, я могу использовать это для проверки подписи на сертификате сервера для веб-сайта, который я хочу посетить. Легко, правда?!
Ну, не так быстро. Мне нужно было получить сертификат Verisign откуда-то. Что делать, если кто-то подделывает сертификат Verisign и размещает там свой открытый ключ? Затем они могут подделать подпись на сертификате сервера, и мы вернулись туда, где мы начали: нападение "человек в середине".
Цепочки сертификатов
Продолжая думать рекурсивно, мы могли бы, конечно, ввести третий сертификат и третью пару ключей (KP3) и использовать их для подписи Verisign certifcate. Мы называем это цепочкой сертификатов: каждый сертификат в цепочке используется для проверки следующего сертификата. Надеюсь, вы уже можете видеть, что этот рекурсивный подход - это всего лишь черепахи/сертификаты. Где это останавливается?
Поскольку мы не можем создать бесконечное количество сертификатов, цепочка сертификатов, очевидно, должна остановиться где-то, и это делается путем включения сертификата в цепочку, которая является самозаверяющей.
Я остановлюсь на мгновение, пока вы поднимете кусочки мозговой материи из головы. Самозаверяющие?!
Да, в конце цепочки сертификатов (a.k.a. "root" ) будет сертификат, который использует его собственную пару ключей для подписи. Это устраняет проблему бесконечной рекурсии, но не устраняет проблему аутентификации. Любой может создать самозаверяющий сертификат, который говорит что-нибудь на нем, точно так же, как я могу создать фальшивый диплом Принстона, в котором говорится, что я трижды занимался политикой, теоретической физикой и применял удар ногами, а затем подписывал свое имя внизу.
[несколько неинтересное] решение этой проблемы - это просто выбрать набор самозаверяющих сертификатов, которым вы явно доверяете. Например, я могу сказать: "Я доверяю этому самоподписанному сертификату Verisign".
С этим явным доверием, теперь я могу проверить всю цепочку сертификатов. Независимо от того, сколько сертификатов существует в цепочке, я могу проверить каждую подпись до корня. Когда я доберусь до корня, я могу проверить, является ли этот корневой сертификат тем, которому я явно доверяю. Если это так, то я могу доверять всей цепочке.
Conferred Trust
Аутентификация в TLS использует систему предоставленного доверия. Если я хочу нанять автомеханика, я не верю никакому случайному механику, который я нахожу. Но, может быть, мой друг ручается за конкретного механика. Поскольку я доверяю своему другу, тогда я могу доверять этому механику.
Когда вы покупаете компьютер или загружаете браузер, он поставляется с несколькими сотнями корневых сертификатов, которым он явно доверяет. [4] Компании, которые владеют и управляют этими сертификатами, могут передать это доверие другим организациям, подписав их сертификаты.
Это далеко не идеальная система. Иногда CA может выдавать сертификат ошибочно. В таких случаях сертификат может быть отозван. Отзыв отменен, поскольку выданный сертификат всегда будет криптографически корректным; необходим внеполосный протокол, чтобы узнать, какие ранее действительные сертификаты были отменены. На практике некоторые из этих протоколов не очень безопасны, и многие браузеры не проверяют их в любом случае.
Иногда весь ЦС скомпрометирован. Например, если вы должны были прорваться в Verisign и украсть свой ключ для подписания корня, то вы можете обмануть любой сертификат в мире. Обратите внимание, что это не просто влияет на клиентов Verisign: даже если мой сертификат подписан Thawte (конкурентом Verisign), это не имеет значения. Мой сертификат все еще можно подделать с помощью взломанного ключа подписи из Verisign.
Это не просто теоретическое. Это случилось в дикой природе. DigiNotar был классно взломан и впоследствии обанкротился. Комодо тоже был взломан, но по необъяснимым причинам они остаются в бизнесе по сей день.
Даже когда ЦС не подвергаются прямому риску, в этой системе существуют другие угрозы. Например, правительство использует законное принуждение, чтобы заставить ЦС подписать поддельный сертификат. Ваш работодатель может установить свой собственный сертификат ЦС на компьютере своего сотрудника. В этих различных случаях трафик, который вы ожидаете быть "безопасным", на самом деле полностью видимый/модифицируемый для организации, которая контролирует этот сертификат.
Были предложены некоторые замены, в том числе Convergence, TACK и DANE.
Сноски
[1] Данные сертификата TLS отформатированы в соответствии со стандартом X.509. X.509 основан на ASN.1 ( "Абстрактная синтаксическая нотация №1" ), что означает, что это не формат двоичных данных. Поэтому X.509 должен быть закодирован в двоичном формате. DER и PEM являются двумя наиболее распространенными кодировками, о которых я знаю.
[2] На практике протокол фактически переключается на симметричный шифр, но это деталь, которая не имеет отношения к вашему вопросу.
[3] Предположительно, CA фактически подтверждает, кто вы, прежде чем подписывать свой сертификат. Если они этого не сделали, я мог бы просто создать сертификат для google.com и попросить ЦС подписать его. С этим сертификатом я мог бы "посещать" любое "безопасное" соединение с google.com. Поэтому шаг валидации является очень важным фактором в работе ЦС. К сожалению, не совсем ясно, насколько строго этот процесс проверки находится в сотнях центров сертификации по всему миру.
[4] См. Mozilla список доверенных сертификатов.
