Re: [squid-users] Intercepting HTTPS with WCCPv2

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.

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.

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

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

> Things might only partially break if TPROXY isn't enabled. The server
> would see the conection from the Squid IP, not the client IP, but the client
> wouldn't know the connection was being redirected. Unless, of course,
> the server is doing some kind of IP based authentication or whatnot.

That's the same when using normal proxying.

Regards
Henrik