Кратко

  • NewSessionTicket передаёт клиенту непрозрачный идентификатор PSK для будущего рукопожатия. Принятие билета криптографически связывает новое соединение с исходным рукопожатием, но не оживляет старый транспорт и не подтверждает актуальность изменяемого состояния приложения.
  • Срок жизни, маскировка возраста, nonce, хеш KDF, SNI, режим PSK и binder отвечают на разные ограниченные вопросы. Ни один из них сам по себе не доказывает текущую авторизацию, прежний маршрут арендатора, принятие 0-RTT или право повторно использовать старое бизнес-решение.
  • Контролируемое возобновление требует версионированного контракта состояния, ограниченного домена ключей и сервисов, отдельной политики 0-RTT, повторной проверки изменяемых полномочий и наблюдаемого перехода к полному рукопожатию.

Правильное рукопожатие с устаревшим результатом

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

В сетевом обмене не было утверждения «вернуть эту роль». Билет показывал, что клиент знает PSK, выведенный из прежнего рукопожатия, а текущий ClientHello содержит корректный binder. Именно приложение добавило другое правило: успешное возобновление транспорта означает действующую авторизацию.

Так две независимые шкалы времени превратились в одну. PSK ещё соответствовал политике билетов, а полномочие уже истекло по политике идентификации. Аутентичность защищает утверждение от незаметной подмены, но не от устаревания.

Билет обозначает новый ключ

В TLS 1.3 прежние механизмы идентификаторов сессии и билетов TLS 1.2 сведены к обмену PSK. После Finished клиента сервер может отправить NewSessionTicket. Непрозрачное значение билета связывается с PSK, полученным из секрета возобновления и индивидуального ticket_nonce.

Формат билета не обязан быть видим клиенту. Это может быть ключ поиска в серверной базе либо самодостаточный пакет, зашифрованный и аутентифицированный сервером. В обоих случаях значение в протоколе служит идентификатором PSK. Оно не является старым ключом трафика и не продолжает прежние номера записей.

Одно соединение может породить несколько билетов для параллельных соединений и гонки сетевых интерфейсов. Разные nonce дают разные PSK. Поэтому журналу нужны корреляция конкретного билета или эпохи ключа, а не один безразмерный признак «та же сессия».

Срок жизни — предел, а не обещание

ticket_lifetime отсчитывается от выпуска и не может превышать семи дней. Ноль предписывает клиенту удалить билет. Клиент вправе удалить его раньше, а сервер — считать недействительным до рекламируемого предела.

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

ticket_age_add скрывает обычный возраст от пассивного наблюдателя: сервер прибавляет случайное значение по модулю 2³², а при предъявлении вычитает его и сравнивает результат с прошедшим временем. Это сигнал свежести, а не активная защита от повторного воспроизведения. Копия билета несёт ту же арифметику.

При недопустимом расхождении возраста TLS разделяет решения. Сервер отклоняет 0-RTT, не считает ClientHello свежим, но может продолжить обычное возобновление. Одного булева поля ticket_valid для этих состояний недостаточно.

Binder доказывает цепочку секрета

Клиент предлагает один или несколько идентификаторов PSK и соответствующие binders. Binder аутентифицирует текущий ClientHello выбранным PSK и транзитивно связывает его с рукопожатием, породившим секрет возобновления.

Это сильное, но узкое доказательство. Оно подтверждает преемственность владения секретом и историю рукопожатия. Оно не ставит свежую метку времени на решение о роли, не доказывает активность учётной записи, состояние устройства или актуальность оценки риска.

При рукопожатии с PSK возобновления сервер заново не отправляет Certificate и CertificateVerify. Работает ранее аутентифицированный контекст. Поэтому приложение обязано перечислить, какие связанные утверждения могут пережить новую связь без обращения к актуальному источнику.

OpenSSL подчёркивает границу поколений после post-handshake-аутентификации клиента: сервер может выпустить новые билеты, связанные с обновлённой личностью. Старые билеты от этого не обновляются. Если эксплуатация не различает эти поколения, порядок отзыва уже потерян.

Имя сервиса принадлежит новому рукопожатию

В ClientHello возобновления клиент отправляет текущий SNI. Возобновлять соединение следует лишь там, где это имя допустимо для сертификата исходной сессии; обычно рекомендуется тот же SNI. Если реализация передаёт SNI приложению, это должно быть значение из нового ClientHello, а не историческое.

RFC 9525 также рассматривает reference identity как текущий вопрос приложения. SNI и ALPN помогают определить сервис и протокол, запрошенные сейчас.

Общий билетный ключ для нескольких имён, арендаторов или регионов — это решение о границах полномочий. Оно повышает долю успешного failover, но расширяет круг узлов, способных интерпретировать состояние. BoringSSL делает межимённое возобновление отдельной политикой, а не автоматическим следствием расшифровки билета.

Хеш KDF образует ещё одну жёсткую границу: билет совместим только с набором шифров, использующим тот же хеш, что и исходное соединение. Совместимость не сохраняет остальные параметры. Новый ClientHello, текущая маршрутизация и профиль приложения остаются решающими.

Возобновление не равно раннему выполнению

В NewSessionTicket может находиться расширение early_data с пределом байтов. Оно разрешает клиенту предложить 0-RTT по этому билету, но не обязывает сервер принять ранние данные и не делает прикладную операцию безопасной.

Телеметрия должна разделять расшифровку или поиск билета, выбор PSK для рукопожатия и принятие 0-RTT. Сервер может отвергнуть ранние данные из-за сомнительного возраста, отсутствия anti-replay-памяти или изменившихся параметров, а затем завершить обычное возобновлённое соединение.

HTTP 425 регулирует следующий уровень: origin может отказаться выполнять запрос, если происхождение из early data создаёт опасность повтора. Это не определяет полномочия самого билета. Проблема перенесённого состояния остаётся даже в системе, где 0-RTT полностью отключён.

QUIC даёт ещё одну проверку композиции. Для 0-RTT он помнит транспортные и прикладные параметры наряду с состоянием TLS. Действительный билет TLS не может объявить прежние лимиты QUIC или SETTINGS HTTP/3 совместимыми. Каждый слой проверяет свою непрерывность.

Модель хранения выбирает домен принятия

Билет, поддерживаемый базой, можно удалить после использования, ограничить одним хранилищем полномочий и учитывать как расходуемый идентификатор. Цена — зависимость от доступности базы и согласованности между узлами.

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

Это не выбор между «безопасной stateful» и «небезопасной stateless» схемой. Он распределяет сбои и полномочия. Задержка базы создаёт ложный отказ или повторное принятие; широко реплицированный ключ превращает локальное решение в региональное.

OpenSSL предоставляет callback сведения о результате расшифровки, имени ключа и прикладных данных, а также позволяет менять число билетов. GnuTLS управляет включением билетов, ключевым материалом и дополнительным выпуском. BoringSSL создаёт свежие смещения возраста, ограничивает число билетов и отдельно допускает early data.

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

Что допустимо переносить

Стабильные криптографические факты подходят для переноса: идентификатор PSK, хеш KDF, выбранный режим и ограниченная ссылка на аутентифицированное рукопожатие. Изменяемым бизнес-фактам нужно отдельное правило.

Приложение может сохранить ID пользователя и версию авторизации, но перед выдачей доступа запросить текущую версию. Маршрут арендатора можно снабдить сроком и отвергнуть после изменения топологии. После новой клиентской аутентификации можно выпустить другое поколение билетов.

Опасная схема переносит готовый ответ вместо доказательства: administrator=true, «устройство доверенное», «подписка активна», «отзывов нет». Шифрование и аутентификация предотвращают незаметное изменение. Они не мешают истинному утверждению стать ложным со временем.

То же различие действует в EAP-TLS: профиль использует билеты для возобновления аутентификации и сохраняет семидневный предел. Но развёртывание само решает, когда изменение учётных данных, доступа к сети или политики отменяет сокращённый путь. TLS предоставляет носитель, а не текущую авторизацию.

Доказательства, переживающие переключение

Следует фиксировать безопасную корреляцию билета или имя билетного ключа, узел и регион выпуска, время, заявленный и фактический срок, эпоху ключа, модель хранения, хеш KDF и режим PSK. При предъявлении нужны заявленный возраст, результат расшифровки или поиска, индекс выбранного PSK, текущие SNI и ALPN, итог возобновления и переход к полному рукопожатию.

0-RTT учитывается отдельно: предложен, криптографически допустим, отклонён или принят, предел байтов, состояние anti-replay и решение приложения. resumed=true никогда не должно означать early_data_accepted=true.

Для прикладного состояния нужны версия схемы, версия авторизации, проверка отзыва, версия маршрута арендатора и источник каждого текущего решения. Редактированная корреляция может связать выпуск с принятием, не раскрывая билет или PSK.

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

Нужна и проверка восстановления. Отклонённый билет должен приводить к полному рукопожатию, если политика его допускает. Аварийное управление должно отключать одну эпоху билетных ключей или одну версию состояния, не останавливая прочий TLS. После отката новые билеты получают новую версию, а старые отвергаются с записанной причиной.

Источники