Расшифровка HTTPS (атака «человек посередине», MitM)

Chute может расшифровывать HTTPS-трафик с помощью MitM. Дополнительную информацию см. в статье Википедии. На iPhone, Apple TV и Android это лицензируемая функция, и движок её соблюдает: без лицензии ничего не расшифровывается, что бы ни говорила конфигурация. См. Лицензия и активация.

Генератор сертификатов поможет вам создать новый сертификат CA для отладки и сделать сертификат доверенным системой. Он доступен в Chute Mac и редакторе Chute iOS. Этот сертификат генерируется локально и сохраняется только в вашем файле профиля и системной связке ключей. Ключ нового сертификата генерируется случайным образом с использованием OpenSSL. В Chute Android генератора нет: импортируйте существующий PKCS#12 в разделе MitM → Настроить CA редактора, а Установить CA передаст его сертификат CA установщику сертификатов Android — см. Установка и доверие CA-сертификату.

Вы также можете использовать существующий сертификат CA. Экспортируйте сертификат в формат PKCS#12 (.p12) с парольной фразой. Обратите внимание, что парольная фраза не может быть пустой; Chute отказывается загружать PKCS#12 без неё. Используйте команду base64 для кодирования в строку base64 и добавьте эти настройки ниже в ваш файл конфигурации.

[MITM]
enable = true
ca-p12 = MIIJtQ.........
ca-passphrase = password
hostname = *google.com

Chute расшифровывает только трафик к хостам, объявленным здесь, поэтому задавайте их всегда. На всех платформах включённый раздел [MITM], в котором не объявлен ни один hostname, не расшифровывает ничего — и когда ключа нет вовсе, и когда заданы только записи hostname-disabled. Через HTTP-прокси расшифровывается только HTTPS, пришедший через CONNECT: обычный HTTP-запрос пересылается как обычно, даже если его хост указан в hostname.

Поддерживаются подстановочные символы и ?. Обратите внимание, что ? действует как подстановочный знак, только если правило также содержит `; правило, содержащее только?`, сравнивается буквально.

• Используйте префикс - для исключения имени хоста. Записи проверяются в том порядке, в котором они написаны, и решает первая совпавшая, поэтому исключение должно стоять перед записью, из которой оно вырезает хосты: hostname = -*.apple.com, * не трогает apple.com, а hostname = *, -*.apple.com его расшифровывает.
• По умолчанию расшифровываются только запросы на порт 443.
  • Используйте суффикс :port для разрешения других портов.
  • Используйте суффикс :0 для разрешения всех портов.

Пример:

• -*.apple.com: Исключает все запросы, отправленные на *.apple.com на порту 443.
• www.google.com: Разрешает MitM для www.google.com на порту 443.
• www.google.com:8080: Разрешает MitM для www.google.com на порту 8080.
• www.google.com:0: Разрешает MitM для www.google.com на всех портах.
• *: Разрешает MitM для всех имён хостов на порту 443. (Не рекомендуется)
• *:0: Разрешает MitM для всех имён хостов на всех портах. (Не рекомендуется)

Четыре ключевых слова обозначают целые классы адресатов и принимают тот же префикс - и суффикс :port, что и имя: <ip-address> (любое соединение к IP-литералу), <ipv4-address>, <ipv6-address> и <simple-hostname> (имя без точки, например intranet). hostname = -<simple-hostname>, * расшифровывает всё, кроме однокомпонентных имён, а hostname = <ip-address> — только соединения к адресу. Ключевые слова адресов применяются только к CONNECT на адрес через HTTP-прокси: соединение TUN расшифровывается только по имени хоста — тому, которое для него разрешил Chute, или имени сервера из его рукопожатия TLS при включённом sniffing-enabled, — поэтому соединение, открытое просто к адресу без имени сервера, не расшифровывается никогда.

Запись имени хоста также может включать шаблон пути после первого символа /. Однако решение о расшифровке принимается при открытии соединения — при CONNECT или в начале сеанса TUN, — когда путь запроса ещё неизвестен, поэтому запись с путём при совпадении хоста расшифровывает всё соединение, а исключение вида -host/path не действует вовсе. Не полагайтесь на это, чтобы уберечь хост от расшифровки.

• example.com/api/*: Разрешает MitM для example.com на порту 443; путь его не сужает.

Общая конфигурация может выглядеть так:

hostname = -*.apple.com, -*.icloud.com, *

Chute будет применять правила перезаписи URL, перезаписи заголовков, перезаписи тела и имитации ответов ([Map Local]), а также скрипты ко всем MitM-запросам — к каждому запросу в расшифрованном соединении, а не только к первому. Расшифрованное соединение HTTP/1.1 несёт один обмен: как только ответ отправлен, Chute закрывает соединение, поэтому следующий запрос клиент отправляет по новому соединению, которое обрабатывается точно так же. Запрос, отправленный конвейерно (pipelining) следом за первым по тому же соединению, не обрабатывается, и клиент повторяет его по новому соединению. Исключение — соединение, которое Chute Android расшифровывает из VPN: оно остаётся открытым, и каждый запрос в нём обрабатывается по очереди. Закрывается оно после ответа, который Chute даёт сам, — имитации ответа, ответа перезаписи URL, response скрипта — и после ответа, тело которого пришло от скрипта http-response, сработавшего на этапе заголовков. Соединения HTTP/2 сохраняют своё соединение, как и переход на WebSocket: после ответа 101 данные проходят в обе стороны без изменений.

MitM поддерживает HTTP/2 — и через HTTP-прокси, и через TUN. Перед TLS-рукопожатием с сервером Chute читает протоколы, которые предлагает клиент (ALPN): если клиент предлагает h2 и в [MITM] не задано h2 = false, серверу предлагаются h2 и http/1.1, иначе только http/1.1. Затем клиенту предлагается протокол, выбранный сервером, так что обе стороны всегда говорят на одном протоколе; если клиент этот протокол не предлагал, Chute не отвечает ALPN, и рукопожатие продолжается. В HTTP/2 трейлеры (например, grpc-status в gRPC) и промежуточные ответы 1xx, такие как 103 Early Hints, передаются как есть; правила и скрипты их не видят. Ключ tcp-connection раздела [MITM] из Surge принимается в файлах конфигурации, но игнорируется.

Некоторые приложения имеют строгую политику безопасности с использованием закреплённых сертификатов или CA. Включение расшифровки для этих хостов может вызвать проблемы.

Chute хранит выпущенные им сертификаты хостов в хранилище и при заполнении вытесняет самый давно не использовавшийся: 512 сертификатов на macOS, 128 на iOS, tvOS и Android.

Установка и доверие CA-сертификату

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

Chute iOS — в редакторе конфигурации откройте MITM → Настроить CA:

1. Создать новый CA-сертификат (или Импортировать сертификат P12 для уже существующего).
2. Нажмите Установить CA-сертификат в систему. Откроется страница в Safari — нажмите Установить сертификат и разрешите загрузку, затем установите загруженный профиль в Настройки → Основные → VPN и управление устройством.
3. Доверьте ему: Настройки → Основные → Об этом устройстве → Доверие сертификатам — включите полное доверие для CA Chute. Именно этот шаг чаще всего пропускают: без него сертификат установлен, но не доверен, и расшифровка продолжает сбоить.

Chute Mac — в окне конфигурации откройте MitM:

1. Создать новый сертификат (или Импортировать сертификат из файла PKCS#12).
2. Нажмите Установить сертификат в систему. macOS запросит пароль администратора и добавит сертификат в системную связку ключей как доверенный корневой — никаких ручных действий в Связке ключей не требуется.
3. Экспортировать сертификат сохраняет копию .pem для установки на другие устройства.

Chute Android — в редакторе конфигурации откройте MitM → Настроить CA:

1. Импортировать P12 записывает существующий PKCS#12 в ca-p12 в виде base64, как это делают приложения для платформ Apple, так что конфигурация переносит свой CA на другие устройства; введите его парольную фразу в поле Парольная фраза CA. Генератора в Chute Android нет. ca-p12 с именем файла, как его записывали прежние версии редактора, по-прежнему читается.
2. Установить CA передаёт сертификат CA из этого P12 установщику сертификатов Android. Начиная с Android 11 приложение больше не может установить сертификат CA таким способом: вместо этого установите его из файла сертификата в настройках безопасности системы — из копии .pem или .crt, например той, что сохраняет Экспортировать сертификат в Chute Mac.
3. Android хранит его среди пользовательских сертификатов, а приложения, ориентированные на Android 7.0 и новее, доверяют таким сертификатам, только если сами это разрешают. Поэтому многие приложения и после установки сертификата не проходят рукопожатие — исключите их хосты из hostname.

Если конкретное приложение продолжает сбоить при доверенном сертификате, оно, скорее всего, закрепляет собственные сертификаты — исключите его хосты из hostname префиксом -, а не боритесь с ним.

Опции

skip-server-cert-verify

skip-server-cert-verify = true

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

[MITM]
enable = true
ca-p12 = MIIJtQ.........
ca-passphrase = password
skip-server-cert-verify = true
hostname = *google.com

Примечание по безопасности: Включение skip-server-cert-verify делает MitM-соединения уязвимыми для атак «человек посередине» между Chute и вышестоящим сервером. Включайте это только для доверенных сетей или целей разработки.

hostname-disabled

hostname-disabled = *.bank.example, pay.example.com:8443

Хосты, которые никогда не расшифровываются, даже если их охватывает запись в hostname. Шаблоны работают так же, как в hostname, а :port ограничивает запись одним портом. Удобно, чтобы отключить хосты, добавленные модулем, не редактируя сам модуль.

auto-quic-block

auto-quic-block = true

Блокирует QUIC ко всем хостам, которые были бы расшифрованы, чтобы клиенты HTTP/3 откатывались на TLS поверх TCP, где MitM видит трафик. Работает в дополнение к block-quic, а не вместо него.