Кратко

  • HelloRetryRequest не начинает TLS 1.3 заново. Второй ClientHello обязан повторять первый, кроме узкого списка разрешённых изменений: новой доли для запрошенной группы, удаления early data, возврата cookie и пересчёта binders.
  • Протокол заменяет байты ClientHello1 синтетическим сообщением message_hash с его хешем, а затем аутентифицирует это обязательство вместе с запросом и последующими сообщениями. Работа без состояния сжимает историю, но не удаляет её.
  • Операционное доказательство должно хранить оба ClientHello, причину запроса, разрешённую разницу, политику cookie, итоговую группу, alerts и добавленную задержку. Успешное рукопожатие само по себе не доказывает ни правомерность запроса, ни исходное предпочтение клиента.

Захват начался слишком поздно

Диагноз выглядел очевидным. ClientHello2 передал одну долю ключа, ServerHello выбрал ту же группу, CertificateVerify и Finished прошли без предупреждения. Панель сформулировала вывод: клиент предложил группу, сервер её принял.

Отсутствующее первое сообщение фиксировало иную последовательность. Клиент перечислил несколько групп в supported_groups, но заранее отправил key_share для другой. Сервер не захотел использовать этот прогноз и послал HelloRetryRequest с группой, которую клиент уже объявил поддерживаемой, хотя её доли в первом полёте не было. Единственная доля во втором Hello была ответом на решение сервера, а не свидетельством первоначального выбора клиента.

Разрешённая конфигурация, объявленная поддержка, предварительно отправленная доля, запрошенная группа и конечный выбор — разные факты. Наблюдение только второго полёта приписывает клиенту предпочтение сервера, скрывает дополнительный сетевой круг и искажает разбор криптографической миграции.

Коррекция по закрытому списку

Текущая спецификация TLS 1.3 требует, чтобы ClientHello2 совпадал с ClientHello1, кроме явно разрешённых случаев. Если запрос содержит key_share, клиент заменяет прежний список одной новой долей указанной группы. Он удаляет early_data, копирует полученный cookie и пересчитывает PSK binders по истории с повторным запросом. Будущее расширение может разрешить другое изменение лишь тогда, когда присутствует в HRR и определяет правило.

Это не пожелание приблизительного сходства, а список полномочий. Граница изменяемых полей является частью соглашения о безопасности.

Запрошенная группа обязана находиться в исходном supported_groups и не должна уже иметь долю в первом key_share. Запрос без полезного изменения, второй HRR, не предложенный cipher suite или ServerHello с другой группой должны быть отвергнуты.

Так бытовое слово retry становится детерминированным переходом состояния. Сервер вправе один раз запросить допустимую коррекцию. Он не вправе открыть заново все поля или повторять запрос, пока клиент не примет иную политику.

message_hash оставляет первое предложение в истории

Криптографические вычисления TLS зависят от упорядоченного хеша сообщений рукопожатия. Серверу, который хочет выдать cookie и затем удалить клиентское состояние, неудобно хранить каждый полный ClientHello или внутреннее промежуточное состояние конкретной библиотеки.

TLS заменяет ClientHello1 синтетическим сообщением типа 254, message_hash, тело которого равно Hash(ClientHello1). Затем в историю входят HelloRetryRequest, ClientHello2, ServerHello и сообщения аутентификации. CertificateVerify, Finished и последующий PSK binder остаются связаны с первой заявкой.

Хеш — обязательство, а не обратимая копия. Конечные точки могут обнаружить разрыв аутентифицированной истории, но операционная команда не восстановит по одному хешу исходные расширения и доли. Протокол доказывает непрерывность; захват или структурированный журнал объясняет разницу.

Поддержка, прогноз и выбор — разные состояния

Клиент TLS 1.3 старается сэкономить сетевой круг, заранее отправляя доли ключей. Генерация доли для каждой поддерживаемой группы увеличивает вычисления и размер ClientHello. Одна доля экономит байты, но может вызвать HRR, если сервер требует другую группу, которую клиент тоже поддерживает.

Гибридные постквантовые группы делают компромисс заметнее. OpenSSL позволяет задавать наборы групп, прогнозируемые доли и предпочтение сервера. Документация предупреждает: большой ClientHello может пересечь границу TCP-сегмента и столкнуться с неисправным межсетевым экраном; отложенная большая доля оставляет дополнительный круг лишь серверам, которые её действительно запросили. GnuTLS тоже отделяет политику групп от режима одной доли TLS 1.3.

Поэтому строки «поддерживает X» в инвентаризации недостаточно. Реализация может знать X, конфигурация разрешать X, первый Hello объявлять X без доли, сервер затем запросить X, а соединение в итоге выбрать X. Каждому состоянию нужно отдельное доказательство.

Early data не проходит по обходному пути

Если ClientHello1 содержал early_data, ClientHello2 удаляет расширение. HelloRetryRequest тем самым доказывает, что путь 0-RTT в этом рукопожатии не был принят.

При этом клиент мог отправить данные приложения до получения запроса. Решение о повторе операции, уже замеченном ответе и согласовании побочных эффектов остаётся за приложением. Поздний успех в 1-RTT не делает неидемпотентное действие безопасным автоматически.

Телеметрия должна разделять попытку early data, отказ через HRR, решение о повторной отправке и деловой результат. Метка «возобновление успешно» стирает главное изменение состояния.

Cookie доказывает только заложенный в него факт

Сервер может вложить непрозрачный cookie в HelloRetryRequest и потребовать вернуть его без изменения. Токен может связывать хеш первого Hello, выбранные параметры, время или контекст маршрутизации. Защита целостности доказывает происхождение и отсутствие изменения в пределах правил хранения ключа, срока и проверки.

DTLS 1.3 добавляет другой сценарий: связать cookie с видимым адресом клиента и проверить обратный путь до отправки усиленного ответа. Ротация секретов, перекрывающиеся окна и временные метки показывают, что у токена без серверного состояния всё равно есть жизненный цикл.

Доступность адреса не равна личности. Возврат cookie может показать, что кто-то принимал трафик на адресе в определённое время, но не устанавливает человека, роль устройства или право приложения. Верный cookie также не отменяет сравнение двух ClientHello.

Расширения входят в ту же историю

Encrypted Client Hello даёт ограниченный пример композиции. Значение random у HelloRetryRequest фиксировано, поэтому ECH не может разместить там подтверждение, как в обычном ServerHello. Вместо этого определено расширение encrypted_client_hello, подтверждение которого выводится из внутреннего ClientHello и изменённого HRR.

Смысл не в превращении материала в руководство по ECH. Любое расширение должно определить допустимые изменения, место сигнала и включение в аутентифицированную историю. Оно не получает отдельного неограниченного пространства переговоров.

Доказательство, которое переживёт инцидент

Надёжная запись начинается раньше момента, который многие панели называют соединением. Она хранит хеш и допустимые разобранные поля ClientHello1, точный HelloRetryRequest, хеш cookie вместо секрета, поля ClientHello2 и итоговый ServerHello. Каждое решение связывается с версиями реализации и конфигурации.

Для групп записывают разрешённый набор, порядок объявления, прогнозируемые доли, режим предпочтения сервера, запрошенную, возвращённую и согласованную группу. Для HRR — причину, соответствие разницы списку, alert при отказе и второй запрос. Для эффекта — дополнительный RTT, размеры двух Hello, сегментацию, исход early data, завершение и клиентскую популяцию.

Нужны и отрицательные доказательства. Проверяют отказ для не объявленной группы, уже переданной доли, запроса без изменения, смены suite, второго HRR и противоречивого ServerHello. Тестовый исполнитель BoringSSL моделирует неверные варианты, потому что правильный отказ — часть совместимости.

Завершённое рукопожатие — конец рассказа, а не доказательство легитимности всех прежних решений. Доказательство находится в проверяемой цепочке ограниченных изменений.

Источники