Почему TLS-сессия не возобновляется, даже когда всё “почти” совпадает?

Почему TLS-сессия не возобновляется, даже когда всё “почти” совпадает?

TLS (Transport Layer Security) resume — это не магия ускорения, а строгая проверка совпадения параметров сессии. В TLS 1.3 (RFC 8446) сервер может принять PSK (pre-shared key), но только если сходятся identity, возраст ticket, набор шифров и политика ранних данных. Если хотя бы один элемент выпадает, происходит полный handshake.

Частая ошибка — путать “есть билет” с “можно продолжать”. Сервер может отвергнуть возобновление из-за смены SNI, ALPN, ключевого расписания, истечения lifetime ticket или внутренней политики риска. Это не баг клиента; так спецификация и задумывалась: возобновление должно быть безопасным, а не просто быстрым.

Что проверять в расследовании:
— совпадает ли server name indication (SNI) и application-layer protocol negotiation (ALPN);
— не истёк ли ticket и не отозван ли контекст на стороне сервера;
— разрешены ли ранние данные, если клиент пытался отправить 0-RTT;
— не изменились ли cipher suites, key share или параметры session cache.

В логах полезно разделять отказ в resumption и отказ в полном handshake: механизмы разные, а выводы — тоже. RFC 8446 и практика реализации показывают, что “fallback” к полному обмену — нормальный путь, а не авария.

Bottom line: если resumption не срабатывает, ищите не “сломанный TLS”, а расхождение политики, контекста или метаданных сессии. Further reading: RFC 8446, RFC 5077, анализы 0-RTT и PSK-механизмов.