transparent ssl proxy: возможно?

Доброго времени, вопрос чисто из любопытства: удавалось кому-нибудь наколдовать сабж? Или это только я такой рак, что не сумел)) ? На squid или на чем-нибудь другом... Только я имею ввиду настоящий, который на самом деле transparent, без шаманства, обмана несчастных браузеров и кучи оговорок?

из

из http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/faq.html#features :

Цитата:
Interception proxying (sometimes confusingly called ‘‘transparent’’ proxying) is a technique that intercepts client connections at the network layer in order to redirect them at an application layer proxy.

Interception proxying is a fundamentally broken design (see for example this posting and RFC 3143 Section 2.2.2), and will not be supported by Polipo. If you want to use interception proxying in order to avoid manually configuring your clients, please ask your browser vendor to provide a proper protocol for client auto-configuration. If you want to use interception proxying for any other reason, you're probably doing something wrong.

(Or you're a fascist pig with a read-only mind.)

Это касательно «transparent» прокси (по ссылкам тоже полюбопытствуйте). А насчет шифрованного соединения через прокси – это что, предполагается, что прокси должен владеть всему приватными ключами клиентов? НЁХ, не?

Попытаться туннелить все

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

Локальный оверлей растёт

очень интересно, как это

очень интересно, как это должно выглядеть :) MITM прокси? :) плюс изоляция клиентоты от конечной точки подключения? то есть цепочка сертификатов клиентоте не_нужна? :)

Я имел в виду просто

Я имел в виду просто пробрасывать ssl-соединение как в HTTPS(CONNECT)proxy, только все подключения через iptables (как redsocks например пробрасывает всё через socks-прокси).

Локальный оверлей растёт

речь изначально шла о

Я лично (может и неправильно) понял ТС так: ему нужно проксировать (с нулевым конфигурированием у клиентов) HTTPS так же, как HTTP. Со стандартными целями – фильтрация/учет. Если же ему нужно просто проксировать TCP (с целью, например, обхода ограничений) через socks например, то можно конечно и redsocks+ипстолы, хотя мне больше нравится badvpn-tun2socks и PBR на его интерфейс. Хотя термин «прозрачное проксирование» в таком контексте употреблять довольно странно.

Вы задумывались зачем вообще

Вы задумывались зачем вообще ставят прокси сервер? Есть две цели: снижение объёма трафика за счёт его кэширования и фильтрация нежелательного содержимого.

Теперь к вопросу об ssl, при его использовании трафик шифруется и расшифровать его может только сервер и клиентский web браузер, кроме всего прочего данные, которые передаются шифрованными предназначаются только одному клиенту, тому, чей клиентский браузер имеет ключ для расшифровки. Отсюда вывод, что кэшировать этот трафик не имеет никого смысла, ибо он всё равно персонален и клиенты, использующие прокси сервер в любом случае его не запросят.

Поэтому для ssl вам нужно настроить NAT для 443 порта и всё.

kostik87, а что, кто-то еще

kostik87, а что, кто-то еще кэширует? :) Про все остальное уже немного более глубоко обсосано постами выше. Ну а насчет «каждому порту по своему NAT'у» я как-то не особо уверен в кошерности этого подхода.

Зачем каждому порту свой NAT?

Зачем каждому порту свой NAT? Nat нужен только для ssl, а 80 порт заворачивается на Squid.

стратегия образца начала

стратегия образца начала тысячелетия? :) оно и тогда-то было довольно убого, а сейчас (особенно в свете того, что тот же гугл намекает, что пора всем переходить на https) – ниже всякой критики. В целом – непонятно зачем вообще оно в таком виде, если управляется/аудируется только часть трафика. Ну и возвращаясь к формулировке ТС – «обначивание» трафика даже с великой натяжкой проксированием не назовешь :)

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".