Кратко

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

Архив, который вернулся вместе с посетителем

TLS умел возобновлять сеансы до появления билетов. В RFC 5246 сеанс TLS 1.2 объединяет параметры безопасности, пригодные для нескольких соединений. Выбранный сервером идентификатор указывает на активное или возобновляемое состояние.

Клиент возвращал короткое имя, а сервер искал запись. Большому сервису приходилось хранить множество записей, старить и инвалидировать их, передавать между узлами либо направлять клиента на прежнюю машину. Балансировка превращала память в задачу координации.

RFC 4507 в 2006 году предложил вынести саму запись в защищённый билет и отдать его клиенту. RFC 5077 заменил первый документ в 2008 году, сохранив архитектуру и усилив рекомендуемую конструкцию.

Теперь клиент приносил не номер серверной ячейки, а запечатанное содержимое. Место хранения изменилось; право толкования — нет.

Носитель не становился читателем

Для клиента билет RFC 5077 непрозрачен. Рекомендуемый формат содержит имя ключа, вектор инициализации, зашифрованное состояние и контроль целостности. Внутри могут находиться набор шифров, master secret, время и сведения об исходной аутентификации клиента.

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

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

Обычный отказ сохранял возможность перемен

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

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

Небольшой набор ключей с большим радиусом

«Без состояния на сервере» означает отсутствие записи на каждого клиента, а не полную амнезию. Остаются ключи билетов, версии формата, правила срока и живые соединения.

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

RFC 5077 рекомендует использовать ключи только для билетов и регулярно менять. RFC 9325 требует ротации, уничтожения старых ключей после срока и разумной жизни билета. Слишком долгий ключ превращает краткий доступ нарушителя в доступ к большой истории возобновления и ослабляет forward secrecy.

В билете работали три часа

TLS 1.2 сообщал клиенту подсказку о сроке. Клиент должен удалить билет после неё и может раньше. Сервер способен принимать меньше или дольше указанного. Это совет по хранению, не бронь будущего обслуживания.

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

Надёжная оболочка не исправляла слабое происхождение

RFC 7627 показал, что прежний master secret был недостаточно привязан к контексту рукопожатия. Активный атакующий мог синхронизировать секреты двух сеансов и разрушить свойства, зависевшие от их уникальности, включая возобновление.

Extended master secret связал вывод секрета с хешем transcript. Переносимое состояние наследует качество исходного обмена: сильная упаковка не переписывает сомнительное происхождение.

TLS 1.3 сделал билет именем PSK

RFC 8446 оформил возобновление как pre-shared key. После основного обмена NewSessionTicket передаёт срок, маскировку возраста, nonce и непрозрачный билет. Позднее binder доказывает владение соответствующей PSK.

Объявленный срок не превышает семи дней, и клиент не может хранить билет дольше. К PSK можно добавить новый эфемерный Diffie–Hellman; RFC 9325 рекомендует psk_dhe_ke, когда нужна forward secrecy возобновлённого соединения.

0-RTT — отдельная возможность. Билет полезен и для обычного 1-RTT. Не каждый билет одноразовый, а отключение ранних данных не отменяет ротацию ключей.

Скрытое содержание всё ещё оставляло метку

RFC 5077 защищает внутренние данные, но предупреждает: повтор одного билета может связать несколько рукопожатий. RFC 9325 также отмечает риск отслеживания.

Нечитаемый объект не обязательно неразличим. Частота выдачи, обновление, повтор и срок участвуют в защите приватности.

Что переместилось, а что осталось

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

Билет не доказывает человека, не обещает принятие до даты, не всегда одноразовый и не делает сервер абсолютно stateless. Его исторический результат точнее: состояние можно перенести, не передавая носителю власть над его смыслом.

Источники и пределы доказательств

Официальные источники: RFC 4507, RFC 5077, RFC 5246, RFC 7627, RFC 8446 и RFC 9325. Выводы о границах кластера следуют из механизмов и не являются измерением конкретного провайдера.