Re: https proxying

Reading the discussion again, and there is some doubts if we talked
about the same thing. Is getting the requested site name sufficient for
you, or do you need the full URL including filename?

In normal proxy operation with CONNECT you get the site name:port, but
not the requested URL-path on that site. I don't know of any browsers
who perform their own DNS lookup when using CONNECT, but it's
theoretically possible to do so.

SslBump is about decrypting the https traffic, getting full access to
the HTTP converstaion including the exchanged content. This requires
breaking open the SSL wrapper by terminating the SSL at Squid and
opening a new SSL connection to the requested server. This is not
possible without security warnings.

Squid today cannot process intercepted https traffic without also
decrypting it. Priority has not been given on this as it's not related
to HTTP, just shuffling of TCP data. Adding some sniffing of CONNECT SSL
payload to decode the SSL handshake would indeed be useful, and would
also make it meaningful to support transparent interception of https
without decrypting it. But you won't be able to rewrite anything at that
state, just drop the connection.

Regards
Henrik

mån 2008-02-25 klockan 00:00 +0100 skrev marc impini:

> 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