Как веб-сервер узнает, какую пару ключей использовать для расшифровки SSL?

Насколько я понимаю, когда Apache получает запрос на один из прослушиваемых TCP-портов (например, 80, 443), он решает, какой хост запрашивается, посмотрев заголовок HTTP Host. Затем сервер узнает, на какой виртуальный хост он должен перенаправить запрос.

Но как это работает для HTTP через SSL / TLS? Поскольку весь HTTP-запрос зашифрован (по крайней мере, это то, что, я полагаю, я где-то прочитал), информацию заголовка можно прочитать только после того, как сервер расшифровал данные. Но для расшифровки необходимо знать, какую пару ключей использовать, поскольку на веб-сервере можно установить несколько SSL-сертификатов.

Так как же сервер узнает, какой ключ ему нужен для расшифровки?

Я мог предположить, что рукопожатие TLS предоставляет необходимую информацию.

Относительно флага «возможный дубликат» :

Хотя я согласен, что ответы как на связанный вопрос, так и на мой, похожи, я должен сказать, что вопрос другой. Вне всякого сомнения, возможен ли хостинг нескольких сайтов с независимыми SSL-сертификатами. Вместо этого мой вопрос касается основного технического аспекта.

Первоначально веб-сервер не знал. По этой причине вам понадобился отдельный IP-адрес для каждого хоста SSL, который вы хотите разместить на сервере. Таким образом, сервер знал, что при установлении соединения по IP X ему нужно было использовать конфигурацию (включая сертификаты) для связанного хоста.

Это изменилось с указанием имени сервера , расширением TLS, которое действительно позволяет клиенту указывать требуемое имя хоста в процессе установления связи. Это расширение используется во всех современных ОС, но старые браузеры или серверы его не поддерживают, поэтому, если вы ожидаете, что клиенты по-прежнему будут использовать IE 6 на WinXP, вам не повезет.

Кажется, у вас есть некоторые неправильные представления о TLS / SSL. HTTP-запрос не зашифрован открытым ключом сервера. Он шифруется симметричным шифром с использованием ключа, согласованного в предыдущем рукопожатии.

Краткое описание рукопожатия TLS: сервер и клиент согласовывают некоторые наборы шифров, симметричный ключ (ключи) и некоторые другие детали. Чтобы предотвратить MITM, сервер обычно отправляет свой сертификат (цепочку) клиенту и аутентифицирует рукопожатие, используя ключ в сертификате. (Существуют также некоторые другие варианты, например, аутентификация клиента или TLS-PSK, но они не очень часто используются с HTTP.) Клиент может либо подтвердить сертификат (обычным способом), либо проигнорировать его.

Хотя SNI важен при использовании нескольких сертификатов TLS на одном IP-адресе, для сервера не требуется расшифровка запроса. Без SNI сервер не знает, какая цепочка сертификатов должна быть отправлена, поэтому сервер обычно выбирает один (например, первый vhost), который, конечно, может быть неправильным. Если сервер выбирает неверную цепочку сертификатов, клиент должен отказаться от нее (чтобы он не продолжил отправку HTTP-запроса). Однако, если клиент игнорирует сертификат (или недействительный сертификат помечен как доверенный для этого сайта), он может успешно продолжиться. Поскольку симметричный ключ, используемый для шифрования, не зависит от сертификата (TLS также предназначен для работы без сертификатов), сервер может расшифровать его.

Небольшое замечание, почему я пишу о TLS, а вы спрашивали о SSL: TLS - это новая версия SSL. Все версии SSL считаются небезопасными для общего использования, поэтому в настоящее время мы в основном используем TLS (1.0, 1.1, 1.2).