Как работает прокси Charles при проксировании SSL-трафика?

Хорошо, я собираюсь опубликовать здесь только то, как Я думаю, что SSL-проксирование с Чарльзом работает, но у меня нет твердой основы, чтобы убедиться, что мой ответ правильный. На самом деле, было бы здорово, если бы кто-нибудь из команды Charles Proxy помог нам в этом.

Дело в том, что когда ваше приложение выполняет HTTPS-запрос к сайту, оно сначала должно пройти через Charles Proxy (не забывайте, что это прокси!). В этот момент Чарльз подключается к сайту https, используя открытый ключ сайт для шифрования и дешифрования данных, как если бы это был обычный браузер или приложение.

Итак, в этот момент Чарльз получил ответ от вашего https-запроса в незашифрованном виде, и он должен быть передан вашему приложению, но ваше приложение ожидает зашифрованные данные, поэтому Чарльз должен снова зашифровать его, чтобы ваше приложение (например, ваш браузер) не пожаловаться на незашифрованный ответ https. Для этого Чарльз использует свой собственный сертификат (пара открытого + закрытого ключей), шифрует ваши данные и отправляет их обратно в ваше приложение.

Наконец, ваше приложение получает эти данные, зашифрованные Charles. Ваше приложение не будет знать, как его расшифровать, если вы не дадите ему открытый ключ сертификата (это делается путем «установки» сертификата в вашем приложении / браузере / устройстве Android и т. д.).

Я думаю, что именно так работает SSL-проксирование с Чарльзом.

Было бы здорово, если бы кто-нибудь мог внести свой вклад в этот ответ!

Чарльз делает в основном Атака "человек посередине". Вот почему вам необходимо установить его сертификат на устройство, которое вы используете.

Обычно, когда устройство и сервер обмениваются данными через ssl / tls, запрос и ответы шифруются с использованием сертификата сервера. Это означает, что кто-то, кто перехватывает трафик, не может его прочитать, поскольку он зашифрован сертификатом сервера. Но поскольку вы установили сертификат Чарльза (то есть ваше устройство доверяет ему) на свое устройство и настроили его для связи с сервером через прокси-сервер, Чарльз может расшифровать трафик.

Шаги будут выглядеть так:

1. клиент и сервер обмениваются ключами (однако, поскольку Чарльз находится посередине, они обмениваются ключами с Чарльзом)
2. клиент отправляет зашифрованный запрос на сервер (однако он использует ключ от Чарльза)
3. Чарльз перехватывает запрос
4. Чарльз расшифровывает запрос и вот что вы видите
5. Чарльз шифрует запрос ключом сервера
6. Чарльз отправляет его на сервер

То же самое и с ответами.

Я создатель Проксимен, прокси-сервера для веб-отладки macOS, такого как Charles Proxy, поэтому у меня может быть понимание и опыт, чтобы ответить на ваши вопросы.

1. Когда вы запускаете Proxyman / Charles, он откроет сервер с IP = 127.0.0.1, портом 9090 или 8080. Он также переопределяет прокси HTTP / HTTPS в сети -> Wi-Fi -> Дополнительно -> вкладка Прокси.

Важно убедиться, что весь трафик будет проходить через сервер Proxyman / Charles.

Если это iPhone, вам нужно вручную настроить конфигурацию прокси в приложении «Настройки». Рекомендация: https://docs.proxyman.io/debug-devices/ios-device

2. Как только клиент (macOS) или приложение iOS (устройства iOS) отправит HTTPS-запрос с помощью Proxy Config. Первый запрос - это запрос CONNECT к Proxyman / Charles Server.

3. Proxyman принимает его и возвращает 200 OK Status.

4. Ваше приложение и сервер Proxyman будут выполнять рукопожатие SSL.

Чтобы добиться успеха, вы должны установить и доверять сертификату Proxyman / Charles CA, который является самозаверяющим сертификатом.

• Для macOS: установите System Keychain.app и доверяйте ему
• Для iOS: вам необходимо посетить http://proxy.man/ssl (или http://chls.pro/ssl)

4.1. Proxyman извлекает ключ хоста из предыдущего запроса CONNECT и начинает получение фактического сервера сертификатов.

4.2. Proxyman анализирует сертификат и получает всю информацию о сертификате, такую ​​как организация, имя, общее имя, альтернативное имя субъекта (DNS и IP-адрес) и т. д.

Насколько мне известно, Чарльз Прокси не выполняет этот шаг. Он просто генерирует базовый листовой сертификат. Некоторые клиенты могут обнаружить недостающие данные в листовом сертификате и отклонить его.

4.3. Proxyman начинает генерировать листовой сертификат с помощью Proxyman CA Certificate. Важно создать тот же сертификат, в котором будет та же информация с сервера.

Если это приложение для macOS / iOS, убедитесь, что сертификат соответствует новому требование безопасности от Apple. В противном случае он может быть отклонен.

Этот шаг можно реализовать с помощью библиотеки OpenSSL или BoringSSL.

4.4. Сервер Proxyman отправляет листовой сертификат обратно клиенту. 4.5. Клиент проверит листовой сертификат, и он будет передан. Потому что сертификату CA доверяют в их системе и он проходит базовую оценку, например:

• Общее имя и DNS-имя должны совпадать с хостом.
• Срок действия не истек
• Используйте алгоритмы шифрования приема
• и больше

5. На этом этапе рукопожатие SSL завершено, и клиент начинает отправлять HTTPS-запрос.

6. Proxyman теперь действует как сервер, поэтому Proxyman может расшифровать прочитанный запрос HTTPS в виде обычного текста.

7. Proxyman теперь действует как клиент и подключается к серверу. Тогда начните отправлять запрос. Этот шаг действительно прост, потому что сертификат сервера подписан известным сертификатом CA.

8. Как только Proxyman получает ответ, Proxyman читает его и отправляет обратно клиенту.

9. Клиент получает ответ и работает в обычном режиме.

Поскольку Proxyman может видеть запрос / ответ в виде обычного текста, он может отображаться в приложении или выполнять несколько инструментов отладки для изменения данных, таких как Карта местная, Сценарии, Точка останова и т. д.

Это длинный ответ, и я надеюсь, что смог ответить на ваше беспокойство.