Как происходит перехват трафика http/https для мобильных устройств?

Ниже — сжатая, практическая инструкция по тому, как перехватывают HTTP/HTTPS‑трафик мобильных устройств в тестировании (что нужно, какие инструменты, ограничения и обходы). Строго по делу, без "волшебных" эксплойтов — только легальные и тест‑ориентированные техники.

Ключевая идея

• HTTP — перехват прост: устройство направляет трафик через прокси, который логирует/меняет запросы.

• HTTPS — защищённая TLS‑сессия; чтобы увидеть содержимое, прокси выполняет MITM (man‑in‑the‑middle) — генерирует поддельный сертификат для целевого хоста и подписывает его своим собственным CA. Чтобы клиент принял такой сертификат, на устройство/в приложение нужно добавить доверенный CA или приложение должно позволять пользовательские CA.

Инструменты (часто используемые)

• mitmproxy — консольный/HTTP(S) прокси, скрипты на Python.

• Burp Suite — профессиональный прокси для тестирования безопасности.

• Charles Proxy / Fiddler — удобные GUI‑прокси для разработчиков/тестировщиков.

• Wireshark / tcpdump — сниффинг на сетевом уровне (полезно для non‑TLS или для диагностики соединения), не дешифрует HTTPS.

• sslsplit, mitmfs — инструменты для прозрачного MITM.

• Frida / Objection — для динамического обхода certificate‑pinning внутри приложения (только для легитимного тестирования/debug сборок).

• Emulator / rooted device / test device — часто упрощают установку CA и обход ограничений.

Как организовать перехват — общая последовательность

1. Запустить MITM‑прокси (mitmproxy / Burp / Charles) на компьютере с доступом к той же сети.

2. Настроить устройство использовать прокси:

   • Настройка Wi‑Fi → вручную задать proxy host:port.

   • Для мобильной сети можно использовать подключение через компьютер (tethering) или VPN‑виртуальную сеть к прокси.

3. Установить CA сертификат прокси на устройство и доверить ему (см. ниже — важные нюансы для Android/iOS).

4. Просматривать и при необходимости модифицировать запросы/ответы в интерфейсе прокси.

Важные нюансы и ограничения (и как с ними работать)

1) Android (начиная с Nougat 7.0)

• По умолчанию приложения Android 7+ НЕ доверяют пользовательским CA (установленным пользователем) для HTTPS, если в приложении явно не разрешено. Это означает, что простая установка CA в пользовательское хранилище часто не работает для релизных сборок.

• Решения для тестирования:

  • Использовать debug‑сборку, в которой devs включают доверие к пользовательским CA (или отключают pinning).

  • Добавить CA в системный trust store (requires root или эмулятор с root): тогда любые приложения увидят прокси‑CA как доверенный.

  • Попросить команду разработчиков предоставить тест‑билд с networkSecurityConfig, где разрешены user CAs или отключено pinning.

  • Эмулятор / Genymotion: проще установить CA в системный store или запускать эмулятор с root.

2) iOS

• Нужно установить доверие к сертификату в Settings → General → About → Certificate Trust Settings (включить Full Trust для прокси‑CA).

• iOS 13+ и современные приложения могут использовать пиннинг или ATS (App Transport Security) — для таких случаев проще работать с тестовым билдом или использовать симулятор/инструменты разработчика.

3) Certificate pinning

• Многие приложения используют pinning TLS‑сертификатов; в этом случае MITM не сработает даже при установленном CA.

• Корректные подходы:

  • Тестовые / debug‑сборки с отключённым pinning.

  • Инструменты для динамического вмешательства (Frida/Objection) для тестовых устройств — применять только с разрешения и в тестовой среде.

  • Модификация приложения (rebuild) с выключенным pinning — самый надёжный и этичный способ для QA.

4) HSTS/HTTP/2/TLS1.3 и другие механизмы

• Современные протоколы и заголовки не мешают MITM при корректной установке доверенного CA, но могут осложнять анализ (например, HTTP/2 мультиплексирование в прокси). Большинство инструментов поддерживают эти протоколы.

Практические рекомендации для QA (без обхода безопасности)

• Всегда имейте разрешение на перехват трафика (от продукта/заказчика). Интерцепт чужих устройств/трафика — незаконно.

• Просите devs подготовить тест‑билд:

  • debug mode или конфигурацию network_security_config, которая позволяет user CA; либо тестовую опцию выключения pinning.

• Используйте эмулятор или тестовые устройства (rooted/emulator с системным cert), чтобы не менять пользователей system stores.

• Для CI/автоматизации: вместо MITM лучше использовать Mock серверы (WireMock, mock backend), либо прокси‑перехват в контролируемой среде (mitmproxy в контейнере).

• Логи и артефакты: сохраняйте capture (HAR/flows), указывайте точные запросы/ответы, заголовки и временные метрики; делайте скриншоты/скрипты воспроизведения.

Примеры типичных сценариев QA

• Проверка API‑контента: настроить прокси → установить CA → выполнить сценарий в приложении → проверить запросы/ответы.

• Тестирование ошибок сетевого уровня: в прокси возвращать 5xx/4xx, менять latency, drop connection.

• Тестирование offline/slow network: использовать прокси‑латентность или Android Network Link Conditioner.

• Проверка корректности cookie / auth headers / token refresh: смотреть как и когда обновляется токен в заголовках.

Детектирование проблем

• Если после установки CA и настройки прокси приложение выдаёт TLS‑ошибки — вероятно, pinning или приложение не доверяет пользовательским CA.

• Ошибки вида SSLHandshakeException/CERTIFICATE_VERIFY_FAILED → диагностировать по цепочке сертификатов в прокси.

Законность и безопасность

• Перехватывайте трафик только на устройствах/сетях, которыми вы владеете или на которые у вас есть разрешение.

• Не оставляйте прокси‑CA в устройстве после тестов в production устройстве — удаляйте CA и восстанавливайте настройки сети.

---

Краткая сводка: для просмотра HTTP достаточно прокси; для HTTPS — нужен MITM‑прокси + доверенный CA, но современные приложения/платформы (Android 7+, iOS, certificate‑pinning) вводят дополнительные шаги: используйте тестовые/ debug‑сборки, эмуляторы или системный сертификат (root), и обязательно работайте с разрешением команды.