TLS: протокол, що стоїть за кожною піктограмою замка

SSL → TLS: хронологічна історія

Netscape Communications розробила першу реалізацію SSL у 1994 році для захисту онлайн-покупок у абсолютно новому браузері Netscape Navigator. SSL 1.0 ніколи не був публічно випущений, оскільки він мав критичні недоліки. SSL 2.0, надісланий у лютому 1995 року, був негайно зламаний, а SSL 3.0 пішов у 1996 році як майже повний перепис.

I У 1999 році IETF перейняла протокол і перейменувала його в Transport Layer Security, щоб відзначити перехід від продукту Netscape до відкритого стандарту. Історія версій з:

• TLS 1.0 (січень 1999 р., RFC 2246) — по суті SSL 3.1.
• TLS 1.1 (квітень 2006 р., RFC 4346) — захищено від атак CBC через явні вектори ініціалізації.
• TLS 1.2 (серпень 2008, RFC 5246) — додано шифри AEAD, SHA-256, настроювані алгоритми підпису. Домінування протягом десятиліття.
• TLS 1.3 (серпень 2018 р., RFC 8446) — серйозний редизайн. Вилучено застарілу помилку, обов’язкову пряму секретність, скорочену затримку рукостискання.

SSL 3.0 офіційно застарів у червні 2015 року (RFC 7568) після POODLE. TLS 1.0 і 1.1 були припинені в березні 2021 року (RFC 8996). У 2026 році сучасні сервери повинні відмовитися від усього, що нижче TLS 1.2, і віддати перевагу TLS 1.3.

Як насправді працює рукостискання

Кожне з’єднання TLS починається з рукостискання, яке виконує три речі: узгоджує набір шифрів, підтверджує ідентичність сервера та отримує спільні ключі для решти сесії.

TLS 1.2 рукостискання (класичний потік)

1. ClientHello: клієнт надсилає підтримувані версії TLS, набори шифрів і випадкове число.
2. ServerHello: сервер вибирає один набір шифрів, надсилає його випадкове число.
3. Certificate: сервер надсилає свій ланцюжок сертифікатів X.509, щоб клієнт міг перевірити особу.
4. ServerKeyExchange: сервер надсилає свій відкритий ключ Діффі-Хеллмана (для ефемерного ключа обмін).
5. ClientKeyExchange: клієнт надсилає свій відкритий ключ DH. Обидві сторони тепер отримують той самий спільний секрет.
6. Завершено: обидві сторони підтверджують рукостискання, надсилаючи MAC-адресу по всій транскрипції.

Це два повних проходження, перш ніж перший байт програми може передати. На посиланні із затримкою 100 мс кожне нове з’єднання HTTPS споживає 200 мс перед тим, як будь-який фактичний вміст буде переміщено. Рукотискання

TLS 1.3 (сучасний потік)

TLS 1.3 згортає рукостискання до одного зворотного зв’язку в загальному case:

1. ClientHello: містить відкритий ключ DH клієнта для кожної групи шифрів, яку підтримує клієнт.
2. ServerHello + все інше: сервер вибирає групу, надсилає свій відкритий ключ DH, сертифікат і Готово, все в одному політ.
3. Клієнт перевіряє та відповідає власним Finished.

Одна поїздка туди й назад, два рейси. З відновленням сеансу (0-RTT) клієнт може навіть розпочати надсилання даних зі своїм першим повідомленням — ціною деяких властивостей прямої секретності для цих початкових даних.

Що TLS 1.3 видалив

TLS 1.3 ще одним важливим кроком було видалення. Вийшло:

• Статичний обмін ключами RSA (порушена конфіденційність). Шифри в режимі
• CBC (вразливі до BEAST і Lucky Thirteen). Поточний шифр
• RC4 (давно зламаний).
• MD5 і хеші SHA-1 для підписи.
• Повторне узгодження (замінено автентифікацією після рукостискання).
• Стиснення (клас атак CRIME).
• Користувацькі параметри Діффі-Хеллмана (виправлення затримок).

Список набору шифрів збільшився з ~300 у TLS 1.2 до 5 у TLS 1.3. Менше мотузки, на якій можна повіситися.

Історія атак, яка сформувала TLS

• BEAST (2011) — атака вибраного відкритого тексту в режимі CBC у TLS 1.0. Виправлено у версії 1.1+ через явні IVs.
• CRIME (2012) — використовувалося стиснення TLS для відновлення файлів cookie сеансу. Виправлено шляхом вимкнення стиснення.
• BREACH (2013) — еквівалент CRIME стиснення на рівні HTTP. Пом’якшено шляхом вимкнення стиснення HTTP для конфіденційних відповідей.
• Heartbleed (квітень 2014) — помилка OpenSSL, а не проблема специфікації TLS. Витік пам'яті сервера, включаючи приватні ключі. Подія масової ротації сертифікатів у мережі.
• POODLE (жовтень 2014) — використовуваний резервний варіант SSL 3.0. Знищив SSL 3.0 у браузерах протягом кількох тижнів.
• Logjam (2015) — показав, що невеликі групи Діффі-Хеллмана (особливо 1024-бітна група 2, яка широко використовується в IPsec/IKE) були в межах досяжності зловмисників з національних держав. Вимушена галузева міграція до більших груп і еліптичної кривої DH.
• Lucky Thirteen (2013) — атака на синхронізацію в режимі CBC. Виправлення на рівні бібліотеки в OpenSSL та інших.

Кожна атака посилювала протокол. У TLS 1.3 більшість із цих класів неможливі.

Центри сертифікації та проблема довіри

TLS автентифікація покладається на центри сертифікації (CA), яким браузери довіряють за умовчанням. Трійка лідерів за часткою ринку з 2019 року: IdenTrust, DigiCert і Sectigo. Let's Encrypt — безкоштовний автоматизований центр сертифікації, запущений у 2016 році — став найбільшим поштовхом до впровадження HTTPS в історії.

Структурний недолік: будь-який довірений ЦС може видати сертифікат для будь-якого домену. Скомпрометований або примусовий ЦС може викарбувати дійсний сертифікат для вашого банку. Для виявлення цього було введено журнали Certificate Transparency (CT) — загальнодоступні записи лише для додавання кожного коли-небудь виданого сертифіката. Браузери тепер вимагають, щоб сертифікати з’являлися в журналах CT, перш ніж вони їх приймуть.

ЦС/Форум браузерів схвалив скорочення максимального терміну дії сертифіката до 47 днів до 2029 року, звужуючи вікно, протягом якого скомпрометований ЦС може завдати шкоди.

Зашифрований клієнт Привіт (ECH)

Одна річ, класичний TLS витоки: поле індикації імені сервера (SNI) у ClientHello, яке повідомляє серверу, до якого імені хоста ви підключаєтеся, щоб він міг представити правильний сертифікат. SNI є відкритим текстом, тому мережеві спостерігачі вивчають кожен домен, який ви відвідуєте, навіть якщо решта з’єднання зашифровано.

Encrypted Client Hello (ECH) — еволюція попередньої пропозиції ESNI — шифрує SNI за допомогою відкритого ключа, який адресат публікує через DNS. Cloudflare і Apple надали підтримку ECH; Firefox і Chrome розгорнули його без прапорів до 2024 року та рухаються до стандартного стану. Для користувачів у ворожих мережах ECH — це наступне оновлення конфіденційності після універсального HTTPS.

DTLS — TLS для UDP

DTLS (Datagram TLS) — це варіант TLS, який працює через UDP. Він підтримує WebRTC (відео/голос у веб-переглядачі), основну безпеку QUIC і кілька протоколів VPN. DTLS 1.3 (RFC 9147, 2022) збігається з модернізацією рукостискання та шифру TLS 1.3.

Постквантовий обмін ключами TLS

Diffie-Hellman — основа прямої секретності TLS — може бути зламаний досить великим квантовим комп’ютером. Виправлення полягає в гібридному обміні ключами, який поєднує класичний алгоритм (X25519) із постквантовим кандидатом (як правило, ML-KEM-768, раніше відомий як Kyber).

Chrome увімкнув гібрид X25519MLKEM768 за замовчуванням наприкінці 2024 року. Cloudflare, Apple iCloud і кілька VPN постачальники постачали його до 2025 року. Більш широке розгортання захищає сьогоднішній трафік від атаки «збирай зараз, розшифруй пізніше» — зловмисник записує зашифрований трафік сьогодні, чекає на квантові комп’ютери, а потім розшифровує історично.

Як перевірити TLS, який ваш веб-переглядач насправді використовує

Натисніть замок в адресному рядку веб-переглядача. Сучасні браузери показують версію протоколу, набір шифрів і деталі сертифіката. Якщо ви бачите TLS 1.0 або 1.1, на сайті використовуються застарілі конфігурації. Якщо ви бачите TLS 1.3 із AES-256-GCM або ChaCha20-Poly1305, ви використовуєте сучасне крипто.

Супутня технологія HTTPS — , описана в нашому поясненні HTTPS — це те, що загортає Інтернет у TLS. Ці два терміни часто використовуються в розмовній мові як взаємозамінні, але TLS є основним криптографічним протоколом; HTTPS — це просто HTTP-over-TLS.