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
signature.asc
Description: Detta är en digitalt signerad meddelandedel
