Почему TLS-рукопожатие ломается не на шифрах, а на мелочах протокола

Почему TLS-рукопожатие ломается не на шифрах, а на мелочах протокола

TLS (Transport Layer Security) — это не один обмен ключами, а цепочка проверок: версии, наборов шифров, расширений, сертификатов и состояния сессии. По RFC 8446 ошибка в любом звене может оборвать handshake, даже если криптография сама по себе корректна.

Чаще всего ломается не математика, а согласование параметров: клиент предлагает наборы шифров, сервер их фильтрует; не совпали SNI, ALPN или требования к эллиптическим кривым — и переговоры прекращаются. В исследованиях по эксплуатации TLS повторяется один мотив: баги интеграции и неверные ожидания между библиотекой, прокси и приложением встречаются чаще, чем «слабый алгоритм».

Если рукопожатие падает, проверяйте по порядку:
— версию протокола и наборы шифров;
— цепочку сертификатов и срок действия;
— имя хоста в SNI и CN/SAN;
— поддержку session resumption и tickets;
— совпадение времени на клиентах и серверах.

Отдельная ловушка — возобновление сессии. RFC 5077 и RFC 8446 показывают, что resumption ускоряет обмен, но добавляет зависимость от ticket keys и политики сервера; потеря этих ключей или смена состояния часто выглядит как «случайный» отказ.

Bottom line: когда TLS не сходится, ищите не «слабое шифрование», а несоответствие параметров и состояния. Further reading: RFC 8446, RFC 5077, RFC 5246.