Re: [squid-users] Intercepting HTTPS with WCCPv2

tor 2006-12-21 klockan 10:09 +0800 skrev Adrian Chadd:

> 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.

Certificates can be signed with any name, but the browsers will complain
if the certificate does not contain the exact requested hostname or a
matching wildcard either in the DN or in a specific attribute for the
purpose..

> 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.

Yes, but so would doing the same thing without TPROXY. Only difference
is which IP the server sees as source IP. The ssl/tls crypto does not
care, but server side access controls may care just as it might for
http.

> 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.)

SSL does not care, neither does most servers.

In fact if you are not using TPROXY then most servers is more happy with
this as then https and http is both coming from the same source IP (the
proxy).

> 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.

No clients or servers have support for the null crypto unless manually
enabled in the settings, but there is some attacks on SSLv2 where a
man-in-the-middle can force the clients to downgrade to very low grade
encryption unless disabled in the crypto profile, which isn't far from
the same thing.. (i.e. 40-bit DES or similar grade)

> I believe just intercepting the HTTPS TCP connection to feed through
> ACLs and delay pools would be a positive benefit.

And very simple thing to do. But most admins will be very confused when
this traffic will bypass any domain checks. Only ip checks are valid
without decrypting the traffic.

> 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..

Intercepting https in tunnel mode will work fine, TPROXY or not. But it
must be real interception where the proxy/tunnel can tell the original
destination address from the connection as no details about the request
as such is available in the normal case..

To the client and server it's the same as if the connection had been
SNAT:ed when not using TPROXY. And with TPROXY it can look like a direct
connection without SNAT.

Regards
Henrik