// Engineering Log

HTTP, HTTPS и TLS: Часть 13 — Перехват HTTPS для отладки: DevTools, HAR-файлы и mitmproxy

Опубликовано 23.10.2026

// Быстрый маршрут

Эта статья относится к теме Безопасность и защита.

curl показывает то, что отправили вы сами, а tcpdump и Wireshark («Сетевой траблшутинг: tcpdump, sngrep и Wireshark») — пакеты, но без расшифровки HTTPS. Но часто нужно увидеть, что отправляет чужой клиент: браузер при сбое формы, мобильное приложение, которое не может достучаться до API, программа, которая ведёт себя не так, как написано в документации. Для этого трафик перехватывают: в браузере — встроенными инструментами разработчика, для остальных программ — прокси, который расшифровывает HTTPS. Всё описанное применимо к собственным устройствам и программам или к системам, на анализ которых есть разрешение.

Вкладка Network в браузере

Инструменты разработчика открываются клавишей F12 (в macOS — Cmd+Option+I). На вкладке Network видны все запросы страницы: адрес, метод, код ответа, тип, размер, время.

Полезные настройки вверху вкладки:

  • Preserve log — не очищать список при переходе на другую страницу. Без этого не увидеть запрос формы, после которого идёт редирект;
  • Disable cache — загружать всё с сервера, пока инструменты открыты;
  • Throttling — имитация медленной сети (Fast 4G, Slow 3G) и работы без сети;
  • фильтр Fetch/XHR — только запросы JavaScript к API; строка поиска понимает условия вроде status-code:500, method:POST, domain:api.example.ru, larger-than:1M.

По щелчку на запросе открываются вкладки:

  • Headers — заголовки запроса и ответа, итоговый адрес, адрес сервера;
  • Payload — параметры строки запроса и тело формы или JSON;
  • Preview / Response — ответ в разобранном и исходном виде;
  • Timing — разбивка времени: ожидание в очереди, DNS, подключение, TLS, ожидание ответа сервера (TTFB), загрузка. Та же информация, что -w в curl;
  • Initiator — какой скрипт или элемент страницы вызвал запрос.

Колонку Protocol (правый щелчок по заголовку таблицы) стоит включить всегда: в ней видно h2, h3 или http/1.1.

Запрос можно скопировать для повторения: Copy → Copy as cURL (как команду curl со всеми заголовками и cookie) или Copy as fetch (как JavaScript-код для консоли).

Ошибки CORS в консоли браузера выглядят как сетевые сбои, а в Network у запроса статус CORS error. Смотрите на предварительный запрос OPTIONS рядом с ним: чаще всего он получил 401, 404 или ответ без заголовков Access-Control-Allow-*.

Сертификат и TLS. Вкладка Security (в Chrome) показывает версию TLS, группу обмена ключами, шифр и сертификат текущей страницы, а также ресурсы, загруженные по HTTP.

HAR-файлы

HAR (HTTP Archive) — JSON-файл со всеми запросами и ответами сессии, включая заголовки, тела и тайминги. Его просит поддержка сервисов, когда проблему нужно воспроизвести у них. Сохранить: на вкладке Network — кнопка со стрелкой вниз (Export HAR) или правый щелчок → Save all as HAR.

В HAR попадают пароли и сессии. Файл содержит cookie, заголовки Authorization, токены в адресах и тела форм, включая введённый пароль. Отправить такой файл — всё равно что отдать доступ к своему аккаунту: в 2023 году злоумышленники получили доступ к клиентам Okta именно через HAR-файлы из обращений в поддержку.

С Chrome 130 экспорт по умолчанию «очищенный» (sanitized): без Cookie, Set-Cookie и Authorization. Полную версию можно получить только после включения настройки Allow to generate HAR with sensitive data. Но токены в адресах, в телах запросов и в собственных заголовках (X-Api-Key) очистка не убирает. Перед отправкой откройте файл в редакторе и поищите token, key, password, session. После отладки выйдите из аккаунта, чтобы сессия из файла стала недействительной.

Посмотреть HAR можно в самой вкладке Network (перетащить файл в окно) или в онлайн-просмотрщике Google Admin Toolbox HAR Analyzer.

Перехватывающий прокси: как это работает

Для программ вне браузера нужен прокси, который встаёт между клиентом и сервером и расшифровывает HTTPS. Самый распространённый свободный вариант — mitmproxy; есть также Charles, Proxyman (macOS), HTTP Toolkit, Burp Suite.

Схема:

  1. Клиент подключается к прокси, а не к серверу.
  2. Прокси сам подключается к серверу по TLS и проверяет его настоящий сертификат.
  3. Клиенту прокси предъявляет сертификат для того же имени, выпущенный на лету своим удостоверяющим центром.
  4. Если клиент доверяет этому центру, у прокси получаются два расшифрованных соединения, и он видит и может изменять всё, что между ними идёт.

Главное условие — установленный на устройстве корневой сертификат прокси. Без него клиент увидит поддельный сертификат и прервёт соединение — ровно так, как TLS и должен работать.

mitmproxy

Установка — brew install mitmproxy, pipx install mitmproxy или Docker-образ mitmproxy/mitmproxy. Три интерфейса:

  • mitmproxy — интерактивный интерфейс в терминале;
  • mitmweb — веб-интерфейс на http://127.0.0.1:8081;
  • mitmdump — без интерфейса, для записи и скриптов.

По умолчанию прокси слушает порт 8080. При первом запуске mitmproxy создаёт свой удостоверяющий центр в ~/.mitmproxy/.

Проверка на curl:

bash
mitmweb &
curl -x http://127.0.0.1:8080 --cacert ~/.mitmproxy/mitmproxy-ca-cert.pem https://example.ru/

Запрос появится в веб-интерфейсе со всеми заголовками и телом.

Установка сертификата. Настройте на устройстве прокси IP-компьютера:8080 и откройте в браузере http://mitm.it — страница, которую отдаёт сам mitmproxy, с сертификатом и инструкцией для каждой системы.

  • iOS: установить профиль, затем включить полное доверие в Настройки → Основные → Об этом устройстве → Доверие сертификатам.
  • Android: с версии 7 приложения по умолчанию не доверяют сертификатам, установленным пользователем, — только системным. Браузер Chrome доверяет, большинство приложений — нет. Для своего приложения доверие к пользовательским сертификатам включается в network_security_config.xml отладочной сборки; для чужих нужен эмулятор или устройство с root, где сертификат кладётся в системное хранилище.
  • Windows и macOS: импорт в системное хранилище корневых сертификатов. Firefox использует собственное хранилище — сертификат нужно добавить в его настройках.

Режимы работы. Кроме обычного прокси, mitmproxy умеет:

  • --mode wireguard — поднимает WireGuard-сервер; устройство подключается к нему как к VPN по QR-коду из mitmweb, и весь его трафик идёт через mitmproxy без настройки прокси. Удобно для телефонов и приложений, которые игнорируют системный прокси;
  • --mode local — перехват программ на этом же компьютере без настройки прокси: mitmproxy --mode local:curl — только curl, --mode local:!curl — всё, кроме curl;
  • --mode reverse:https://api.example.ru — обратный прокси перед конкретным сервером;
  • --mode transparent — прозрачный перехват вместе с правилами перенаправления в межсетевом экране.

Изменение запросов. Сценарий на Python подменяет запросы и ответы на лету — удобно, чтобы проверить, как приложение переживёт ошибку сервера, не трогая сервер:

python
# fail.py — отдавать 503 на запросы к /api/orders
from mitmproxy import http

def request(flow: http.HTTPFlow) -> None:
    if flow.request.pretty_url.startswith("https://api.example.ru/api/orders"):
        flow.response = http.Response.make(503, b'{"error":"maintenance"}',
                                           {"Content-Type": "application/json"})
bash
mitmdump -s fail.py

Записать сессию и позже воспроизвести её: mitmdump -w flows.mitm, затем mitmproxy -r flows.mitm. Экспорт в HAR — mitmdump -n -r flows.mitm --set hardump=flows.har (-n — не запускать прокси, только обработать файл).

Пример целиком: как приложение переживёт отказ API

Задача: проверить, что мобильное приложение показывает понятное сообщение, а не падает, когда API заказов отвечает 503. Сервер при этом трогать нельзя. Проверено на mitmproxy 12.2.

1. Сценарий подмены — файл fail.py из раздела выше, адрес заменён на ваш API.

2. Запуск с записью сессии:

bash
mitmweb -s fail.py -w flows.mitm --mode wireguard

mitmweb откроет веб-интерфейс и покажет QR-код с настройками WireGuard.

3. Телефон. Установите приложение WireGuard, отсканируйте QR-код, включите туннель. Откройте на телефоне http://mitm.it, установите сертификат и включите доверие к нему (для iOS — в «Доверии сертификатам», для Android — только если это отладочная сборка вашего приложения или эмулятор).

4. Проверка перехвата. Откройте в браузере телефона любой сайт — запрос появится в mitmweb. Если сайт не открывается с ошибкой сертификата, не включено доверие к сертификату.

5. Сценарий. Откройте в приложении список заказов. В mitmweb у запроса к /api/orders будет ответ 503 от сценария, а приложение должно показать сообщение об ошибке и предложить повторить.

6. Разбор. После проверки остановите mitmweb (Ctrl+C) и посмотрите запись:

bash
mitmproxy -r flows.mitm                                # интерактивно
mitmdump -n -r flows.mitm --set hardump=flows.har      # в HAR — например, приложить к задаче

7. Уборка. Выключите туннель WireGuard, удалите профиль сертификата с телефона. Файлы flows.mitm и flows.har содержат токены приложения — удалите их или храните как секреты.

Проверить сам сценарий без телефона можно из командной строки:

bash
mitmdump -s fail.py &
curl -x http://127.0.0.1:8080 --cacert ~/.mitmproxy/mitmproxy-ca-cert.pem https://api.example.ru/api/orders
# {"error":"maintenance"}

Когда перехват не работает

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

Протоколы не на HTTP. Приложения, которые используют QUIC, собственные протоколы поверх TCP или UDP, gRPC с нестандартными настройками, могут не работать через HTTP-прокси. Для HTTP/3 браузеры в этом случае откатываются на TCP; новые версии mitmproxy умеют работать с HTTP/3, но не во всех режимах.

Приложение игнорирует системный прокси. Многие программы не читают системные настройки прокси: приложения на Go смотрят только переменные окружения HTTPS_PROXY, приложения на Java — собственные параметры JVM. Помогает режим WireGuard или прозрачный режим — они перехватывают трафик на уровне сети.

Отпечаток TLS. Сервер видит отпечаток TLS прокси, а не приложения. Если сервер защищён от ботов по JA3/JA4, запросы через прокси могут получать капчу или 403, хотя напрямую приложение работает.

Безопасность после отладки

  • Удалите корневой сертификат прокси с устройства, когда закончите. Закрытый ключ этого центра лежит в ~/.mitmproxy/ на вашем компьютере, и любой, кто его получит, сможет расшифровывать трафик устройства, которое ему доверяет.
  • Не оставляйте mitmproxy слушать на всех интерфейсах в публичной сети: прокси без пароля — открытый прокси. Параметр --set proxyauth=user:pass задаёт пароль.
  • Записанные сессии и HAR-файлы содержат пароли и токены — храните их как секреты и удаляйте.

// Похожая задача

Если у вас похожая ситуация

Эта статья относится к одной из рабочих тем. Можно продолжить чтение по теме, перейти на главную, чтобы понять, чем я занимаюсь, или сразу открыть услуги.

Тема статьи

Безопасность и защита

SSL, hardening, доступы, защита сервисов и безопасные конфигурации.

Часто с этим приходят

  • Настроить SSL, сертификаты и безопасные подключения
  • Ограничить доступы и закрыть лишние точки входа
  • Усилить конфигурацию сервера и сервисов

// Следующий шаг

Если вам нужна не только статья, а помощь по этой теме, удобнее сразу перейти в услугу. Главная и подборка материалов остаются рядом.

Открыть услуги

// Contact

Нужна помощь?

Свяжись со мной и я помогу решить проблему

Написать в Telegram

Отвечаю в течение рабочего дня (03:00–13:00 GMT)

Или оставьте заявку здесь:

Подтвердите, что вы не бот.

Написать и получить быстрый ответ