Рукостискання TLS

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

Розуміння рукостискання TLS

Протокол Transport Layer Security (TLS) є фундаментальним для забезпечення безпеки інтернет-комунікацій. Він працює над транспортним рівнем (TCP) і забезпечує наскрізне шифрування та автентифікацію. Рукостискання TLS — це початкова фаза узгодження, під час якої клієнт і сервер домовляються про криптографічні параметри та встановлюють безпечну сесію перед обміном даними програми.

Основні цілі рукостискання TLS:
* Автентифікація: Перевірка особи сервера (і, за бажанням, клієнта) за допомогою цифрових сертифікатів.
* Обмін ключами: Безпечне узгодження спільного секретного ключа для симетричного шифрування.
* Узгодження набору шифрів: Вибір алгоритмів для шифрування, хешування та обміну ключами.

Етапи прямого рукостискання TLS

При прямому з'єднанні без проксі-сервера рукостискання TLS відбувається наступним чином:

1. Client Hello: Клієнт ініціює рукостискання, надсилаючи повідомлення Client Hello. Це повідомлення включає:
   • Підтримувані версії TLS.
   • Список підтримуваних наборів шифрів.
   • Випадковий байтовий рядок (Client Random).
   • Підтримувані методи стиснення.
   • Індикація імені сервера (SNI) для віртуального хостингу.
2. Server Hello: Сервер відповідає повідомленням Server Hello, вибираючи:
   • Версію TLS для використання.
   • Вибраний набір шифрів зі списку клієнта.
   • Випадковий байтовий рядок (Server Random).
3. Сертифікат: Сервер надсилає свій цифровий сертифікат, який містить його публічний ключ і підписаний центром сертифікації (CA). Клієнт перевіряє цей сертифікат.
4. Server Key Exchange (Необов'язково): Якщо вибраний набір шифрів цього вимагає (наприклад, для Diffie-Hellman ephemeral), сервер надсилає параметри для обміну ключами.
5. Server Hello Done: Сервер вказує, що він завершив свою частину початкового рукостискання.
6. Client Key Exchange: Клієнт генерує попередній майстер-секрет, шифрує його публічним ключем сервера (з його сертифіката) і надсилає його серверу.
7. Change Cipher Spec (Клієнт): Клієнт надсилає повідомлення Change Cipher Spec, вказуючи, що всі наступні повідомлення будуть зашифровані за допомогою узгоджених ключів та набору шифрів.
8. Зашифроване повідомлення рукостискання (Клієнт): Клієнт надсилає повідомлення Finished, зашифроване щойно встановленим симетричним ключем, для перевірки цілісності рукостискання.
9. Change Cipher Spec (Сервер): Сервер надсилає власне повідомлення Change Cipher Spec.
10. Зашифроване повідомлення рукостискання (Сервер): Сервер надсилає своє повідомлення Finished, також зашифроване.
11. Дані програми: Обидві сторони тепер можуть обмінюватися зашифрованими даними програми.

Типи проксі та взаємодія рукостискання TLS

Проксі-сервери змінюють спосіб ініціації та обробки рукостискання TLS залежно від їхнього режиму роботи.

Прямий проксі (без перехоплення)

Прямий проксі діє як посередник для клієнтів, які бажають отримати доступ до зовнішніх ресурсів. Для трафіку HTTPS прямий проксі без перехоплення зазвичай працює як TCP-тунель. Клієнт явно налаштовує себе на використання проксі.

Механізм:
Клієнт надсилає HTTP-запит CONNECT проксі-серверу для встановлення TCP-тунелю до вихідного сервера. Після встановлення тунелю клієнт і вихідний сервер виконують рукостискання TLS безпосередньо через цей тунель. Проксі пересилає зашифровані байти, не розшифровуючи їх.

Потік рукостискання TLS:
1. Клієнт до проксі (TCP): Клієнт встановлює TCP-з'єднання з проксі.
2. Запит CONNECT від клієнта: Клієнт надсилає HTTP-запит CONNECT проксі-серверу, вказуючи ім'я хоста та порт вихідного сервера (наприклад, CONNECT example.com:443 HTTP/1.1).
3. Проксі до джерела (TCP): Проксі встановлює TCP-з'єднання з вказаним вихідним сервером.
4. Проксі 200 OK: Якщо з'єднання з вихідним сервером успішне, проксі відповідає клієнту HTTP/1.1 200 Connection established.
5. Клієнт до джерела (TLS через тунель): Клієнт, отримавши 200 OK, ініціює стандартне рукостискання TLS безпосередньо з вихідним сервером через встановлений TCP-тунель.
6. Пересилання проксі: Проксі прозоро пересилає всі наступні зашифровані байти між клієнтом і вихідним сервером. Він не бере участі в рукостисканні TLS і не розшифровує трафік.

Приклад коду: Запит CONNECT від клієнта

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive

Відповідь проксі

HTTP/1.1 200 Connection established

Зворотний проксі (завершення TLS)

Зворотний проксі розташовується перед одним або кількома вихідними серверами та перехоплює запити клієнтів, призначені для цих серверів. Для трафіку HTTPS зворотний проксі часто виконує завершення TLS.

Механізм:
Зворотний проксі отримує HTTPS-запит клієнта, завершує TLS-з'єднання, розшифровує трафік, а потім встановлює нове з'єднання (яке може бути або не бути зашифрованим TLS) до внутрішнього вихідного сервера.

Потік рукостискання TLS:
1. Клієнт до зворотного проксі (Рукостискання TLS 1):
* Клієнт виконує стандартне рукостискання TLS безпосередньо зі зворотним проксі.
* Зворотний проксі надає клієнту свій власний цифровий сертифікат.
* Між клієнтом і зворотним проксі встановлюється безпечний, зашифрований канал.
2. Розшифрування зворотним проксі: Зворотний проксі розшифровує запит клієнта.
3. Зворотний проксі до джерела (Рукостискання TLS 2 або HTTP):
* Зворотний проксі потім ініціює нове з'єднання до відповідного внутрішнього вихідного сервера.
* Це з'єднання може бути звичайним HTTP (поширено в довірених внутрішніх мережах) або іншим TLS-зашифрованим з'єднанням (для наскрізного шифрування).
* Якщо використовується TLS, зворотний проксі діє як клієнт і виконує друге рукостискання TLS з вихідним сервером, який надає свій власний сертифікат.
4. Обробка джерелом: Вихідний сервер обробляє запит і надсилає відповідь назад до зворотного проксі.
5. Шифрування зворотним проксі: Якщо з'єднання з клієнтом було TLS, зворотний проксі повторно шифрує відповідь, використовуючи ключі TLS-сесії, зверненої до клієнта.
6. Зворотний проксі до клієнта: Зашифрована відповідь надсилається назад клієнту.

Прозорий проксі (перехоплення TLS за принципом MITM)

Прозорий проксі перехоплює трафік без явного налаштування клієнта на його використання. Для HTTPS це зазвичай передбачає підхід "людина посередині" (Man-in-the-Middle, MITM).

Механізм:
Коли клієнт намагається підключитися до HTTPS-сайту, прозорий проксі перехоплює з'єднання. Він генерує фальшивий сертифікат для запитуваного домену, підписаний власним кореневим CA. Клієнт виконує рукостискання TLS з проксі, який потім виконує інше рукостискання TLS з вихідним сервером. Це дозволяє проксі розшифровувати, перевіряти та потенційно змінювати трафік. Щоб це працювало без помилок сертифіката, кореневий сертифікат CA проксі має бути довіреним для клієнта. Це поширено в корпоративних середовищах для моніторингу безпеки.

Порівняння типів проксі та взаємодії TLS

Міркування щодо безпеки

При встановленні безпечних з'єднань через проксі виникає кілька наслідків для безпеки:

• Довіра до проксі:
  • Прямий проксі: Оскільки проксі лише тунелює зашифровані дані, вимоги до довіри щодо конфіденційності даних мінімальні. Однак проксі потенційно може реєструвати метадані з'єднання (IP-адреси, домени).
  • Зворотний проксі / Прозорий проксі (MITM): Ці проксі розшифровують трафік. Довіра до оператора проксі стає першочерговою, оскільки він має доступ до розшифрованих конфіденційних даних. Для прозорих MITM-проксі клієнт повинен явно довіряти кореневому CA проксі, зазвичай встановлюючи його в сховище довіри системи.
• Прив'язка сертифікатів (Certificate Pinning): Програми, які використовують прив'язку сертифікатів, можуть не працювати при підключенні через зворотний проксі або прозорий MITM-проксі, оскільки проксі надає інший сертифікат, ніж очікуваний сертифікат вихідного сервера. Це функція безпеки, розроблена для запобігання MITM-атакам.
• Примусове використання версії TLS та набору шифрів: Проксі можуть бути налаштовані на примусове використання певних версій TLS та наборів шифрів, підвищуючи безпеку шляхом заборони застарілих або слабких криптографічних протоколів, навіть якщо клієнт або вихідний сервер їх підтримує.
• Ведення журналів та аудит: Проксі, особливо зворотні та прозорі типи, можуть надавати широкі можливості ведення журналів для розшифрованого трафіку, допомагаючи в аудиті безпеки та реагуванні на інциденти.
• Накладні витрати на продуктивність: Завершення TLS на проксі створює обчислювальні накладні витрати на шифрування та розшифрування, що необхідно враховувати в середовищах з високим трафіком. Для зменшення цього часто використовується апаратне прискорення (наприклад, розвантаження SSL).