TLS 0-RTT: ранний запрос должен переносить возможный повтор
Увеличить схему
Фотография конкретного исполнения не приложена.
Ускорение первого запроса полезно, когда задержка handshake заметна пользователю. Но ранние данные имеют иные гарантии, чем обычная передача после согласования. Для изменяющих операций важнее сохранить корректность действия, чем выиграть один сетевой обмен.
RFC 9846 прямо ограничивает защиту 0-RTT от replay между соединениями. Это не означает произвольное дублирование обычных данных внутри одного установленного соединения. Отдельная политика early data должна учитывать возможность повторной обработки запроса на другом соединении и особенности распределённого сервиса.
Отказ принять early data также не равен обязательному отказу всего TLS. Приложение должно понимать, какие данные были приняты и когда разрешён повтор после обычного handshake. Нельзя назначать один и тот же автоматический retry всем операциям без учёта побочного эффекта и идентификаторов запросов.
В приёмке проверяют допустимую раннюю операцию, её отклонение и повтор в предусмотренном контуре. Для изменения состояния фиксируют отдельную защиту от второго действия. Отчёт должен различать выигрыш задержки и гарантию обработки. Наличие anti-replay механизма у одного узла само по себе не доказывает корректность всех экземпляров сервиса при балансировке.
Основание — Numbered IETF TLS and certificate lifecycle references; TLS1.3 RFC9846 July2026 replacing RFC8446, разделы RFC9846 0-RTT data; Section8 anti-replay; application requirements. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Использованы указанные RFC, включая базовую редакцию TLS 1.3 RFC 9846 от июля 2026 года, заменившую RFC 8446. Это разбор отдельных механизмов, а не полный профиль защиты. Реальные библиотека, сертификаты, trust store и настройки сервиса не проверялись; ключи, соединения и выпуск сертификатов не выполнялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
