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