Как TLS на самом деле защищает HTTPS-соединение?

Люди говорят «HTTPS означает, что всё зашифровано» и на этом останавливаются, но самое интересное — как два незнакомца в интернете договариваются о общем секрете, никогда не встречаясь, в сети, полной людей, которые могут подслушивать. Этим занимается TLS, и механика стоит понимания, если вы работаете с сетями, веб-разработкой или безопасностью.

Рукопожатие шаг за шагом

Когда ваш браузер подключается к https://example.com, вот примерно что происходит (TLS 1.3, который используют большинство сайтов):

1. ClientHello — браузер отправляет поддерживаемые cipher suites, случайный nonce и предположение о доле ключа (используя что-то вроде X25519 или secp256r1) для обмена ключами.
2. ServerHello — сервер выбирает cipher suite, отправляет свою долю ключа и возвращает сертификат плюс подпись, доказывающую, что он владеет приватным ключом, соответствующим этому сертификату.
3. Вывод ключей — обе стороны теперь независимо вычисляют один и тот же общий секрет, используя математику в стиле Diffie-Hellman на своих долях ключей. Никто никогда не передаёт сам секрет; он производится, а не отправляется.
4. Finished сообщения — обе стороны подтверждают, что рукопожатие не подвергалось подделке, отправляя MAC по всему transcriptу рукопожатия.

После этого всё шифруется симметричными ключами, выведенными из общего секрета, обычно AES-128-GCM или ChaCha20-Poly1305. TLS 1.3 сократил это с двухраундового рукопожатия TLS 1.2 практически до одного раунда, что даёт реальный выигрыш в задержке в масштабе.

Почему сертификат важнее шифрования

Шифрование без проверки идентичности бесполезно — любой может установить зашифрованный канал, включая атакующего, запускающего man-in-the-middle. Сертификат связывает открытый ключ с именем домена и подписан Certificate Authority (CA) вроде Let's Encrypt или DigiCine.

Ваш браузер доверяет фиксированному списку корневых CA, встроенному в хранилище доверия ОС или браузера. Сертификат сервера идёт через цепь промежуточных сертификатов к одному из этих корней. Если цепь не валидируется или домен в сертификате не совпадает с тем, который вы запросили, вы видите красную предупреждающую страницу. Эта модель цепи доверия — настоящая граница безопасности — украдите ключ подписи CA и вы сможете выпустить валидные сертификаты для любого домена, поэтому компрометация CA рассматривается как серьёзный инцидент.

Что здесь делают симметричная и асимметричная криптография

Асимметричная криптография (RSA или эллиптическая кривая) медленная и затратная, поэтому TLS использует её только во время рукопожатия — для аутентификации сервера и помощи в установлении общего секрета. После этого все реальные данные (HTML, JSON, что угодно) шифруются быстрыми симметричными cipher'ами. Этот гибридный подход — это же самое, что вы увидите в SSH, PGP и большинстве реальных криптосистем: асимметричная для идентичности и обмена ключами, симметричная для большого объёма данных.

Forward secrecy — связанная деталь, стоящая знания: потому что общий секрет происходит из временных Diffie-Hellman долей ключей, генерируемых заново для каждой сессии, даже если кто-то записал ваш трафик и позже украл приватный ключ сервера, они всё равно не смогут расшифровать старые сессии. Этого свойства не было в более старом RSA-only обмене ключами.

Проверка самому

Вы не должны слепо доверять зелёному значку замка. Запустите:

openssl s_client -connect example.com:443 -tls1_3

Это показывает вам согласованный cipher suite, цепь сертификатов и завершилось ли рукопожатие. Для быстрого взгляда на то, что видит браузер, curl -v https://example.com выводит версию TLS и детали сертификата перед HTTP-ответом.

Вы также можете расшифровать свой собственный трафик в Wireshark, если экспортируете переменную окружения SSLKEYLOGFILE перед запуском Chrome или Firefox — действительно полезно для отладки проблем TLS вместо угадывания.

Где это на самом деле ломается на практике

Большинство реальных HTTPS-сбоев — это не криптографические взломы, а операционные: истёкшие сертификаты, неправильно настроенные цепи промежуточных сертификатов, клиенты, застрявшие на старых версиях TLS, или смешанный контент (страница HTTPS загружает ресурс HTTP). Настоящие атаки на уровне протокола против современного TLS 1.3 редки, потому что спецификация закрыла большинство трюков с padding oracle и downgrade, которые мучили SSL 3.0 и ранний TLS. Слабые точки теперь обычно на конечных узлах — скомпрометированная CA, украденный приватный ключ или пользователь, кликнувший на предупреждение о сертификате, которое он не должен был.

Если вы хотите идти дальше, сегменты Korra Studio по сетям и криптографии охватывают базовую математику Diffie-Hellman и анализ протокола на уровне пакетов более глубоко.