Почему TLS-рукопожатие ломается не там, где вы ищете ошибку

Почему TLS-рукопожатие ломается не там, где вы ищете ошибку

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

Типовые причины выглядят так:
— сервер не поддерживает нужный набор cipher suites;
— SNI указывает не на тот виртуальный хост;
— цепочка сертификатов неполная или не совпадает с именем;
— клиентский hello урезан прокси, DPI или балансировщиком;
— OCSP/CRL-проверка блокируется и валидация обрывается.

Важно различать криптографическую ошибку и транспортную. Первая обычно видна в логике TLS-стека, вторая — как timeout, reset или странный EOF. По RFC 5246 и 8446 это разные классы отказов, и лечатся они по-разному: один требует правки конфигурации, другой — поиска промежуточного узла между клиентом и сервером.

Самый надежный способ диагностики — воспроизвести handshake с минимальным набором условий: чистый клиент, прямое соединение, полная трассировка и проверка цепочки сертификатов отдельно от приложения. Тогда видно, на каком сообщении обмен рвется, а не только где всплыл общий error.

Bottom line: сначала докажите, на каком шаге рукопожатие ломается, и лишь потом меняйте шифры, сертификаты или сеть. Further reading: RFC 8446, RFC 5246, X.509 path validation.