Почему handshake ломается не в TLS, а в ваших ожиданиях от него

Почему handshake ломается не в TLS, а в ваших ожиданиях от него

TLS (Transport Layer Security) — это не «магия шифрования», а протокол с жёсткой последовательностью сообщений. Если на любом шаге ломается согласование параметров, ключей или сертификатов, соединение рвётся ещё до передачи данных. RFC 8446 описывает это как fail closed: лучше оборвать сессию, чем продолжить с невалидным состоянием.

Типовые причины всегда одни и те же:
— несовпадение версий или наборов шифров;
— проблемы с SNI и сертификатом;
— просроченная, отозванная или неполная цепочка доверия;
— сбой в ALPN, когда клиент и сервер не могут выбрать протокол;
— попытка resumption, но сервер не принимает ticket или PSK (pre-shared key).

В логах полезно разделять симптом и первопричину. Ошибка «handshake failure» часто приходит слишком поздно: настоящая проблема могла быть в DNS, прокси, middlebox или в том, что сервер закрыл доступ к старому cipher suite. RFC 5246 и RFC 8446 показывают, что поведение клиента и сервера допустимо только внутри чётко определённого набора состояний; всё остальное — не «глюк», а корректный отказ.

Если нужен рабочий чек-лист, сначала проверяйте цепочку сертификатов, затем SNI/ALPN, затем совместимость версий, и только потом — resumption. Это экономит часы и убирает ложные гипотезы.

Bottom line: handshake редко «ломается сам» — он просто быстро и честно обнаруживает несовместимость.

Further reading: RFC 8446, RFC 5246, RFC 6066.