On Mon, 2015-05-25 at 08:48 +1200, Jason Haar wrote:
On 25/05/15 04:25, James Lay wrote:
My first question is about properly creating the certs. Looking at:
http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
this mentions using crtd, but as I understand it, crtd isn't supported when using transparent proxies. So, with no crtd, as I understand it this is what I'll need:
I don't know where you got that from, but that's not true. I think you are confusing the issue that when squid is used as a transparent HTTPS proxy, it lacks the "easy" hostname details that a formal (ie non-transparent) proxy has. ie when a browser asks for a secure website via a formal proxy, it sends
CONNECT github.com:443 HTTP/1.1
So squid knows *in advance* the server is called "github.com". So it connects to github.com, downloads the public key and then uses crtd to create a clone of it - identical except that it's signed by your self-created Squid CA instead of Verisign/whatever
Compare that with transparent proxy mode, where all that squid knows is that a browser has had it's outbound tcp port 443 traffic to 192.30.252.128 redirected onto it, so it doesn't know that is github.com. If you are using squid-3.4 or less, that's all there is to it - there's no way to figure out the cert name in a guaranteed fashion (there are hacks, but my own experience is that they can only work up to 95% of the time - and break for some of the largest sites). With squid-3.5 there is "peek" - which means squid can let the initial few packets through (ie act like "splice") - which is enough to see the client send the SNI request to the https server and get the reply. So "peek" allows squid to learn about the true server name of the https server. At that point *I think* squid creates a forged cert, then creates a new connection to the server, then links together the existing client tcp channel with the new proxy->server tcp channel and carries on intercepting (I think that's the outcome - there would have to be some extra smoke-n-mirrors in there to make that happen)
In pseudo-code, it looks like this
if http_port and "CONNECT (.*) HTTP" then sni_name=$1
else if https_port and "peek" then sni_name=find_sni($ipaddress)
else if https_port then sni_name=$ipaddress
When all is said and done, transparent HTTPS intercept is the very last thing you should be working on. You need to gets squid working 100% as a formal proxy - and only then start looking at making that work in transparent mode. And you *definitely* want ssl_crtd.
--
Cheers
Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
Thanks for the great response Jason...I appreciate it. I think maybe I misread this:
http://wiki.squid-cache.org/Features/DynamicSslCert
"While SslBump itself works fine in transparent redirection environments (e.g. those using WCCP or iptables), dynamic certificate generation does not: To generate the certificate dynamically, Squid must know the server domain name. That information is not available at the time the HTTPS client TCP connection is intercepted and bumped. Currently, you cannot use dynamic certificate generation for transparent connections until bump-server-first is supported."
Is this no longer accurate with now that peek/splice has been implemented?
Thank you.
James
|
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
