Как работает SSL?
Где установлен сертификат на клиенте (или браузере?) И на сервере (или веб-сервере?)?
Как запускается процесс доверия / шифрования / аутентификации, когда вы вводите URL-адрес в браузер и получаете страницу с сервера?
Как протокол HTTPS распознает сертификат? Почему HTTP не может работать с сертификатами, если все доверие / шифрование / аутентификация работают именно с сертификатами?
ssl
ssl-certificate
Вики
источник
источник
Ответы:
Возможности TLS
«SSL» - это имя, которое чаще всего используется для обозначения этого протокола, но SSL конкретно относится к проприетарному протоколу, разработанному Netscape в середине 90-х годов. TLS - это стандарт IETF, основанный на SSL, поэтому в своем ответе я буду использовать TLS. В наши дни есть вероятность, что почти все ваши безопасные соединения в Интернете действительно используют TLS, а не SSL.
TLS имеет несколько возможностей:
№1 и №2 очень распространены. №3 встречается реже. Кажется, вы сосредоточились на №2, поэтому я объясню эту часть.
Аутентификация
Сервер аутентифицирует себя для клиента с помощью сертификата. Сертификат - это блок данных [1], который содержит информацию о веб-сайте:
Вы можете добиться конфиденциальности (№1 выше), используя открытый ключ, включенный в сертификат, для шифрования сообщений, которые могут быть расшифрованы только с помощью соответствующего закрытого ключа, который должен безопасно храниться на этом сервере. [2] Назовем эту пару ключей KP1, чтобы потом не запутаться. Вы также можете убедиться, что доменное имя в сертификате совпадает с сайтом, который вы посещаете (№ 2 выше).
Но что, если злоумышленник может изменить пакеты, отправляемые на сервер и с сервера, и что, если этот злоумышленник изменит сертификат, который вам был предоставлен, и вставил свой собственный открытый ключ или изменил любые другие важные детали? Если это произойдет, злоумышленник сможет перехватить и изменить любые сообщения, которые, по вашему мнению, были надежно зашифрованы.
Чтобы предотвратить эту самую атаку, сертификат криптографически подписывается чужим закрытым ключом таким образом, что подпись может быть проверена любым, у кого есть соответствующий открытый ключ. Назовем эту пару ключей KP2, чтобы было ясно, что это не те ключи, которые использует сервер.
Центры сертификации
Так кто создал КП2? Кто подписал сертификат?
Немного упрощая, центр сертификации создает KP2, и они продают услугу использования своего закрытого ключа для подписи сертификатов для других организаций. Например, я создаю сертификат и плачу такой компании, как Verisign, за ее подпись своим закрытым ключом. [3] Поскольку никто, кроме Verisign, не имеет доступа к этому закрытому ключу, никто из нас не может подделать эту подпись.
И как мне лично получить открытый ключ в KP2, чтобы проверить эту подпись?
Мы уже видели, что сертификат может содержать открытый ключ - а компьютерщики любят рекурсию - так почему бы не поместить открытый ключ KP2 в сертификат и не распространить его таким образом? Поначалу это звучит немного безумно, но на самом деле это работает именно так. Продолжая пример Verisign, Verisign создает сертификат, который включает информацию о том, кто они такие, какие типы вещей им разрешено подписывать (другие сертификаты) и их открытый ключ.
Теперь, если у меня есть копия этого сертификата Verisign, я могу использовать ее для проверки подписи на сертификате сервера для веб-сайта, который я хочу посетить. Легко, правда ?!
Ну не так быстро. Мне нужно было откуда- то получить сертификат Verisign . Что, если кто-то подделает сертификат Verisign и поместит туда свой открытый ключ? Затем они могут подделать подпись на сертификате сервера, и мы вернемся к тому, с чего начали: атака «человек посередине».
Цепочки сертификатов
Продолжая думать рекурсивно, мы могли бы, конечно, ввести третий сертификат и третью пару ключей (KP3) и использовать их для подписания сертификата Verisign. Мы называем это цепочкой сертификатов: каждый сертификат в цепочке используется для проверки следующего сертификата. Надеюсь, вы уже видите, что этот рекурсивный подход - это просто черепахи / сертификаты до конца. Где это остановится?
Поскольку мы не можем создать бесконечное количество сертификатов, очевидно, что цепочка сертификатов должна где-то останавливаться , и это достигается путем включения сертификата в цепочку, которая является самоподписанной .
Да, в конце цепочки сертификатов (он же «корень») будет сертификат, который использует свою собственную пару ключей для подписи. Это устраняет проблему бесконечной рекурсии, но не решает проблему аутентификации. Кто угодно может создать самозаверяющий сертификат, на котором написано что угодно, точно так же, как я могу создать фальшивый диплом Принстона, в котором говорится, что я трижды специализировался в политике, теоретической физике и прикладном искусстве, а затем подписал свое имя внизу.
[Несколько неинтересное] решение этой проблемы состоит в том, чтобы просто выбрать некоторый набор самозаверяющих сертификатов, которым вы явно доверяете. Например, я мог бы сказать: «Я доверяю этому самозаверяющему сертификату Verisign».
Имея это явное доверие, теперь я могу проверить всю цепочку сертификатов. Независимо от того, сколько сертификатов в цепочке, я могу проверить каждую подпись вплоть до корня. Когда я добираюсь до корня, я могу проверить, является ли этот корневой сертификат тем, которому я явно доверяю. Если так, то я могу доверять всей цепочке.
Признанное доверие
Аутентификация в TLS использует систему предоставленного доверия . Если я хочу нанять автомеханика, я не могу доверять ни одному случайному механику, который найду. Но, может быть, мой друг ручается за конкретную механику. Поскольку я доверяю своему другу, я могу доверять этому механику.
Когда вы покупаете компьютер или загружаете браузер, он поставляется с несколькими сотнями корневых сертификатов, которым он явно доверяет. [4] Компании, которые владеют этими сертификатами и управляют ими, могут передать это доверие другим организациям, подписав свои сертификаты.
Это далеко не идеальная система. Иногда ЦС может ошибочно выдать сертификат. В таких случаях сертификат может потребоваться отозвать. Аннулировать сложно, поскольку выданный сертификат всегда будет криптографически корректным; внеполосный протокол необходим, чтобы узнать, какие ранее действующие сертификаты были отозваны. На практике некоторые из этих протоколов не очень безопасны, и многие браузеры все равно их не проверяют.
Иногда компрометируется весь ЦС. Например, если вы взломаете Verisign и украдете их корневой ключ подписи, вы сможете подделать любой сертификат в мире. Обратите внимание, что это влияет не только на клиентов Verisign: даже если мой сертификат подписан Thawte (конкурент Verisign), это не имеет значения. Мой сертификат все еще можно подделать, используя взломанный ключ подписи от Verisign.
Это не просто теория. Это случилось в дикой природе. DigiNotar был взломан и впоследствии обанкротился. Comodo также был взломан , но по необъяснимым причинам они продолжают работать по сей день.
Даже если ЦС не скомпрометированы напрямую, в этой системе есть другие угрозы. Например, правительство использует законное принуждение, чтобы заставить ЦС подписать поддельный сертификат. Ваш работодатель может установить собственный сертификат ЦС на компьютер вашего сотрудника. В этих различных случаях трафик, который, как вы ожидаете, будет «безопасным», на самом деле полностью виден / может быть изменен для организации, которая контролирует этот сертификат.
Было предложено несколько замен, включая Convergence , TACK и DANE .
Сноски
[1] Данные сертификата TLS отформатированы в соответствии со стандартом X.509 . X.509 основан на ASN.1 («Абстрактная синтаксическая нотация №1»), что означает, что это не двоичный формат данных. Следовательно, X.509 должен быть закодирован в двоичный формат. DER и PEM - две наиболее распространенные кодировки, о которых я знаю.
[2] На практике протокол фактически переключается на симметричный шифр, но эта деталь не имеет отношения к вашему вопросу.
[3] Предположительно, ЦС действительно проверяет вашу личность перед подписанием сертификата. Если бы они этого не сделали, я мог бы просто создать сертификат для google.com и попросить ЦС подписать его. Обладая этим сертификатом, я мог управлять любым «безопасным» подключением к google.com. Следовательно, этап проверки является очень важным фактором в работе центра сертификации. К сожалению, не очень ясно, насколько тщательным является этот процесс проверки в сотнях центров сертификации по всему миру.
[4] См. Список доверенных центров сертификации Mozilla .
источник
HTTPS - это комбинация HTTP и SSL (Secure Socket Layer) для обеспечения зашифрованной связи между клиентом (браузером) и веб-сервером (здесь размещается приложение).
Зачем это нужно?
HTTPS шифрует данные, которые передаются от браузера к серверу по сети. Таким образом, никто не может прослушивать данные во время передачи.
Как устанавливается соединение HTTPS между браузером и веб-сервером?
Этот поток можно представить в виде следующей диаграммы:
источник
Я написал небольшой пост в блоге, в котором кратко обсуждается процесс. Пожалуйста, смотрите.
Подтверждение SSL
Вот небольшой отрывок из того же:
"Клиент делает запрос к серверу через HTTPS. Сервер отправляет копию своего сертификата SSL + открытый ключ. После проверки идентичности сервера с его локальным хранилищем доверенного центра сертификации, клиент генерирует секретный ключ сеанса, шифрует его, используя общедоступный сервер. key и отправляет его. Сервер расшифровывает секретный сеансовый ключ, используя свой закрытый ключ, и отправляет подтверждение клиенту. Безопасный канал установлен ».
источник
Мехаасе уже подробно объяснил это. Я добавлю свои 2 цента к этой серии. У меня много сообщений в блогах, посвященных подтверждению SSL и сертификатам. Хотя большая часть этого вращается вокруг веб-сервера IIS, сообщение по-прежнему актуально для установления связи SSL / TLS в целом. Вот несколько примеров для справки:
Установление доверия между взаимодействующими сторонами через хранилище сертификатов
Связь SSL / TLS работает исключительно на основе доверия. Каждый компьютер (клиент / сервер) в Интернете имеет список корневых центров сертификации и промежуточных центров сертификации, которые он поддерживает. Они периодически обновляются. Во время подтверждения SSL это используется как ссылка для установления доверия. Например, во время подтверждения SSL, когда клиент предоставляет сертификат серверу. Сервер попытается проверить, присутствует ли CA, выдавший сертификат, в его списке CA. Когда он не может этого сделать, он объявляет, что не смог выполнить проверку цепочки сертификатов. (Это часть ответа. Здесь также рассматривается AIAдля этого.) Клиент также выполняет аналогичную проверку сертификата сервера, который он получает в Server Hello. В Windows вы можете увидеть хранилища сертификатов для клиента и сервера через PowerShell. Выполните нижеприведенное из консоли PowerShell.
Такие браузеры, как Firefox и Opera, не полагаются на базовую ОС для управления сертификатами. У них есть собственные отдельные хранилища сертификатов.
Подтверждение SSL использует криптографию с симметричным и открытым ключом. Серверная аутентификация происходит по умолчанию. Аутентификация клиента является необязательной и зависит от того, настроена ли конечная точка сервера для аутентификации клиента или нет. Обратитесь к моему сообщению в блоге, поскольку я подробно объяснил это.
Наконец для этого вопроса
Сертификаты - это просто файл, формат которого определен стандартом X.509 . Это электронный документ, удостоверяющий личность сообщающей стороны. HTTPS = HTTP + SSL - это протокол, определяющий принципы взаимодействия двух сторон друг с другом.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
Если вышеуказанное действие будет выполнено, вы получите хорошее представление о сертификатах и SSL.
источник