Это довольно большой вопрос =) Ниже приведен общий обзор HTTPS; кричите, если что-то непонятно, и я укажу больше деталей.
При использовании HTTPS-соединения криптография с открытым ключом используется только во время инициализации сеанса. Частью этой инициализации является безопасная замена частного общего ключа, который затем используется для симметричного шифрования. Причиной этого является то, что асимметричное шифрование (с открытым ключом) значительно медленнее, чем шифрование с симметричным ключом, из-за математики.
SSL рукопожатие
На очень высоком уровне протокол выглядит примерно так:
Клиент отправляет начальное сообщение "HELLO", которое содержит версию ssl, которую он хотел бы использовать, псевдослучайную строку битов (назовем это B1) и список различных шифров, которые он поддерживает.
Сервер отвечает своим собственным сообщением "HELLO", другой псевдослучайной строкой битов (назовем это B2), выбранным шифром (обычно это самый сильный шифр из списка, отправленного клиентом, который поддерживает сервер), и его сертификат, который содержит его открытый ключ (назовем это k).
Затем клиент использует сертификат для аутентификации сервера (см. Ниже) и создает "секрет мастера" - еще одну строку псевдослучайных битов, которую мы назовем S.
Если клиент удовлетворен результатами проверки подлинности сервера, он шифрует секретный ключ перед мастером S с помощью открытого ключа сервера k и отправляет его на сервер (сам S шифруется, но соединение по-прежнему отсутствует).
На этом этапе сервер и клиент совместно используют три строки битов - B1, B2 и S. B1 и B2 были отправлены в незашифрованном виде - S был зашифрован, и поэтому, предполагая, что частный ключ сервера действительно является закрытым, известен только клиент и сервер.
И клиент, и сервер затем используют эти три битовые строки для создания ключа сеанса - строки, которая известна только им, и может использоваться в качестве ключа в ранее выбранном симметричном шифре.
Клиент и сервер затем обмениваются сообщениями, которые указывают, что они меняют протокол, и все последующие сообщения шифруются (симметрично, с ключом, вычисленным выше).
Проверка подлинности сервера
Когда клиент получает сообщение HELLO от сервера, он должен быть уверен, что он говорит с сервером, который, по его мнению, так и есть. Сертификат и ключ сервера используются для установления этого доверия.
Весь цифровой сертификат является третьей стороной, утверждающей, что «этот объект содержит закрытый ключ, который соответствует этому открытому ключу, который встроен в этот сертификат». Такие организации, как Verisign, сделают это утверждение - по цене. Причина, по которой люди платят Verisign и другим за сертификаты, заключается в том, что Verisign столкнулась с проблемой внедрения своих промежуточных сертификатов в большинство распространенных браузеров.
Итак, когда клиент получает сервер HELLO, он выполнит следующие проверки:
- Соответствует ли сегодняшняя дата сроку действия сертификата?
- Имя субъекта сертификата совпадает с именем сервера, к которому я пытаюсь подключиться?
- Совпадает ли имя эмитента в сертификате с каким-либо из тех ЦС, о открытых ключах которых я знаю?
- Если да, проверяет ли этот открытый ключ, который у меня есть, для этого центра сертификации?
Если все эти проверки пройдены, клиент предполагает, что он может поверить, что сервер - это тот, кого он ожидал. Затем он берет открытый ключ (все еще k) из сертификата и использует его для безопасной передачи S на сервер. На данный момент идея заключается в том, что у вас есть какое-то стороннее (Verisign) утверждение о том, что открытый ключ принадлежит серверу; таким образом, только сервер сможет расшифровать результат E (S, k), и, следовательно, только сервер может создать соответствующий ключ, который вы будете использовать для симметричного шифра.
После рукопожатия ваша уверенность в том, что пакеты не могут быть прочитаны третьей стороной, должна быть равна вашей уверенности в используемом симметричном алгоритме.
(Существуют и другие приятные повороты - например, причина в том, что используются трехбитные строки, для предотвращения атак воспроизведения. Если используется только S, злоумышленник может записать весь сеанс и воспроизвести его в свободное время - например, многократно повторяя инструкцию по переводу денег. Благодаря тому, что и клиент, и сервер генерируют дополнительные псевдослучайные строки, вы значительно уменьшаете вероятность того, что два независимых SSL-рукопожатия произведут один и тот же S.)
