Re: [SQU] transparent proxy of https needed (I have RTFM'd)

This /cannot/ be done, ever. If it could, then SSL wouldn't be very
secure, now would it? (Man in the middle attacks would become very easy.)

SSL authenticates both sides of the connection...And if Squid is in the
middle (transparently--meaning nobody, server or client knows it's
there) then each side tries to authenticate to the Squid box, which is
not the correct server or client. The connection must fail. No way
around it without breaking encryption.

When you have a traditional proxy in the middle, the http spec allows
the proxy to tunnel the requests and the answers, and since both sides
know the Squid is there, it all works out fine.

Let me clarify this further...When a web cache acts transparently
(interception proxy is the accurate term, but I can't remember to use it
either most of the time) it becomes the server for that client, and it
becomes the client for that server. The connection between the two
parts is broken and the identity of each is hidden (from the ssl
standpoint). And there is nothing short of decrypting and recrypting
every packet that comes through that will solve that. Thankfully, it's
still no mean feat to crack 128bit RSA, and we certainly can't do it inline.

Now, what you have is a routing question. If you configure your Squid
box to split traffic (roughly) across the internet with a proper
netmask, or whatever it is you'd like to achieve, then you'll be able to
send whatever traffic you want to whatever interface you want to. The
Advanced Routing HOWTO at the LDP has lots of good info on this topic,
and is a very informative read.

Good luck!

Ian wrote:

> Hi,
>
> before this message is dismissed as yet another "why can't I proxy
> https?" post, I would like to say that this is an informed
> question, that I am unable to find the answer to in the docs, faqs,
> or mail archives.
>
> I have set up a transparent proxy on our gateway, and am using
> ipchains to redirect outgoing port 80 requests to 3128 on the
> localhost (squid). This is working fine for all http traffic. All
> other traffic (including https) is currently masqueraded, and that
> works fine.
>
> I wish to transparently "proxy" 443 (https) traffic also - even
> though I know squid will simply retrieve the https url via a DIRECT
> request. The reason I want to do this, and not masquerade is this:
>
> internal -> gateway -> isp1 -> internet -> isp2 ->
>
> we have two squid configurations, one for isp1 and one for isp2. By
> default, all http traffic travels through isp1. However, if this
> goes down, we use our second squid configuration and point all
> traffic through isp2. There are differences between both squid
> configurations, as each isp provides a different set of parent
> caches.
>
> Now, when isp1 fails, and we move our configuration to isp2, all
> http traffic is succesful. https, however, still fails because
> masquerading is still configured to go out isp1. If we could
> transparently "proxy" https, then we can redirect all web (http,
> https) traffic out through either isp with a single "flick of a
> switch".
>
> I tried to transparently proxy https by simply redirecting 443
> traffic to 3128 on localhost, just like what we do with http
> traffic. This does not work - browsers are unable to view https
> sites, and squid does not log any requests for the sites. Setting
> the gateway as a proxy in the browser, however, enables viewing
> https sites through squid. It would be great if we could
> transparently proxy https traffic, so we can easily redirect all
> web traffic out through either isp1 or isp2 in "one go", without
> having to reconfigure masquerading as well.
>
> I find this situation odd, and I have looked through the manuals,
> faq, and mailing lists in search for an answer. While many people
> have asked this question, the reply i constantly find is "why do
> you want to?", or "just use masquerading". I hope I have presented
> a plausible reason as to why I want to transparently "proxy" https
> traffic.
>
> any help or advice would be greatly appreciated,
>
> rgds, Ian.

                                   --
                      Joe Cooper <joe@swelltech.com>
                  Affordable Web Caching Proxy Appliances
                         http://www.swelltech.com

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html