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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
