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

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

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

NubasLol,

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

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

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

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