Как прокси работает с https трафиком?

Question

[NubasLol]

Вопрос может очень простой, но я реально не нашел ответ. В целом мне интересно, как работает прокси на https сайты, конкретно в моменте установки соединения и обмена ключами. Может ли прокси сервер перехватить ключи и расшифровать весь мой трафик или нет, и по какой вообще схеме это примерно работает?

Answer 1

[Армянское Радио]

Прокси не может ничего перехватить, если вы не установите себе сертификаты от прокси.

Трафик пропускается или насквозь без модификации, или с него просто снимается вся защита, но тогда вы это увидите (HTTPS превратится в HTTP), а некоторые браузеры, обнаружив такие вольности с помощью HSTS начнут ругаться

Comments

[NubasLol]

Трафик пропускается или насквозь без модификации

можно подробнее о механизме?

[Армянское Радио]

NubasLol, Насквозь без модификации - это метод CONNECT(), а если прокси прозрачный - обычный роутинг. Вытащить данные при этом невозможно, кроме IP, и в некоторых случаях - URL

Answer 2

[galaxy]

Очень просто: прокси работают с https с помощью HTTP метода CONNECT. По сути это просьба клиента: а открой-ка мне TCP соединение до такого-то адреса, дальше я уже сам.

Прокси может попытаться перехватить и подменить TLS handshake, но для этого ему нужно иметь валидный сертификат для требуемого сервера или сертификат доверенного УЦ (тогда он на лету сможет сгенерировать поддельный сертификат).

Comments

[NubasLol]

Тоесть, я правильно понял, что это должно работаь примерно как NAT?

Типо прокси сервер знает, что запросы c ip клиента на порт N прокси сервера нужно передать на ip сайта. Где-то хранит у себя в памяти эту информацию.. Но ведь сайт не знает, что работает с прокси и запрос получает с с ip и портом именно прокси сервера, и ему отсылает ответ. А уже прокси этот ответ пересылает клиенту..

[galaxy]

NubasLol,

Тоесть, я правильно понял, что это должно работаь примерно как NAT?

Схема похожая в чем-то, но есть существенные различия:
- клиент знает о существовании прокси и сам просит открыть туннель до сайта в CONNECT (про NAT клиент не знает, хотя может догадываться)
- получается два TCP соединения: клиент-прокси (то самое, по которому шел CONNECT) и прокси-сервер. Прокси с момента ответа на CONNECT и успешного соединения с сервером просто пересылает все данные, приходящие на первое соединение по второму и наоборот. В отличие от NAT, где соединение одно, но происходят манипуляции со служебными заголовками TCP/IP пакетов.

Бывает еще вариант прозрачного https прокси, о котором не знает клиент и в котором не используется CONNECT, но это по сути ничем не отличается от роутинга/NAT (если, конечно, прокси не имеет возможности перехватить TLS соединение, для чего нужны сертификаты).

Выше давали ссылки на squid с его ssl модулем, он умеет все три вида проксирования. Т.е. при наличии сертификата он может на лету создавать поддельные и перехватывать TLS трафик полностью. Он поддерживает CONNECT и прозрачное проксирование. Последние варианты мало что дают в плане контроля трафика, т.к. соединение будет зашифровано и прокси имеет доступ только к IP адресу/порту сервера, адресу, указанному в CONNECT, к домену, указанному в SNI - поле первого TLS сообщения клиента (не всегда), и домену(ам), которые есть в сертификате сервера. Это можно логировать или, исходя из этих данных, запрещать соединение.

Answer 3

[CityCat4]

Не только может, но именно так он и работает :)

Как это работает - хорошо написано здесь Прокси с бампингом (это так называется) - основа всех корпоративных прокси. И возможно наше общее будущее :D

Comments

[Армянское Радио]

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

[CityCat4]

Армянское Радио, Ну да. Либо сертификат самого прокси, который он использует для генерации "типо-сертификатов", либо сертификат CA, издавшего сертификат для прокси. Впрочем, в корпоративной сети как правило, корневой сертификат(ы) корпоративного CA автоматом пихаются в доверенные.