Интеграция корпоративного прокси-сервера в мобильное приложение
Корпоративные мобильные приложения часто работают в среде с принудительным HTTPS-прокси — Zscaler, BlueCoat, Cisco Umbrella, squid. Пользователи подключаются через MDM-профиль (Mobile Device Management), который устанавливает системные настройки прокси. Приложение должно читать эти настройки и использовать их, а не игнорировать — иначе трафик будет блокирован или пойдёт в обход корпоративной политики безопасности.
Как мобильные ОС передают настройки прокси
Android: системные настройки прокси доступны через ConnectivityManager и свойства LinkProperties. Для HTTP/HTTPS — ProxyInfo с полем host и port. Для PAC (Proxy Auto-Config) — URL скрипта. OkHttp читает системный прокси автоматически при использовании OkHttpClient.Builder() без явного proxy() — если не переопределять, он использует ProxySelector.getDefault().
Проблема: ProxySelector работает для HTTP/HTTPS, но не для WebSocket (ws://, wss://). OkHttp при апгрейде HTTP соединения до WebSocket прокси использует (CONNECT-туннель), но Proxy-Authorization нужно передавать отдельно через Authenticator.
iOS: URLSessionConfiguration.default автоматически подхватывает системный прокси из настроек. Но URLSession с кастомным URLSessionConfiguration или ephemeral конфигурацией — нет. Для явного контроля: CFNetworkCopySystemProxySettings() (Core Foundation) или NEProxySettings через Network Extension API.
NTLM и Kerberos: корпоративная аутентификация прокси
Самый болезненный сценарий — прокси требует NTLM или Kerberos аутентификацию (Integrated Windows Authentication). Стандартные HTTP-библиотеки на iOS и Android не поддерживают NTLM из коробки.
На Android: OkHttp + библиотека ntlm-authentication или кастомный Authenticator с реализацией NTLM handshake. NTLM — трёхшаговый протокол: NEGOTIATE → CHALLENGE → AUTHENTICATE. Ответ на challenge вычисляется на основе хэшей NT-пароля, username и domain. Хранить credentials в AccountManager — не в SharedPreferences.
На iOS: URLSession поддерживает NTLM через URLAuthenticationChallenge с NSURLAuthenticationMethodNTLM. Нужно реализовать URLSessionTaskDelegate и возвращать URLCredential с username/password. Domain — опционально, но без него некоторые корпоративные прокси не принимают.
Kerberos (Negotiate) на мобиле — редкость, но встречается в крупных корпорациях с MS AD. На iOS: GSS-API (доступен через Heimdal). На Android — практически нет нормального решения без NDK и MIT Kerberos.
SSL Inspection: подмена сертификата прокси
Корпоративный HTTPS-прокси часто выступает Man-in-the-Middle — расшифровывает TLS-трафик, проверяет, перешифровывает собственным сертификатом. Устройство должно доверять корпоративному CA.
На устройствах с MDM корпоративный CA устанавливается автоматически через профиль. Для приложений, которые реализуют Certificate Pinning — SSL-inspection ломает его. Нужно либо отключить pinning для внутренних эндпоинтов, либо pinning на уровне MDM-сертификата (проверять не leaf-сертификат сервера, а цепочку к доверенному корпоративному CA).
На Android 7+ пользовательские CA-сертификаты не доверяются приложениям по умолчанию. Для корпоративных приложений, которые должны доверять MDM-установленному CA: network_security_config.xml с <certificates src="system"/> и явным указанием <certificates src="user"/> для development, только system для production MDM.
PAC-файлы: когда прокси не один
Proxy Auto-Config (PAC) — JavaScript-функция FindProxyForURL(url, host), которая возвращает прокси или DIRECT для каждого URL. Корпоративные сети используют PAC для маршрутизации: внутренние ресурсы — напрямую, интернет — через прокси.
На iOS: PAC обрабатывается системой, URLSession использует результат прозрачно. На Android: ProxyInfo.buildPacProxy(Uri) — MDM устанавливает, но программная обработка PAC-скриптов в приложении не тривиальна. Для кастомных HTTP-клиентов (OkHttp) нужно парсить и выполнять PAC самостоятельно — библиотека pac4j-proxy или JavaScript через JavaScriptEngine.
Процесс интеграции
Начинаем с аудита: какой прокси использует клиент, MDM-решение (Intune, Jamf, MobileIron), метод аутентификации, нужен ли SSL-inspection. От этого зависит объём работ.
Базовая интеграция (HTTP/HTTPS прокси без аутентификации) — 1 неделя. NTLM + PAC + SSL inspection bypass — 3–5 недель включая тестирование в корпоративной среде.