Прокси подменяет сертификат: что происходит с HTTPS

Что именно происходит при HTTPS

HTTPS строится поверх TLS. Клиент устанавливает защищённое соединение с сервером и проверяет его сертификат. Сертификат связывает доменное имя с открытым ключом сервера и подтверждается доверенной цепочкой сертификации.

В обычной схеме посредник пересылает зашифрованные данные и не знает содержимое защищённого соединения.

Но представим другую архитектуру.

Вместо одного соединения появляются два:

клиент → посредник

и

посредник → целевой сервер

Посредник завершает TLS на своей стороне, получает доступ к содержимому, а затем создаёт отдельное соединение с исходным сервером.

Это и есть принцип MITM-перехвата.

Как прокси вообще может сделать это с HTTPS

Главное препятствие здесь — доверие к сертификату.

Если браузер ожидает сертификат сайта, а вместо него получает сертификат, подписанный неизвестным центром сертификации, он должен выдать предупреждение.

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

Один из распространённых вариантов — установить собственный корневой сертификат на устройство. После этого прокси может выпускать сертификаты для посещаемых доменов, которым клиент будет доверять. Такой подход используется, например, в корпоративной инспекции трафика.

То есть MITM не «ломает HTTPS» математически.

Он меняет структуру доверия вокруг соединения.

Почему браузер может ничего не показать

Это самая важная часть темы.

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

Это неверно.

Если клиент доверяет сертификату, который использует посредник, TLS-соединение для браузера выглядит корректным.

Сертификат валиден относительно доверенной цепочки. Соединение шифруется. Сайт открывается.

Но шифрование происходит уже на двух отдельных участках:

клиент ↔ посредник

и

посредник ↔ сервер

Сам посредник находится между ними и может видеть расшифрованное содержимое. Принцип такой схемы подтверждается и документацией по корпоративному перехвату TLS: доверенный клиентский корень позволяет прокси выступать в роли промежуточного участника соединения.

Поэтому отсутствие ошибки браузера — не доказательство отсутствия перехвата.

Когда MITM бывает нормальным

MITM не является автоматически атакой.

Есть полностью легитимные сценарии.

Например, организация может контролировать свои устройства и использовать TLS-инспекцию для анализа трафика, обнаружения вредоносного содержимого или выполнения корпоративной политики.

Такой сценарий предполагает, что доверенный сертификат установлен осознанно и инфраструктура принадлежит самой организации.

Другой вариант — отладка.

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

В таких случаях перехват — инструмент диагностики.

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

Почему «HTTPS работает» ничего не доказывает

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

Он не отвечает на вопрос:

проходили ли данные непосредственно между ними или их кто-то расшифровывал по дороге?

При корректно настроенном MITM оба TLS-соединения могут работать нормально.

Никакого сбоя приложения при этом не происходит.

Именно поэтому искать проблему только по видимым симптомам бесполезно.

Удачный перехват как раз и стремится выглядеть как обычный рабочий трафик.

Что происходит с сертификатом

При обычном соединении браузер получает сертификат, связанный с целевым доменом и цепочкой доверия.

При TLS-инспекции посредник создаёт другой сертификат для клиента.

Для пользователя доменное имя может выглядеть привычно, а соединение оставаться действительным, потому что новый сертификат подписан центром сертификации, которому устройство доверяет.

Отсюда важный вывод:

сам факт наличия сертификата ещё не показывает, что сертификат принадлежит исходному серверу напрямую.

Нужно понимать, кто его выпустил и почему этому центру сертификации доверяет ваше устройство.

Как понять, есть ли перехват

Есть несколько подходов.

Первый — изучить сертификатную цепочку и сравнить её с ожидаемой.

Если сайт обычно использует одну цепочку доверия, а через определённый прокси появляется другая, это может быть признаком TLS-инспекции.

Но ручная проверка сертификатов плохо подходит для большого списка прокси.

Здесь проще иметь отдельный тест, который оценивает, изменяется ли трафик по пути.

Именно такой MITM-тест входит в Proxy Checker. Он рассматривает изменение трафика как самостоятельное свойство прокси, а не делает вывод только по тому, был ли получен HTTPS-ответ.

Не всякий MITM означает компрометацию

Нельзя делать обратную ошибку и считать любой обнаруженный перехват атакой.

Результат проверки говорит:

трафик изменяется по пути.

Дальше уже нужно выяснить контекст.

Это корпоративный шлюз?

Антивирус?

Отладочный прокси на вашем компьютере?

Собственная инфраструктура?

Если вы знаете, почему используется TLS-инспекция и доверяете этой схеме, результат может быть совершенно нормальным.

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

Почему бесплатный прокси может быть особенно интересным случаем

Если посредник контролирует ваш HTTPS-трафик, у него потенциально появляется доступ к содержимому тех соединений, которые он успешно перехватывает.

Поэтому вопрос при выборе неизвестного прокси звучит не так:

«Открывает ли он сайты?»

Гораздо важнее:

«Что происходит с трафиком между мной и сайтом?»

Именно поэтому MITM стоит проверять отдельно от доступности, задержки и внешнего IP.

FAQ