Рукопожатие TLS 1.3 работает следующим образом:
Клиент отправит на сервер структуру данных «ClientHello». На данном этапе клиент еще не знает, какие «Группы» поддерживает сервер. Чтобы избежать дополнительного обращения к серверу, он может предположительно содержать «элемент группы» для группы, которую он предпочитает использовать. В рассматриваемом случае элемент group представляет собой 32-байтовый открытый ключ для использования с «Группой 29» (29 == hex 0x1d), которая является идентификатором TLS для того, что обычно известно как X25519. Список нумерации для всех поддерживаемых TLS групп находится здесь: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
X25519 означает замену Диффи-Хеллмана с использованием хорошо известной базовой точки G на эллиптической кривой Curve25519, где элементы группы находятся в большой циклической подгруппе, содержащей G, внутри этой кривой. Точку G передавать не нужно, потому что она определена как часть Стандарт X25519 и одинаково для всех вызовов X25519.
Эфемерный открытый ключ клиента — это «групповой элемент», который был отправлен предположительно. Для X25519 он имеет длину 32 байта (64 шестнадцатеричных символа или 256 бит). Этот групповой элемент указан как значение «обмена ключами» в разделе «общие ключи» структуры данных ClientHello.
Сервер ответит сообщением «ServerHello», если он согласится использовать спекулятивно включенную группу клиента, здесь Группа 29. Это включает элемент группы сервера в значении «обмена ключами» в разделе «общие ключи».Этот групповой элемент является эфемерным открытым ключом сервера.
С помощью этой информации и клиент, и сервер смогут вычислить один и тот же общий секрет, называемый «предварительным секретом». Затем они объединяются с данными ClientHello и ServerHello для получения симметричных ключей шифрования (см. https://datatracker.ietf.org/doc/html/rfc8446#section-7.1). Это позволяет серверу и клиенту безопасно обмениваться данными друг с другом с помощью шифрования с проверкой подлинности, такого как AES-GCM.
Если сервер не согласен с предложенной клиентом группой или клиент решил не предлагать какую-либо группу, но сервер согласен с (другой) группой, которую клиент указал в «поддерживаемых группах», вместо этого он отправляет HelloRetryRequest, который сообщает client, чтобы повторить ClientHello, используя указанную группу, которую сервер затем принимает, как указано выше. Если сервер не согласен Любые группу, которую поддерживает клиент, он отправляет предупреждение об ошибке, и рукопожатие завершается неудачно — если клиент также не предложил доступный PSK, но обычно это происходит только для возобновления, а если начальное рукопожатие не удается, возобновление невозможно.
TLS 1.0-1.2 обрабатывает ECDHE по-другому — если вообще, потому что там это необязательно. В этих протоколах набор шифров определяет обмен ключами и аутентификацию, а также шифр данных и хэш для HMAC (если не AEAD) и PRF (если 1.2). Клиент отправляет ClientHello список наборов шифров, которые он поддерживает, любой, некоторые или все из которых могут использовать ECDHE в сочетании с аутентификацией RSA или ECDSA (т. е. сертификатом). и расширение support-groups (или support-curves до RFC7919), определяющее поддерживаемые им кривые. Если сервер соглашается на предложенный набор шифров ECDHE и предложенную кривую, он отправляет ServerHello, указав набор шифров, затем его цепочку сертификатов, а затем ServerKeyExchange, содержащий идентификатор кривой и ее эфемерный открытый ключ.Клиент (если он принимает сертификат) отправляет ClientKeyExchange, содержащий его эфемерный открытый ключ, после чего вычисление общего секрета происходит аналогичным образом, хотя детали получения рабочих ключей отличаются от 1.3, а также от 1.2 и ранее.
