[squid-users] Ssl-bump deep dive (properly creating certs)

[James Lay]

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 at lists.squid-cache.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150524/30f22ebb/attachment.html>