Інтеграція корпоративного прокси-сервера в мобільний додаток
Корпоративні мобільні додатки часто працюють у середовищі з примусовим 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 для внутрішніх endpoints, або 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 bypass. Від цього залежить обсяг робіт.
Базова інтеграція (HTTP/HTTPS прокси без аутентифікації) — 1 тиждень. NTLM + PAC + SSL inspection bypass — 3–5 тижнів включаючи тестування в корпоративному середовищі.