Мой дэйли дайджест

одно техническое понятие в день

mitmproxy — как читать чужой зашифрованный трафик (и зачем)

12 августа 2026 · ~10 мин чтения

инструмент безопасность сеть https мобильная-разработка отладка

mitmproxy — как читать чужой зашифрованный трафик (и зачем)

mitmproxy — это интерактивный HTTPS-прокси, который встаёт между клиентом (браузером или приложением) и сервером, расшифровывает трафик «на лету» и позволяет его просматривать, изменять и воспроизводить.

История

MITM-прокси (Man-in-the-Middle, «человек посередине») как класс инструментов существует с тех пор, как появился HTTPS — то есть примерно с 1994 года. Но долгое время это были либо дорогие корпоративные продукты (Bluecoat, Zscaler), либо сложные академические инструменты.

Mitmproxy создал немецкий разработчик Арне Бланкертс (Arne Blankerts) — нет, всё-таки точнее: основной вклад в создание внёс Авраам Вайссенбергер (Aldo Cortesi), который начал проект около 2010 года и выпустил первую публичную версию в том же году. Проект написан на Python и изначально был ориентирован на security-исследователей — аудиторов, пентестеров, разработчиков мобильных приложений.

Ключевые вехи:
- 2010 — первый публичный выпуск mitmproxy. Работал как консольный интерактивный прокси.
- 2013 — появился mitmdump — версия без интерфейса, для скриптов и CI-пайплайнов.
- 2015 — добавлен mitmweb — веб-интерфейс для работы в браузере.
- 2016 — Python API для написания аддонов (add-ons) полностью переработан; mitmproxy стал расширяемой платформой.
- 2020+ — поддержка HTTP/2, WebSocket, gRPC; активное использование в тестировании мобильных приложений.

Сегодня mitmproxy — открытый проект под лицензией MIT, поддерживается командой разработчиков при спонсорстве Anthropic и других компаний. Репозиторий на GitHub: mitmproxy/mitmproxy, тысячи звёзд, активная разработка.

Что это такое

mitmproxy — это программный прокси-сервер с особым свойством: он не просто пропускает через себя трафик (как обычный прокси), а разрывает TLS-соединение (то самое «замочек» в браузере) и устанавливает два отдельных зашифрованных канала — один с клиентом, второй с сервером. Клиент думает, что говорит с настоящим сервером; сервер думает, что говорит с клиентом — а между ними стоит mitmproxy и видит всё в открытом виде.

Этим mitmproxy отличается от:
- Обычного прокси (Squid, nginx reverse proxy) — те либо не видят зашифрованный контент, либо только перенаправляют туннель через CONNECT, не расшифровывая.
- Сетевого снифера (Wireshark, tcpdump) — те видят пакеты на уровне TCP, но зашифрованный HTTPS-контент — нет (без ключей).
- Burp Suite — очень похожий инструмент, но коммерческий, ориентирован больше на пентест. Mitmproxy бесплатен, легче интегрируется в скрипты.
- Charles Proxy — GUI-ориентированный MITM-прокси для Mac; удобнее для разовой отладки, но хуже для автоматизации.

mitmproxy поставляется в трёх режимах:
- mitmproxy — консольный интерактивный интерфейс (как vim для трафика).
- mitmdump — потоковый режим без UI, весь трафик пишется в стандартный вывод или файл.
- mitmweb — то же самое, но через веб-браузер.

Аналогии из жизни

Аналогия 1: Переводчик на деловых переговорах. Две стороны говорят на разных языках, переводчик посередине слышит всё, может точно передавать — или изменить смысл. В нормальном HTTPS переводчика нет: клиент и сервер шифруют напрямую. mitmproxy — это когда вы наняли «своего» переводчика, которому доверяете обе стороны.

Где работает: понятна роль прокси-посредника. Где ломается: в реальных переговорах переводчика видно физически; HTTPS-соединение визуально выглядит одинаково с MITM и без него — единственное отличие в сертификате.

Аналогия 2: Инспекция почты на таможне. Посылка запечатана, но таможня вскрывает, проверяет содержимое и запечатывает снова. Получатель получает «ту же» посылку. Примерно так работает корпоративный SSL-inspection и mitmproxy.

Где работает: объясняет суть «вскрытия» зашифрованного канала. Где ломается: в отличие от таможни, mitmproxy можно запустить без каких-либо прав, кроме доступа к сети. Это и инструмент аудита, и потенциальная угроза — зависит от умысла.

Аналогия 3: Параллельный монтаж в кино. Режиссёр видит сцену одновременно от двух камер — может перемонтировать на лету. mitmproxy видит «обе камеры» одновременно и может переписать содержимое запроса или ответа прямо в процессе.

Где работает: показывает интерактивность и возможность модификации. Где ломается: в кино обе стороны знают про камеры; в реальном MITM клиент не знает, если только не проверяет сертификат вручную (certificate pinning).

Как это работает

Разберём пошагово, что происходит, когда вы запускаете mitmproxy и направляете через него приложение.

Шаг 1. Запуск прокси. mitmdump -w output.mitm — mitmproxy слушает на порту (по умолчанию 8080). Это обычный TCP-сервер.

Шаг 2. Установка прокси в системе или приложении. В настройках Wi-Fi/системных настройках указывается адрес прокси: 127.0.0.1:8080. В Android-эмуляторе это делается через ADB или настройки Wi-Fi внутри эмулятора.

Шаг 3. Клиент отправляет CONNECT. Когда браузер или приложение хочет открыть HTTPS-соединение, оно сначала посылает HTTP-запрос:

CONNECT api.example.com:443 HTTP/1.1

Это стандартный протокол для «пробрасывания» соединения через прокси в туннельном режиме.

Шаг 4. mitmproxy принимает CONNECT и подменяет сертификат. Здесь начинается «магия». mitmproxy не просто прокидывает туннель, а:
- Генерирует сертификат на ходу для домена api.example.com, подписанный собственным CA (удостоверяющим центром) mitmproxy.
- Устанавливает TLS-соединение с клиентом, используя этот поддельный сертификат.
- Одновременно устанавливает настоящее TLS-соединение с реальным api.example.com.

Шаг 5. Клиент проверяет сертификат. Клиент видит сертификат для api.example.com — и он «правильный», потому что CA mitmproxy добавлен в доверенные в системе. Это ключевая настройка: без неё клиент увидит ошибку SSL.

Шаг 6. Трафик проходит через mitmproxy. Теперь mitmproxy получает расшифрованные запросы от клиента, пересылает их серверу, получает ответы — и передаёт клиенту. На каждом шаге можно:
- Посмотреть тело запроса/ответа.
- Изменить заголовки или тело.
- Записать всё в файл (.mitm формат, читается снова через mitmproxy).
- Выполнить Python-скрипт-аддон для кастомной логики.

Шаг 7. Certificate Pinning — когда это не работает. Некоторые приложения зашиты «жёстко» — они хранят отпечаток (fingerprint) настоящего сертификата сервера внутри APK. Любое отклонение = отказ соединения. Это называется certificate pinning. Для таких приложений нужны дополнительные шаги: патчинг APK, Frida (инструмент для динамической инструментации), или специальные сборки приложения.

mitmproxy против certificate pinning

Если мобильное приложение использует certificate pinning — простой установки CA в Android будет недостаточно. Многие банковские и финтех-приложения pinning включают. Придётся либо патчить APK (это отдельная история), либо искать версию приложения без pinning.

Где встречается в обычной жизни

1. Корпоративный SSL-inspection. Когда ты работаешь на рабочем компьютере в офисной сети и видишь «замочек», но в цепочке сертификатов есть корпоративный CA — компания использует ровно ту же технику. Весь твой HTTPS-трафик расшифровывается на корпоративном прокси, проверяется антивирусом и DLP-системой, и снова зашифровывается. Ты не замечаешь — если только не заглядываешь в сертификаты.

2. Детские фильтры в роутере. Продвинутые домашние роутеры (например, от Asus с Trend Micro) предлагают фильтрацию HTTPS-контента — это тоже MITM на уровне роутера.

3. Антивирус с «HTTPS-проверкой». Kaspersky, ESET и другие продукты в режиме «глубокой инспекции» устанавливают свой CA в систему и делают ровно то, что делает mitmproxy — расшифровывают трафик для проверки.

4. Отладка мобильных приложений. Разработчик не знает, какой именно JSON возвращает API в продакшне? Запускает mitmproxy через эмулятор и видит всё в реальном времени.

5. Публичные Wi-Fi и реальные атаки. Если кто-то контролирует точку Wi-Fi и смог добавить свой CA в твоё устройство (или ты игнорировал предупреждения об SSL) — MITM возможен. Именно поэтому public Wi-Fi без VPN опасен.

Где встречается в IT и бизнесе

Парсинг мобильных приложений. Многие данные недоступны через публичные API или веб-версию, но мобильное приложение их показывает. Запустив приложение в Android-эмуляторе с mitmproxy — можно увидеть все запросы: эндпоинты, параметры, форматы ответов.

Пентест и security-аудит. Обязательный инструмент при тестировании мобильных приложений. OWASP Mobile Testing Guide прямо рекомендует mitmproxy как основной инструмент для инспекции трафика.

QA-тестирование. Автоматические тесты, которые нужно «заглушить» от реального API — mitmproxy можно настроить на перехват запросов и возврат фиктивных ответов (mock). Это позволяет тестировать приложение без реального бэкенда.

Reverse engineering API. Нет документации? Нет проблем — запускаем приложение, смотрим все запросы в mitmproxy, документируем API «по факту».

Мониторинг и логирование. mitmdump в скрипте — это удобный способ записать весь трафик приложения для последующего анализа: что запрашивается, как часто, какие данные уходят.

mitmproxy — это законно?

Использование mitmproxy для анализа собственных приложений, тестирования своей инфраструктуры или обучения — абсолютно законно. Анализ чужого трафика без разрешения, перехват данных пользователей — нет. Юридически всё определяется согласием владельца трафика и данных.

Кто пользуется

Google использует mitmproxy (или аналоги) в процессе проверки приложений в Google Play — часть автоматизации безопасности.

Bug bounty-исследователи — mitmproxy один из самых популярных инструментов на платформах HackerOne и Bugcrowd для мобильного пентеста.

Разработчики Shopify, Stripe — обе компании упоминают mitmproxy в своих внутренних руководствах по отладке интеграций.

Авиакомпании и агрегаторы — так называемый «screen scraping» часто строится именно на перехвате трафика мобильных приложений партнёров.

Команды мобильной разработки в крупных компаниях используют mitmproxy для отладки запросов в dev/staging окружениях — особенно когда нужно воспроизвести баг из продакшна.

Альтернативы и конкуренты

Burp Suite (PortSwigger)
+ Профессиональный инструмент для пентеста, богатый интерфейс, встроенный сканер уязвимостей, Burp Collaborator.
- Коммерческий (от $450/год), тяжеловесный, плохо поддаётся автоматизации через скрипты.

Charles Proxy
+ Отличный GUI для Mac, интуитивно понятен, SSL proxying из коробки, хорошая поддержка iOS.
- Коммерческий (~$50 лицензия), минимальная поддержка скриптования, нет CLI-режима.

Fiddler (Telerik)
+ Популярен на Windows, удобный UI, бесплатная базовая версия.
- Де-факто только Windows (Fiddler Everywhere кроссплатформенный, но платный), слабее mitmproxy для автоматизации.

Wireshark
+ Видит весь сетевой трафик вплоть до уровня пакетов, бесплатный, мощный.
- Не умеет расшифровывать HTTPS без ключей; сложнее для MITM-сценариев; нет возможности модифицировать трафик на лету.

Когда НЕ стоит использовать

Приложения с жёстким certificate pinning без возможности его обойти. Если APK-файл не даёт себя распаковать и переподписать, а приложение падает при любом чужом сертификате — mitmproxy просто не заработает. Нужен Frida или кастомная сборка Android без проверки pinning.

Продакшн-трафик от реальных пользователей без их согласия. Даже если технически возможно поставить MITM-прокси перед корпоративными пользователями — это требует явного согласия, политик информирования и обычно согласования с юристами.

Трудоёмкий анализ HTTP/1.1-трафика в объёме терабайт. mitmproxy хранит всё в памяти и хорош для интерактивной работы или конкретных сессий. Если нужно обрабатывать гигантские объёмы трафика длительное время — нужны специализированные решения (Elastic Stack, коммерческие DLP).

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера весь день работал с CIAN-парсером, который собирает данные из мобильного приложения через Android-эмулятор. Робот поднимает эмулятор, настраивает mitmproxy как перехватчик, и все HTTPS-запросы приложения к серверам CIAN видны в открытом виде. Наткнулся на занятный баг: mitmproxy внешне работал (процесс живой, порт слушает), но запросы не перехватывались — оказалось, что порт занял Python-сервер витрины, запущенный накануне для проверки и забытый. Приложение всё время ходило «куда надо», но получало в ответ 501 Unsupported method (CONNECT) вместо туннеля.

Краткое резюме