https proxying

Hi,

here is a related irc discussion with hno concerning https proxying:

<John-Pine_> my actual need would be to enable url rewriting in
transparent mode for https connections. It seems that the
 url_rewrite_program isn't called when the client first sends a
CONNECT request to squid
<hno> ok. sslbumw was merged into squid-3 some time ago, but it most
likely only supports conNECT initiated requests, not transparent
 interception, but i have not followed the development of that feature
very closely.
<John-Pine_> i've talked with rousskov who confirmed me that
interception work with WCCP
<John-Pine_> it seems that no testing have been done to check whether
it works with typical iptables interception,
 but as wccp rely on it, i guess it should work
<hno> hmm. i wonder if it acts as a CA, or just using a static cert.
<John-Pine_> problem with 2.x was that when called, the url rewriter
only sees the IP of the distant serv, but can't check the
 GET url to know the domain name
<hno> yes, as SSL encrypts everything..
<John-Pine_> i suppose that using a static cert would alert the
client's browser that someone might be hijacking the secure connection
<hno> to see the request you need to break open thee SSL
<hno> yes, and even if it's running as a CA unless you install the
proxy CA certificate as a trusted certificate authority in each
browser
 usinng the proxy...
<John-Pine_> clients would have to definitively accept the CA when 1st
CONNECT is performed, which could not be suitable
 for production use
<hno> no, cöients can only accept individual site certivicates, not a
full CA. Getting a CA installed is a somewhat longer process..
<John-Pine_> it's my bad, i was refering to the static cert option.
<John-Pine_> but the problem remains the same :p
<John-Pine_> i was wondering: when ssl_bump is enabled, the
url_rewriter will be called only for the server-side connection,
right?
<hno> ther the clients will get a site name warning on each site they
visit, on each browsing session. No option to ignore that check.
<John-Pine_> i'm sorry to bother you this much, but there's still
something i don't understande
<John-Pine_> when a client connects to a distant server, and before
the ssl negociation is established, i can see with tcpdump some
 clear informations, and particullary the url requested
(mail.google.com in my test)
<John-Pine_> would it be possible to create a squid module allowing to
get this url while running in transparent mode, and eventually
 rewrite it using url_rewrite_program?
<hno> Yes, some modern clients send the sitename SSL option in the
negotiate packet. And it's helpful when doing interception
 and acting as a CA. But idealy you'd like to mirror the actual site
SSL certificate just replacing the key,
 and CA if the certificate verifies OK.
<hno> but I guess that's sslBump version 3..
<hno> Been reading the sslBump changes and it looks like it's using a
static cert to answer CONNECT requests.
 The equivalence in transparent interception is to forward the traffic
to a https_port.
<hno> technically works, but not something one would use in production
yet due to the unavoidable SSL warnings..
<hno> so a good next task would perhaps be to
<hno> a) Add a basic CA capability, and use this on CONNECT requests
to issue a temporary certificate with the correct site name.
<hno> b) In https_port do the same but using the site name from the
client hello packet instead of CONNECT.
<hno> actually 'a' is optional. 'b' would work for both as long as the
client is sending this SSL option..
<hno> Anyway, this discussion is best held on suqid-dev.

as far as I understand, the goal would be to intercept on-the-fly
https connections and mirror the original certificate to avoid
client's browser warnings, instead of using a static certificate.

the interesting field in the ssl header is named "Extension: server_name".

I'll post in a few days a list of browsers/versions implementing this option

Marc
Received on Sun Feb 24 2008 - 16:00:40 MST