Як TLS насправді захищає HTTPS-з'єднання?

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

Handshake крок за кроком

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

1. ClientHello — браузер надсилає підтримувані cipher suite, випадковий nonce та припущення про key share (використовуючи щось на кшталт X25519 або secp256r1) для обміну ключами.
2. ServerHello — сервер вибирає cipher suite, надсилає свій key share та повертає свій сертифікат плюс підпис, що доводить, що він володіє приватним ключем, який відповідає цьому сертифікату.
3. Key derivation — обидві сторони незалежно обчислюють той самий спільний секрет, використовуючи математику у стилі Diffie-Hellman на своїх key share. Жодна сторона ніколи не передає сам секрет; він розраховується, а не надсилається.
4. Finished messages — обидві сторони підтверджують, що handshake не був змінений, надсилаючи MAC над усім handshake transcript.

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

Чому сертифікат важливіший за шифрування

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

Ваш браузер довіряє фіксованому списку root CA, вбудованому в ОС або хранилище довіри браузера. Сертифікат сервера ланцюжком піднімається через проміжні сертифікати до одного з цих коренів. Якщо ланцюжок не валідується або домен у сертифікаті не збігається з тим, який ви запросили, ви бачите червону сторінку попередження. Ця модель ланцюга довіри — це справжня межа безпеки — украй приватний ключ CA, і ви можете видавати валідні сертифікати для будь-якого домену, тому компрометації CA розглядаються як серйозні інциденти.

Що роблять тут симетричне та асиметричне шифрування

Асиметричне шифрування (RSA або еліптична крива) повільне і дороге, тому TLS використовує його тільки під час handshake — для аутентифікації сервера та допомоги у встановленні спільного секрету. Як тільки це зроблено, всі фактичні дані (HTML, JSON, що завгодно) шифруються швидкими симетричними шифрами. Цей гібридний підхід — той самий паттерн, який ви побачите в SSH, PGP та більшості реальних систем шифрування: асиметричне для ідентичності та обміну ключами, симетричне для масивних даних.

Forward secrecy — пов'язаний деталь, варто її знати: оскільки спільний секрет походить від недовічних Diffie-Hellman key share, які генеруються свіжо для кожної сесії, навіть якщо хтось записує ваш трафік і пізніше крадіжку приватного ключа сервера, вони все одно не можуть розшифрувати старі сесії. Ця властивість не існувала в старшому RSA-only обміні ключами.

Перевірка самостійно

Вам не потрібно сліпо довіряти значку зеленого замка. Запустіть:

openssl s_client -connect example.com:443 -tls1_3

Це показує вам узгоджений cipher suite, ланцюжок сертифіката та чи дійсно завершився handshake. Для швидшого погляду на те, що бачить браузер, 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 та аналіз протоколу на рівні пакетів більш детально.