Кишеньковий термометр

Відкритий обмін: ClientHello та ServerHello

Клієнтський handshake починається в момент, коли браузер встановлює з’єднання з веб-сервером. Він надсилає повідомлення під назвою ClientHello, яке перераховує версії TLS та набори шифрів (комбінації алгоритмів шифрування, обміну ключами та хешування), які може використовувати браузер, а також випадкове число. Це випадкове значення не є декоративним; воно пізніше буде змішане у формулу, яка генерує шифр для сеансу, гарантуючи, що жодні два з’єднання ніколи не отримають однакові ключі, навіть якщо все інше в сеансі виглядає ідентично. Сервер відповідає повідомленням ServerHello. Він обирає один набір шифрів зі списку браузера, найсильніший із них, який він також підтримує, та генерує власне випадкове число. На цьому етапі жодна сторона не погоджується на будь-яку секретну інформацію; вони просто погоджуються на правила розмови. Сервер також прикріплює свій цифровий сертифікат на цьому етапі, що ініціює наступний критичний етап. Цей весь відвідувальний round trip є коротким, але це фундамент, на якому залежить кожен пізній криптографічний крок, оскільки узгоджений набір шифрів визначає, які саме алгоритми обміну ключами та шифрування будуть використовуватися для решту handshake та всього сеансу.

Довіра до незнайомця: Перевірка сертифікату та ланцюг довіри

Узгодження на використання алгоритмів шифрування означає нічого, якщо ви шифруєте дані для шахрая, тому браузер повинен підтвердити, що сервер є тим, ким він себе називає. Сертифікат сервера містить його доменне ім’я, публічний ключ та цифрову підпис Відмінного Центру (CA). Браузер перевіряє цей підпис проти вбудованого списку довірених CA, так само як ви можете довіряти новому документу, тому що новий документ запечатаний відомим вам нотаріусом. Часто підписуючий CA не знаходиться у списку довірених браузером, а є проміжним органом, тому браузер йде ланцюжком довіри від сертифіката сервера до проміжного сертифікату до кореневого сертифікату, який вбудований в операційну систему або браузер. Якщо кожен зв’язок у цьому ланцюжку перевіряється, сертифікат не закінчився та не було відкликано, а доменне ім’я відповідає відвідуваному сайту, браузер приймає заяву про ідентичність. Якщо будь-що з цього не вдасться, ви отримаєте знайому сторінку попередження, що з’єднання не є приватним. Цей крок важливий, оскільки це єдина частина рукоздавання, яка захищає від того, щоб незнайомця просто видавав себе за ваш банк; без нього шифрування само по собі із задоволенням б збереже розмову з нападником.

Ключовий обмін та захист від прориву

Після того, як браузер довіряє ідентичності сервера, обидві сторони повинні узгодити спільний секрет, який можна використовувати для фактичного шифрування, не передаючи цей секрет у відкритому вигляді по мережі. Це робить публічну криптографію корисною. У сучасному TLS 1.3 це практично завжди виконується за допомогою Diffie-Hellman або, більш конкретно, Elliptic-Curve Diffie-Hellman (ECDHE). Кожна сторона генерує тимчасовий ключний пар лише для однієї сесії, обмінюється публічними частками та комбінує їх математично зі своїм приватним частиною, щоб незалежно дійти ідентичного спільного секрету, який ніхто не може відтворити під час обміну. Важливе слово – тимчасовий: оскільки ці пари ключів генеруються свіжою кожну сесію та викидаються після цього, вони не пов’язані з довготривалим приватним ключем сервера сертифіката. Це дає TLS 1.3 властивість захисту від прориву вперед: навіть якщо нападник пізніше викраде постійний приватний ключ сервера, він не зможе повернутися та розшифрувати трафік сеансу, який було записано місяць тому, оскільки ключ, який насправді захищав цей трафік, ніколи не існував ніде, крім тимчасово в пам’яті кожної сторони під час цього одного рукошляпу.

Чому переходити на симетричне шифрування для реальних даних

Все, що описано вище, перевірка сертифікатів та обмін Диффі-Hellмана, базується на асиметричному шифруванні, яке є математично дорогим і відносно повільним, оскільки передбачає великі числові операції, такі як модульна експонентація або множення точок еліптичної кривої. Використання цього для кожного байта відеопотоку або великого файлу завантаження було б непрактичним. Тому обмін існує виключно для запуску чогось простішого: спільного симетричного сеансового ключа. Після того, як обидві сторони отримали цей ключ через обмін вище, вони перемикаються на сильне шифрування, найчастіше AES (або новіше ChaCha20), де той самий ключ і шифрує, і розшифровує дані. Симетричні алгоритми значно швидші, часто в рази, і добре підходять для шифрування безперервного потоку даних у реальному часі. Це розділення праці є патерном, що лежить в основі майже всіх практичних зашифрованих комунікацій: використовуйте повільне, потужне асиметричне шифрування короткочасно для вирішення складної проблеми безпечного узгодження ключів між незнайомцями, а потім передавайте до швидкого симетричного шифрування для фактичної обробки великої кількості даних сеансу, тому зашифрований веб-перегляд по суті відчувається так само швидко, як і незашифрований веб-перегляд десятиліття тому.

Менше поїздок: Як TLS 1.3 Пришвидшив Процес

Старі handshake TLS 1.2 зазвичай потребували двох повних поїздок між браузером та сервером перед тим, як будь-який застосунок передавав дані: одна поїздка для узгодження шифрування та обміну випадковими даними, а друга – окрема для обміну ключами та підтвердження шифрування. Кожна поїздка коштувала часу, особливо на мобільних мережах з високою затримкою, і цей час оплачувався при кожному новому з’єднанні. TLS 1.3, стандартизований у 2018 році, переробив потік, щоб він був значно стрункішим. Він об'єднав процес узгодження та обмін ключами в одну поїздку: ClientHello тепер включає оцінене клієнтом параметри обміну ключами (його публічний ECDHE значення) разом зі списком шифрування, щоб сервер міг відповісти ServerHello, сертифікатом і підтвердженням отриманого ключа в один момент. Це часто називають handshake 1-RTT, що скорочує затримку налаштування приблизно вдвічі порівняно з TLS 1.2. TLS 1.3 також запровадив ще швидший режим відновлення 0-RTT для сайтів, які ви відвідували раніше, дозволяючи браузеру надсилати початкові застосунок дані у першому ж повідомленні, за рахунок незначного зниження захисту від повторного відтворення для цих даних. TLS 1.3 також повністю видалив старіші, слабкі варіанти шифрування, що спростило протокол і закрив цілі категорії атак на пониження, які переслідували TLS 1.2.

Frequently asked questions

Спробуйте наживо

Усе, що вище, працює прямо у вашому браузері — відкрийте The TLS Handshake: How Your Browser Sets Up a Secure Connection і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.