Як працює SSL/TLS Handshake

SSL/TLS Handshake – "рукостискання" між сервером і клієнтом. Простіше кажучи – ідентифікація один одного. Відбувається під час HTTPS-з'єднання всередині зашифрованого тунелю SSL/TLS, який гарантує безпеку як серверу, так і клієнту. Після успішної ідентифікації генерується секретний сеансовий ключ, який забезпечує захищений зв'язок – він слугує одночасно як для шифрування, так і для дешифрування переданих даних.

Шифрування даних

Процес рукостискання обов'язково супроводжується обміном відомостями про підтримувані криптографічні технології – це необхідно для того, щоб сервер і клієнт узгодили оптимальний для обох сторін шифронабір. Після узгодження сервер передає клієнту свій SSL-сертифікат.

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

Як відбувається SSL/TLS-рукотиснення

Якщо уявити SSL-рукостискання як діалог між сервером і клієнтом, то процес матиме такий вигляд:

1. Клієнт звертається до сервера з проханням встановити безпечне з'єднання і пропонує набір шифрів, які "розуміє", а також сумісну версію SSL/TLS.
2. Сервер перевіряє надісланий шифронабір, порівнює зі своїм і надсилає відповідь клієнту з файлом сертифіката і відкритим ключем.
3. Клієнт перевіряє сертифікат і, якщо все гаразд, пропонує перевірити закритий ключ. Для цього він його генерує і шифрує спільний секретний ключ за допомогою надісланого раніше відкритого ключа сервера.
4. Сервер приймає ключ, перевіряє його своїм закритим ключем. Далі він створює головний секрет, який і буде використовуватися для шифрування обмінюваної інформації.

Після цього клієнт надсилає серверу тестове повідомлення, зашифроване за продуманим раніше методом, а той його розшифровує й аналізує. На цьому SSL/TLS Handshake завершується, і клієнт із сервером можуть спокійно обмінюватися інформацією далі.

Якщо сеанс буде завершено, і через певний час клієнт знову звертається до сервера, проходити заново процедуру "рукостискання" не буде потрібно – всі згенеровані раніше дані і головний секрет збережуть свою актуальність. Весь цей процес займає лічені секунди і проходить абсолютно непомітно для користувача.



Алгоритм Діффі-Геллмана в TLS Handshake 1.2

Версія протоколу TLS 1.2 з'явилася 2008 року як велике оновлення протоколу 1.1 з поліпшеним механізмом узгодження сторонами списків підтримуваних методів шифрування. Має такий вигляд:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Тут:

• TLS – протокол передавання даних;
• ECDHE – тимчасовий (ефемерний) ключ;
• ECDSA – алгоритм автентифікації;
• AES 128 GCM – алгоритм симетричного шифрування;
• SHA256 – алгоритм хешування даних.

Це і є алгоритм Діффі-Геллмана, але на сьогодні він уже вважається застарілим і рідко де використовується.

Шифронабори TLS 1.3

Ця версія протоколу побачила світ у 2018 році і зазнала низки істотних поліпшень:

• розділено процеси узгодження ключів, аутентифікацій і набори шифрування;
• додано правило, яке стверджує обов'язковість наявності цифрового підпису;
• впроваджено функцію отримання ключа HKDF;
• прискорено процеси з'єднання;
• заборонено стиснення даних, шифри без автентифікації повідомлень і неузгодження, які забезпечували певну вразливість попередньої версії протоколу;
• додали потоковий шифр ChaCha20 з MAC кодом Poly1305, ефективні алгоритми цифрового підпису Ed25519 і Ed448, а також відповідні їм протоколи обміну ключами Curve25519 і Curve448.

Виглядає шифронабір рукостискання TLS 1.3 так:

TLS_AES_256_GCM_SHA384

Відповідно, тут:

• TLS – протокол;
• AES-256 у режимі GCM – алгоритм шифрування та аутентифікації з додатковими даними (AEAD);
• SHA384 – алгоритм функції формування хешованого ключа (HKFD).

Протокол TLS 1.3 зазнав величезної кількості змін і поліпшень, що позитивно позначилося на безпеці та продуктивності процесів Handshake, а сама аутентифікація стала займати значно менше часу. Швидкість рукостискання збільшилася майже в 2 рази, водночас протокол позбувся кількох вразливостей, які раніше доставляли чимало проблем системним адміністраторам.

Висновок

Найбезпечніший варіант – криптографічний протокол TLS 1.3, але він має специфічну зворотну сумісність. Під час встановлення з'єднання клієнт і сервер обмінюються версіями протоколу і вибирається той, з яким можуть працювати обидві сторони. Однак на практиці виявилося, що деяка кількість серверів на старому протоколі TLS 1.2 миттєво обривали з'єднання в разі, якщо процес "рукостискання" повинен був відбутися через протокол TLS 1.3. Цей феномен було названо осифікацією, і через нього в перші роки виникали проблеми з впровадженням нового протоколу. На сьогодні ця проблема не зустрічається практично ніде, а самі сервери здебільшого перейшли на TLS 1.3, тож ми рекомендуємо використовувати саме його.