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

[Amos Jeffries]

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