Как работает SSL?
Где установлен сертификат на клиенте (или в браузере?) и на сервере (или на веб-сервере?)?
Как начинается процесс доверия/шифрования/аутентификации, когда вы вводите URL-адрес в браузер и получаете страницу с сервера?
Как протокол HTTPS распознает сертификат? Почему HTTP не работает с сертификатами, когда это сертификаты, которые выполняют все доверие/шифрование/аутентификацию?
Примечание. Я написал свой первоначальный ответ очень поспешно, но с тех пор это превратилось в довольно популярный вопрос/ответ, поэтому я немного расширил его и уточнил.
"SSL" - это имя, которое чаще всего используется для ссылки на этот протокол, но SSL конкретно относится к проприетарному протоколу, разработанному Netscape в середине 90-х годов. "TLS" - это стандарт IETF, основанный на SSL, поэтому я буду использовать TLS в своем ответе. В наши дни все шансы, что почти все ваши безопасные подключения в Интернете действительно используют TLS, а не SSL.
TLS имеет несколько возможностей:
# 1 и # 2 очень распространены. # 3 встречается реже. Кажется, вы фокусируетесь на # 2, поэтому я объясню эту часть.
Сервер аутентифицируется клиентом с использованием сертификата. Сертификат представляет собой блок данных [1], содержащий информацию о веб-сайте:
Вы можете добиться конфиденциальности (№ 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".
С этим явным доверием, теперь я могу проверить всю цепочку сертификатов. Независимо от того, сколько сертификатов существует в цепочке, я могу проверить каждую подпись до корня. Когда я доберусь до корня, я могу проверить, является ли этот корневой сертификат тем, которому я явно доверяю. Если это так, то я могу доверять всей цепочке.
Аутентификация в 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 список доверенных сертификатов.
HTTPS представляет собой комбинацию HTTP и SSL (Secure Socket Layer), чтобы обеспечить зашифрованную связь между клиентом (браузером) и веб-сервером (приложение размещено здесь).
Почему это необходимо?
HTTPS шифрует данные, которые передаются от браузера к серверу по сети. Таким образом, никто не может обнюхать данные во время передачи.
Как устанавливается соединение HTTPS между браузером и веб-сервером?
Этот поток может быть представлен следующей диаграммой:
Я написал небольшое сообщение в блоге, в котором кратко обсуждается этот процесс. Пожалуйста, не стесняйтесь смотреть.
Небольшой отрывок из этого можно сделать следующим образом:
"Клиент делает запрос на сервер через HTTPS. Сервер отправляет копию своего SSL-сертификата + открытый ключ. После проверки подлинности сервера с его локальным доверенным хранилищем CA клиент генерирует секретный ключ сеанса, шифрует его, используя открытый ключ сервера и отправляет его. Сервер расшифровывает секретный ключ сеанса с помощью его закрытого ключа и отправляет подтверждение клиенту. Установлен защищенный канал.
Mehaase объяснил это подробнее. Я добавлю 2 цента в эту серию. У меня много blogposts, вращающихся вокруг рукопожатия SSL и сертификатов. Хотя большая часть этого связана с веб-сервером IIS, сообщение по-прежнему относится к рукопожатию SSL/TLS в целом. Вот несколько примеров:
Не обрабатывайте СЕРТИФИКАТЫ и SSL как один из тем. Относитесь к ним как к двум различным темам, а затем пытайтесь увидеть, с кем они работают. Это поможет вам ответить на вопрос.
Установление доверия между общими сторонами через хранилище сертификатов
Связь SSL/TLS работает исключительно на основе доверия. Каждый компьютер (клиент/сервер) в Интернете имеет список корневых ЦС и промежуточного ЦС, которые он поддерживает. Они периодически обновляются. Во время установления связи SSL это используется как ссылка для установления доверия. Например, во время установления связи SSL, когда клиент предоставляет сертификат серверу. Сервер попытается определить, присутствует ли CA, выдавший сертификат, в своем списке CA. Когда он не может этого сделать, он заявляет, что не смог выполнить проверку цепочки сертификатов. (Это часть ответа, а также для AIA). Клиент также выполняет аналогичную проверку для сертификата сервера, который он получает в Server Hello. В Windows вы можете увидеть хранилища сертификатов для клиента и сервера через PowerShell. Выполните нижеследующее из консоли PowerShell.
PS Cert: > ls Location: CurrentUser StoreNames: {TrustedPublisher, ClientAuthIssuer, Root, UserDS...}
Местоположение: LocalMachine StoreNames: {TrustedPublisher, ClientAuthIssuer, Remote Desktop, Root...}
Браузеры, такие как Firefox и Opera, не полагаются на базовую ОС для управления сертификатами. Они сохраняют свои собственные хранилища сертификатов.
Подтверждение SSL использует как криптографию Symmetric, так и Public Key. Аутентификация сервера происходит по умолчанию. Аутентификация клиента является необязательной и зависит от того, настроена ли конечная точка сервера для аутентификации клиента или нет. Обратитесь к моему сообщению в блоге, как я объяснил это подробно.
Наконец, для этого вопроса
Как протокол HTTPS распознает сертификат? Почему HTTP не работает с сертификатами, когда это сертификаты, которые выполняют все доверие/шифрование/аутентификацию?
Сертификаты - это просто файл, формат которого определяется X.509. Это электронный документ, подтверждающий личность сообщающей стороны. HTTPS = HTTP + SSL - это протокол, который определяет рекомендации относительно того, как две стороны должны взаимодействовать друг с другом.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
Если вышеуказанное действие будет выполнено, вы получите справедливое представление о сертификатах и SSL.