Почему мобильные приложения игнорируют HTTPS-прокси и как это исправить

Включаешь HTTPS-прокси, ставишь корневой сертификат, прописываешь системные настройки — а в списке перехваченных запросов пусто. Или приложение сразу падает с ошибкой TLS. По мнению автора разбора на Хабре, так выглядят четыре типичных сценария, когда трафик мобильного или десктопного приложения упорно не идёт через ваш прокси. Разберём, почему так происходит и где тут собака зарыта.

Почему приложение игнорирует прокси

Перевод с маркетингового на человеческий: разработчик вшил в приложение кастомный HTTP-клиент (OkHttp, URLSession с хитрой конфигурацией или вообще самописный велосипед), который читает настройки прокси не из системы, а из своих переменных окружения. Результат — ваш системный прокси для этого приложения просто не существует. Из чужих приложений и браузера трафик в перехватчик идёт исправно, а из нужного — нет.

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

Сертификат вроде стоит, а TLS всё равно падает

Знакомая картина: корневой сертификат прокси установлен и доверен, система его видит, но приложение упорно выдаёт ошибку рукопожатия. Причина в том, как именно работает MITM-перехват (от англ. man-in-the-middle — «человек посередине», когда прокси вклинивается в соединение между вами и сервером): прокси для каждого хоста на лету генерирует поддельный конечный сертификат и подписывает его своим корневым CA. Приложение примет эту подмену только если корневой сертификат прокси лежит именно в том хранилище, к которому это приложение реально обращается.

Тут начинается самое весёлое. Начиная с Android 7 приложения по умолчанию доверяют только системному хранилищу сертификатов — закинуть CA в пользовательское уже недостаточно. На iOS та же история: профиль конфигурации должен быть помечен как полностью доверенный, иначе система его «видит», но игнорирует. Лечение в обоих случаях одно — загнать корневой сертификат в системное хранилище. На Android это технически возможно с root, на iOS — через MDM-профиль (систему управления мобильными устройствами) или ручную пометку доверия.

SSL Pinning и собственные TLS-стеки

Самая непробиваемая история — SSL Pinning. Приложение после стандартной проверки цепочки дополнительно сверяет открытый ключ сервера (или весь сертификат) с жёстко зашитым в код значением — так называемым SPKI pin. Поддельный сертификат от прокси содержит ключ прокси, а не реального сервера, и проверка проваливается. В интерфейсе — короткий запрос с ошибкой TLS и тишина. Причём системному корневому CA приложение доверяет, а вот конкретному подменному сертификату — нет.

Подвох номер два ждёт там, где приложение вообще не использует системный TLS. Некоторые клиенты держат собственное хранилище сертификатов и требуют отдельного импорта корневого CA через свои настройки. Firefox на Linux — классический пример: системный сертификат в этом случае бесполезен, у браузера свой магазин. Проверяется просто: ставите CA, дёргаете curl и lynx — работает, а в приложении тишина. Значит, у него собственное хранилище.

Что с этим делать

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

Для корпоративного MDM и DLP (систем предотвращения утечек данных) вывод простой: рассчитывать на пассивный перехват трафика мобильных приложений в большинстве случаев нельзя. Хотите реально контролировать — покупайте MDM с управлением устройством, ставьте корпоративный профиль с корневым CA и не удивляйтесь, что часть приложений всё равно будет ходить мимо вашего прокси. Такова цена «безопасности по-дефолту», которую нам давно вписали в ОС.