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
