Кратко

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

Долгая связь расходует криптографический ресурс

После handshake работа ключей обычно остаётся невидимой. Между тем одна HTTP/2-сессия или постоянное API-соединение может передать огромное число TLS records. У AEAD-алгоритмов есть пределы применения одного ключа: объём обработанных данных влияет на вероятностные гарантии конфиденциальности и целостности.

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

В прежних версиях TLS существовало повторное согласование. Оно могло заново открыть сразу несколько вопросов внутри работающего соединения — от криптографических параметров до аутентификации. TLS 1.3 отказался от этого широкого инструмента и оставил более специализированные операции. KeyUpdate не выбирает новую версию или cipher suite, не меняет сертификат и не переопределяет прикладную личность. Он касается секретов трафика приложения.

Указатель границы защищён старым ключом

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

Граница тем самым находится внутри аутентифицированной последовательности. Сторонам не нужно угадывать общее время переключения. Но порядок обязателен: ранний переход не даст прочитать саму команду, поздний — первый record новой эпохи.

Переход относится к одному направлению. Клиентский и серверный трафик имеют независимые секреты. Обновление отправки у A означает обновление соответствующего приёма у B; отправка B остаётся на своей эпохе.

Вариант update_not_requested на этом заканчивает операцию. Вариант update_requested просит B отправить собственный KeyUpdate без встречного запроса. Лишь второе сообщение переводит обратное направление. Если обе стороны независимо начали запросы, они могут пересечься, и каждый участник всё равно обязан ответить. Однако повторно просить обновление до ожидаемого ответа нельзя. Сообщение до Finished отклоняется, а чрезмерный поток обновлений должен ограничиваться.

Односторонняя функция даёт несимметричную защиту

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

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

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

HTTP/2 сохранил смысл запросов

В одном HTTP/2-соединении одновременно идут многие streams. Смена аутентифицированной личности после handshake создала бы вопрос, к какой личности относится каждый запрос. Поэтому RFC 9113 запрещает в HTTP/2 post-handshake-аутентификацию TLS 1.3.

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

QUIC проводит границу иначе. RFC 9001 запрещает сообщения TLS KeyUpdate в QUIC. Дейтаграммы могут приходить не по порядку, поэтому QUIC применяет бит Key Phase и собственные правила подтверждения. Цель обновления общая, но процедура упорядоченного TLS-потока не универсальна.

Новое поколение без новой биографии

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

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

Источники и границы

Материал основан на RFC 8446, RFC 9001, RFC 9113 и RFC 9325. Эти документы не устанавливают текущую долю внедрения, значения по умолчанию в библиотеках или единый интервал обновления.