HTTPS CONNECT

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

Розуміння проксі-тунелювання за допомогою CONNECT

Коли клієнту потрібно отримати доступ до ресурсу через HTTPS, зв'язок має бути наскрізно зашифрованим між клієнтом та сервером-джерелом. Стандартний HTTP-проксі, який зазвичай працює шляхом читання та пересилання HTTP-запитів (GET, POST тощо), не може безпосередньо обробляти HTTPS-трафік, оскільки він не може розшифрувати дані без порушення TLS (Transport Layer Security) з'єднання. Метод CONNECT надає рішення, перетворюючи проксі на простий TCP-ретранслятор на час з'єднання.

Виклик зашифрованого трафіку для проксі

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

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

Як працює метод CONNECT

Процес встановлення HTTPS-тунелю за допомогою методу CONNECT включає окреме рукостискання між клієнтом та проксі, за яким слідує пряме TLS-рукостискання клієнта з сервером-джерелом через встановлений тунель.

1. Клієнт надсилає запит CONNECT проксі:
   Клієнт ініціює процес, надсилаючи HTTP-запит CONNECT проксі-серверу. Цей запит вказує цільовий хост та порт, до якого клієнт бажає підключитися. Порт для HTTPS зазвичай 443.

   http CONNECT www.example.com:443 HTTP/1.1 Host: www.example.com:443 Proxy-Connection: Keep-Alive User-Agent: MyApp/1.0
   Цей запит сигналізує проксі: "Встановити необроблене TCP-з'єднання з www.example.com на порті 443. Після підключення ретранслювати всі наступні дані між мною та цим сервером без перевірки."

2. Проксі встановлює з'єднання та відповідає:

   • Проксі отримує запит CONNECT і намагається встановити пряме TCP-з'єднання з www.example.com на порті 443.
   • Якщо це з'єднання успішно встановлено, проксі надсилає HTTP-відповідь 200 OK назад клієнту.

   http HTTP/1.1 200 Connection established Proxy-Agent: MyProxyService/1.0
   Ця відповідь 200 OK підтверджує клієнту, що TCP-тунель активний.

3. TLS-рукостискання та зашифрований зв'язок:

   • Отримавши 200 OK, клієнт припиняє надсилати HTTP-запити проксі. Натомість він починає надсилати необроблені повідомлення TLS-рукостискання безпосередньо до www.example.com через встановлений проксі-тунель.
   • Проксі, діючи виключно як ретранслятор, пересилає ці TLS-повідомлення, не намагаючись їх інтерпретувати або модифікувати.
   • Після успішного завершення TLS-рукостискання встановлюється наскрізний зашифрований канал між клієнтом та www.example.com. Всі наступні дані програми (наприклад, HTTP-запити та відповіді через HTTPS) безпечно проходять через цей тунель, повністю непрозорі для проксі.

Переваги тунелювання CONNECT

• Наскрізне шифрування: Основною перевагою є збереження наскрізного шифрування. Проксі ніколи не бачить відкритого вмісту зв'язку, забезпечуючи конфіденційність та цілісність даних між клієнтом та сервером-джерелом.
• Агностичний до протоколу: Хоча метод CONNECT переважно використовується для HTTPS, він може тунелювати будь-який TCP-протокол. Оскільки проксі просто ретранслює необроблені байти після встановлення тунелю, йому не потрібно розуміти інкапсульований протокол.
• Проходження брандмауера: CONNECT дозволяє клієнтам за обмежувальними брандмауерами отримувати доступ до зовнішніх служб (наприклад, безпечних веб-сайтів), направляючи весь трафік через один дозволений проксі-порт (зазвичай 80 або 443).
• Конфіденційність: Оскільки проксі не перевіряє тунельовані дані, вміст зв'язку залишається приватним між клієнтом та призначенням.

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

Стандартний CONNECT проти проксі-серверів перехоплення SSL/TLS

Стандартний CONNECT проксі, як описано, працює як сліпий ретранслятор. Він не виконує атаку "людина посередині" (MITM); він не розшифровує, не перевіряє та не перешифровує HTTPS-трафік. Браузер клієнта перевіряє сертифікат сервера-джерела безпосередньо, забезпечуючи автентичність з'єднання.

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

1. Перехоплення запиту CONNECT клієнта.
2. Встановлення власного TLS-з'єднання з сервером-джерелом.
3. Динамічне генерування нового SSL-сертифіката для запитуваного домену, підписаного користувацьким кореневим центром сертифікації (CA), контрольованим власником проксі.
4. Представлення цього згенерованого проксі-сертифіката клієнту.
5. Якщо клієнт налаштований довіряти користувацькому кореневому CA проксі (зазвичай шляхом встановлення його в сховище довіри операційної системи), він приймає сертифікат та встановлює TLS-з'єднання з проксі.
6. Потім проксі ефективно підтримує два окремі TLS-з'єднання: одне з клієнтом та одне з сервером-джерелом. Це дозволяє йому розшифровувати трафік від клієнта, інспектувати його та перешифровувати перед пересиланням до джерела, і навпаки.

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

Конфігурація проксі та CONNECT

Коли клієнтська програма або веб-браузер налаштовані на використання HTTP-проксі, вони автоматично визначають, чи використовувати стандартний HTTP-метод (наприклад, GET або POST для незашифрованого HTTP) або метод CONNECT (для зашифрованого HTTPS) на основі схеми цільового URL.

Наприклад, якщо браузер налаштований на використання proxy.example.com:8080:
* Запит до http://www.unencrypted.com призводить до надсилання GET http://www.unencrypted.com HTTP/1.1 до proxy.example.com:8080.
* Запит до https://www.encrypted.com призводить до надсилання CONNECT www.encrypted.com:443 HTTP/1.1 до proxy.example.com:8080.

Порівняння: HTTP-проксі проти HTTPS-проксі (через CONNECT)

Практичні наслідки для користувачів

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

• Сумісність з брандмауером: При налаштуванні клієнта на використання проксі переконайтеся, що локальні правила брандмауера дозволяють вихідні з'єднання до IP-адреси та порту проксі-сервера (наприклад, proxy.service.com:8080). Потім проксі керує з'єднанням до кінцевого призначення.
• Продуктивність: Накладні витрати, пов'язані з тунелюванням CONNECT, мінімальні, в основному включаючи початковий запит CONNECT та відповідь. Після встановлення тунелю продуктивність передачі даних значною мірою залежить від затримки мережі та пропускної здатності між клієнтом, проксі та сервером-джерелом.
• Усунення несправностей: Якщо виникають проблеми з HTTPS-сайтами під час використання проксі, перевірте наступне:
  • Правильна конфігурація хоста та порту проксі в клієнтській програмі або браузері.
  • Успішне мережеве з'єднання від вашого клієнта до проксі-сервера.
  • Що проксі-сервер не налаштований на блокування доступу до конкретного хоста або порту призначення.