Re: [squid-users] Ssl-bump deep dive (properly creating certs)
On 25/05/2015 8:48 a.m., 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) I dont think that is right. AFAIK, peek at step-1 lets the first few client packets buffer up inside Squid instead of leaving them in the TCP buffers. That way it can literally *peek* at the buffer contents to find the SNI without having consumed them. - which is enough to see the client send the SNI request to the https server and get the reply. That would be is step-2. Squid can selectively drain the buffered clientHello details toward the server (peek @ step-2). Or Squid can send its own ClientHello faked details (stare @ step 1 or 2) and repeat the peek process for the serverHello packets. So peek allows squid to learn about the true server name of the https server. This word true keeps getting thrown about in regards to the server name. Its just *a* name the client is aware of - one of many the server has usually. 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) AFAIK, the original server connection is still being used. This is stage-3. Squid should only have sent enough details to either splice (original clients details) or bump (Squid faked details). 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. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Ssl-bump deep dive (properly creating certs)
Hey all, SoI'm sure those on the list have seen my posts a number of times, usually all questions (sorry I'm not very helpful). That being said, whenever there is something I can't get to work right, or don't understand as well as I think I should, I do kind of a deep dive into it for about a month. I'm going to do that now with Squid. I have NEVER gotten ssl-bump to work right. I have it sort of working, but there are some issues I want to address. So I'm going to start from scratch in a lab environment using a VM as a client, a physical machine with two nics that are bridged and run squid as a transparent proxy, and a physical laptop as the server. 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: Server: Self-signed CA cert (pem) - used as cafile= in https_port Intermediate cert signed by the above self signed CA cert (pem) - used as cert= in https_port Key file for the self-signed CA cert above (pem) - used as key= in https_port Client: Self-signed CA cert from above (pem) - in /etc/ssl/certs for linux Any help, advice, links that would assist in better understanding this first step in ssl-bumping transparently would be wonderful. Thank you. James ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Ssl-bump deep dive (properly creating certs)
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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
