SSL/TLS Проксі

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

Як працюють проксі-сервери SSL/TLS

Проксі-сервери SSL/TLS працюють за принципом "людина посередині" (MITM), але з явною метою мережевого управління або безпеки, а не зловмисного перехоплення. Процес включає два окремі рукостискання SSL/TLS:

1. Рукостискання Клієнт-Проксі: Коли клієнт ініціює з'єднання з ресурсом, захищеним SSL/TLS (наприклад, https://example.com), проксі-сервер перехоплює запит. Проксі-сервер динамічно генерує сертифікат SSL/TLS для example.com, підписаний довіреним кореневим центром сертифікації (CA), якому система клієнта довіряє неявно або явно. Потім клієнт встановлює безпечне з'єднання з проксі-сервером, вважаючи, що він спілкується безпосередньо з example.com.
2. Рукостискання Проксі-Сервер: Одночасно проксі-сервер встановлює власне безпечне з'єднання з фактичним сервером example.com. Він виконує стандартне рукостискання SSL/TLS з вихідним сервером, перевіряючи легітимний сертифікат сервера.

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

Щоб цей процес успішно завершився без попереджень браузера, кореневий сертифікат CA проксі-сервера повинен бути встановлений і довірений усіма клієнтами, трафік яких він має намір перехоплювати.

Типи проксі-серверів SSL/TLS

Проксі-сервери SSL/TLS класифікуються на основі контексту їх розгортання та напрямку трафіку.

Прямий проксі-сервер (перехоплення вихідного трафіку)

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

• Клієнт: Внутрішній користувач
• Розташування проксі-сервера: Між внутрішньою мережею та Інтернетом
• Призначення: Перевірка вихідних з'єднань, застосування політик безпеки, блокування шкідливих сайтів, запобігання витоку даних.
• Вимога до довіри: Кореневий CA проксі-сервера повинен бути встановлений на всіх внутрішніх клієнтських пристроях.

Зворотний проксі-сервер (перехоплення вхідного трафіку)

Зворотний проксі-сервер SSL/TLS перехоплює трафік, що надходить від зовнішніх клієнтів та призначений для внутрішніх серверів. Він розташовується перед одним або кількома веб-серверами, діючи як шлюз.

• Клієнт: Зовнішній користувач
• Розташування проксі-сервера: Між Інтернетом та внутрішніми веб-серверами
• Призначення: Балансування навантаження, функціональність WAF (брандмауер веб-додатків), захист від DDoS, розвантаження SSL/TLS, кешування вмісту, шлюз API.
• Вимога до довіри: Проксі-сервер використовує легітимний сертифікат SSL/TLS для домену (наприклад, example.com), якому зовнішні клієнти довіряють за замовчуванням. Йому не потрібно встановлювати спеціальний CA на клієнтські пристрої.

Випадки використання та переваги

Проксі-сервери SSL/TLS надають критично важливі можливості в різних операційних сферах.

Перевірка безпеки

• Виявлення шкідливого ПЗ: Сканує зашифрований трафік на наявність відомих сигнатур шкідливого ПЗ, командно-контрольних комунікацій та експлойт-комплектів, які можуть обійти традиційний захист периметра.
• Системи запобігання/виявлення вторгнень (IPS/IDS): Дозволяє глибоку перевірку пакетів зашифрованих даних для виявлення аномальної поведінки або відомих шаблонів атак.
• Запобігання втраті даних (DLP): Запобігає витоку конфіденційних даних (наприклад, PII, інтелектуальної власності) з мережі через зашифровані канали шляхом перевірки вихідного трафіку.
• Розширений захист від загроз (ATP): Сприяє ізоляції (sandboxing) та поведінковому аналізу підозрілих файлів, завантажених через SSL/TLS.

Відповідність вимогам та аудит

• Дотримання нормативних вимог: Допомагає організаціям відповідати вимогам відповідності (наприклад, HIPAA, GDPR, PCI DSS), забезпечуючи аудит всього мережевого трафіку, включаючи зашифрований, та його відповідність політиці.
• Судово-медичний аналіз: Надає розшифровані журнали мережевої активності для реагування на інциденти та посмертного аналізу.

Оптимізація продуктивності

• Розвантаження SSL/TLS: Зворотні проксі-сервери можуть обробляти обчислювально інтенсивний процес шифрування/розшифрування SSL/TLS, розвантажуючи його з бекенд-серверів та покращуючи їх продуктивність.
• Кешування: Розшифрований вміст може кешуватися проксі-серверами, зменшуючи навантаження на вихідні сервери та прискорюючи доставку вмісту для подальших запитів.
• Стиснення: Проксі-сервери можуть стискати вміст перед повторним шифруванням та відправленням клієнтам, зменшуючи використання пропускної здатності.

Фільтрація вмісту та застосування політик

• Фільтрація URL: Блокує доступ до певних категорій веб-сайтів або окремих URL-адрес, навіть якщо доступ здійснюється через HTTPS.
• Контроль додатків: Ідентифікує та контролює конкретні додатки або функції додатків, які використовують SSL/TLS, незалежно від порту.
• Географічні обмеження: Застосовує політики доступу на основі географічного походження або призначення трафіку.

Виклики та міркування

Впровадження та управління проксі-серверами SSL/TLS пов'язане з кількома технічними та операційними викликами.

Довіра та управління сертифікатами

Фундаментальною вимогою для функціонування проксі-сервера SSL/TLS без попереджень клієнта є встановлення його кореневого сертифіката CA на всіх клієнтських пристроях. Це може бути складно в великих, різноманітних середовищах і створює єдину точку довіри. Якщо ключ CA проксі-сервера буде скомпрометований, його можна буде використовувати для видачі себе за будь-який веб-сайт, що призведе до значних ризиків безпеки.

Наслідки для конфіденційності

Розшифровка всього зашифрованого трафіку викликає занепокоєння щодо конфіденційності, особливо для особистих пристроїв або в юрисдикціях із суворими законами про конфіденційність. Організації повинні чітко повідомляти користувачам свої політики та забезпечувати відповідність правовим рамкам.

Накладні витрати на продуктивність

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

Сумісність додатків

Деякі додатки використовують "закріплення сертифікатів" (certificate pinning), де вони жорстко кодують або закріплюють очікуваний сертифікат або відкритий ключ для певних доменів. Коли проксі-сервер SSL/TLS надає динамічно згенерований сертифікат, ці додатки виявлять невідповідність і відмовляться підключатися, що призведе до збоїв додатків. Поширені приклади включають банківські додатки, мобільні додатки та певні API. Часто необхідно виключити такі додатки з перехоплення.

Юридичні та етичні аспекти

Перехоплення зашифрованих комунікацій має значні юридичні та етичні наслідки. Організації повинні переконатися, що вони мають законне право та належне обґрунтування для перехоплення трафіку, особливо в сценаріях BYOD (Bring Your Own Device) або через міжнародні кордони з різними правовими рамками.

Концептуальний приклад конфігурації проксі-сервера

Поширений підхід до налаштування проксі-сервера SSL/TLS включає комбінацію управління центром сертифікації та конфігурації програмного забезпечення проксі-сервера.

Налаштування кореневого CA (концептуально)

По-перше, для підписання динамічно згенерованих сертифікатів потрібен внутрішній кореневий CA.

# Згенерувати приватний ключ кореневого CA
openssl genrsa -out ca.key 2048

# Створити сертифікат кореневого CA
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/C=US/ST=State/L=City/O=Org/CN=Internal CA"

Файл ca.crt повинен бути розповсюджений і довірений усіма клієнтськими пристроями, призначеними для перехоплення.

Конфігурація програмного забезпечення проксі-сервера (приклад з Nginx як концептуальний зворотний проксі-сервер)

Хоча Nginx є переважно зворотним проксі-сервером, його можливості розвантаження та перевірки SSL/TLS ілюструють принципи. Для прямого проксі-сервера використовувалося б спеціалізоване програмне забезпечення, таке як Squid з SSL Bump, або комерційні шлюзи безпеки.

# Приклад конфігурації Nginx для розвантаження SSL/TLS (зворотний проксі-сервер)
server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate /etc/nginx/certs/www.example.com.crt;
    ssl_certificate_key /etc/nginx/certs/www.example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "HIGH:!aNULL:!MD5";

    # Проксі-запити до бекенд-серверів додатків
    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

У сценарії повного перехоплення SSL/TLS для прямого проксі-сервера, програмне забезпечення проксі-сервера динамічно генеруватиме www.example.com.crt та www.example.com.key на льоту для кожного запитуваного домену, підписуючи їх своїм ca.key.