Як працює SSL/TLS Handshake
SSL/TLS Handshake – "рукостискання" між сервером і клієнтом. Простіше кажучи – ідентифікація один одного. Відбувається під час HTTPS-з'єднання всередині зашифрованого тунелю SSL/TLS, який гарантує безпеку як серверу, так і клієнту. Після успішної ідентифікації генерується секретний сеансовий ключ, який забезпечує захищений зв'язок – він слугує одночасно як для шифрування, так і для дешифрування переданих даних.
Шифрування даних
Процес рукостискання обов'язково супроводжується обміном відомостями про підтримувані криптографічні технології – це необхідно для того, щоб сервер і клієнт узгодили оптимальний для обох сторін шифронабір. Після узгодження сервер передає клієнту свій SSL-сертифікат.
Симетричне шифрування запобігає можливості прочитання даних сторонніми особами. Крім того, навіть у разі перехоплення пакетів їх не вдасться змінити, оскільки кожне повідомлення містить код MAC, за допомогою яких перевіряється цілісність даних.
Як відбувається SSL/TLS-рукотиснення
Якщо уявити SSL-рукостискання як діалог між сервером і клієнтом, то процес матиме такий вигляд:
- Клієнт звертається до сервера з проханням встановити безпечне з'єднання і пропонує набір шифрів, які "розуміє", а також сумісну версію SSL/TLS.
- Сервер перевіряє надісланий шифронабір, порівнює зі своїм і надсилає відповідь клієнту з файлом сертифіката і відкритим ключем.
- Клієнт перевіряє сертифікат і, якщо все гаразд, пропонує перевірити закритий ключ. Для цього він його генерує і шифрує спільний секретний ключ за допомогою надісланого раніше відкритого ключа сервера.
- Сервер приймає ключ, перевіряє його своїм закритим ключем. Далі він створює головний секрет, який і буде використовуватися для шифрування обмінюваної інформації.
Після цього клієнт надсилає серверу тестове повідомлення, зашифроване за продуманим раніше методом, а той його розшифровує й аналізує. На цьому 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, тож ми рекомендуємо використовувати саме його.