TLS handshake под микроскопом: разбор по шагам с tcpdump

HTTPS кажется магией: браузер открывает сайт, и через доли секунды соединение уже зашифровано. Но под капотом происходит довольно сложный процесс — TLS handshake. Понимание его шагов помогает диагностировать проблемы с сертификатами, latency и несовместимостью протоколов.

Разберём TLS‑рукопожатие по шагам и посмотрим, как анализировать его через tcpdump.

Что такое TLS handshake

TLS handshake — это процесс установления защищённого соединения между клиентом и сервером.

Во время него стороны:

договариваются о версии протокола;
выбирают набор шифров (cipher suite);
обмениваются ключами;
проверяют сертификат сервера;
создают общий секрет для симметричного шифрования.

После завершения handshake начинается передача зашифрованных данных.

Шаг 1. ClientHello

Клиент отправляет первый пакет — ClientHello.

В нём содержится:

поддерживаемые версии TLS;
список cipher suites;
случайное число (Client Random);
расширения (SNI, ALPN и другие).

Посмотреть пакет можно так:

tcpdump -i eth0 -nn -s 0 -A port 443

Для более точного фильтра:

tcpdump -i eth0 -nn -s 0 'tcp port 443 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]>>4)<<2)) > 0)'

ClientHello — самый важный пакет для диагностики несовместимости.

Шаг 2. ServerHello

Сервер отвечает пакетом ServerHello.

Он выбирает:

конкретную версию TLS;
один cipher suite из предложенных;
отправляет своё случайное число (Server Random).

Если версия или шифры не совпадают — соединение прерывается.

В tcpdump ServerHello обычно следует сразу после ClientHello.

Шаг 3. Сертификат

Сервер отправляет цепочку сертификатов.

Клиент:

проверяет подпись;
проверяет срок действия;
сверяет домен (SNI);
проверяет доверие к CA.

Если есть проблема (expired, self-signed, неверный CN) — handshake завершается ошибкой.

В tcpdump это выглядит как несколько TLS-пакетов подряд с увеличенным размером.

Шаг 4. Обмен ключами

В современных версиях (TLS 1.3) используется ECDHE.

Стороны обмениваются параметрами для вычисления общего секрета.

Важно:

приватные ключи не передаются по сети;
общий ключ вычисляется независимо обеими сторонами.

После этого создаются симметричные ключи для шифрования трафика.

Шаг 5. Finished

Обе стороны отправляют сообщение Finished, подтверждающее успешное завершение handshake.

С этого момента данные передаются в зашифрованном виде.

TLS 1.2 vs TLS 1.3

TLS 1.3 значительно упростил handshake:

меньше раундов обмена;
быстрее установление соединения;
удалены устаревшие алгоритмы;
улучшена безопасность.

Handshake TLS 1.2 требует больше RTT, что влияет на latency.

Как анализировать handshake на практике

1. Снять дамп

tcpdump -i eth0 -nn -s 0 -w tls.pcap port 443

2. Открыть в Wireshark

Wireshark автоматически распознаёт TLS и покажет:

ClientHello
ServerHello
Certificate
Key Exchange
Finished

3. Проверить ошибки

Ищем:

Alert packets
handshake failure
protocol version
bad certificate

Типичные проблемы

1. Старый клиент

Сервер поддерживает только TLS 1.3, клиент — TLS 1.0.

2. Неверный SNI

Если SNI не передан, сервер может вернуть другой сертификат.

3. Блокировка firewall

Некоторые устройства фильтруют расширения TLS.

4. Высокая latency

Каждый дополнительный RTT увеличивает время установления HTTPS.

Быстрая проверка через openssl

Можно проверить handshake без tcpdump:

openssl s_client -connect example.com:443 -tls1_3

Вы увидите:

версию TLS;
выбранный cipher;
сертификат;
детали handshake.

Итог

TLS handshake — это фундамент HTTPS. Его понимание позволяет:

диагностировать ошибки сертификатов;
находить проблемы совместимости;
анализировать latency;
понимать безопасность соединения.

Анализ через tcpdump и Wireshark — обязательный навык для инженеров, работающих с сетями и backend‑инфраструктурой.

Когда HTTPS «странно себя ведёт», почти всегда стоит посмотреть handshake под микроскопом.