<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 25/05/15 04:25, James Lay wrote:<br>
</div>
<blockquote cite="mid:1432484742.3702.17.camel@JamesiMac"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="GENERATOR" content="GtkHTML/4.6.6">
My first question is about properly creating the certs. Looking
at:<br>
<br>
<a moz-do-not-send="true"
href="http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit">http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit</a><br>
<br>
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:<br>
<br>
</blockquote>
<br>
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<br>
<br>
CONNECT github.com:443 HTTP/1.1<br>
<br>
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<br>
<br>
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)<br>
<br>
In pseudo-code, it looks like this<br>
<br>
if http_port and "CONNECT (.*) HTTP" then sni_name=$1<br>
else if https_port and "peek" then sni_name=find_sni($ipaddress)<br>
else if https_port then sni_name=$ipaddress<br>
<br>
<br>
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. <br>
<br>
<br>
<pre class="moz-signature" cols="72">--
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
</pre>
</body>
</html>