Re: [squid-users] Intercepting HTTPS with WCCPv2

On Thu, Dec 21, 2006, Henrik Nordstrom wrote:
> ons 2006-12-20 klockan 14:22 +0800 skrev Adrian Chadd:
>
> > The trouble is breaking the end-to-end-ness. I think it'd be fine
> > if you ran Squid in TPROXY mode and had all the SSL connections redirected
> > and spoofed accordingly. Then both ends think they're talking directly
> > to each other.
>
> Not sure I follow. There is several end-to-end aspects. The TCP/IP level
> is the minor one here, no different for https than http. SSL/TLS does
> not depend on TCP/IP level end-to-endness, only stream end-to-endness.
> It relies on certificates to validate the endpoints, not transport level
> properties such as IP addresses.

I could've sworn I've seen certificates signed with the IP address of the
server in the past, rather than the current practice of signing w/ website
name.

> Being able to intercept SSL/TLS without shouldn't depend on TPROXY at
> all. Needs a different xxx_port where connections is internally
> translated to tunnel requests very much like CONNECT ip:port.

Using TPROXY allows you to transparently proxy the TCP/IP connection without
either side necessarily knowing there's a proxy in the middle. It does mean
you can't get your grubby hands into the stream to figure out whats going on
without causing issues, like you've noted below, but it would allow admins
to apply basic ACLs on intercepted HTTPS connections.

You could do it without TPROXY, sure - the client would think its talking
direct to the server IP but the server wouldn't see the client IP. I'm not
sure there's any easy way (sans decrypting the SSL stream and re-encrypting
it before forwarding) to indicate that you have. This could make things
somewhat dangerous (eg breaks forwarding loop detection.)

> Breaking the stream level end-to-endness is more interesting. Requires
> Squid to fake a CA that it trusted by the clients to get rid of the
> certificate warning, and clients either configured to use the proxy or
> sending the TLS extension advertising the requested host..

I've seen people do this before. In fact, I remember reading something
talking about "interfering" with the encryption negotiation to encrypt
the session w/ no encryption but i could be very misled. I have to admit
I haven't looked into SSL stuff at all for a number of years now.

> To play with breaking the stream end-to-endness try transparently
> redirecting traffic to an https_port with the transparent option.. It
> will work, save for the small detail that clients will complain about
> the certificate mismatch on every visited site.
>
> The hardest part is actually the CA management and server certificate
> verification policy, the clients will place their trust in the proxy.
> Wouldn't be too good if the proxy wraps up a bogus/faked site with a
> trusted proxy certificate...

I believe just intercepting the HTTPS TCP connection to feed through
ACLs and delay pools would be a positive benefit. I'm a bit worried
about loop detection and prevention but I'd be more worried about clients
seeing invalid SSL certificate warnings. This is especially going to be
an issue with IE7 and its "anti-phishing" stuff..

Adrian
Received on Wed Dec 20 2006 - 19:06:59 MST