Re: [squid-users] How Bad is CONNECT and Should I Prevent It?

> > Or better yet, use real MITM interception, and the https: proxies no
> > longer bypass your filters, since no SSL/TLS traffic can make it out
> > of your network alive.
>
> Ok, I give up. Can you describe the "real MITM interception" for me
> please?

Well, let's say you know that there are internal clients which talk to
the outside world using TCP/443 as the external destination port. You
want to do something about this.

Transparently you could:
1) Just do "deny" for all ports by default.
2) Implement on your router permit/deny IP filter rules to deny really
evil known bad IPs, or better yet, use permit rules to only permit
"known good" IPs.
2.5) Force the client to explicitly (not transparently) proxy via
something like Squid, with the proxy doing the same permit or deny
based on IP, hostname, domain name.
3) Let the traffic flow past a sniffer that knows what SSL is supposed
to look like, and spoof resets if it sees something funky.
4) Use a firewall or WCCP to route the traffic through a device that
does "application inspection" and perhaps "plug proxy" or NAT, also
doing inspection for what SSL is supposed to look like, but actually
directly closing down sessions that do not conform.

None of the above are really 100% effective, since it's trivial for
somebody to just use TLS so their traffic really is SSL, and tunnel
some arbitrary protocol inside TLS. That said, they are about 97%
effective, since quite a few tunnel tools just assume that TCP/443 is
wide open and don't bother making their traffic "look like" the real
thing.

The final option is to do "real MITM interception". That is, you have
a device on your network with acts as a Man In the Middle attacker
against SSL. When the client attempts to make an outbound connection
on TCP/443, he thinks he is talking to the remote server, but actually
he is talking to you.

When a client e does a TLS/SSL handshake to set up an encrypted
channel, they are really setting up that encrypted channel with your
box. Meanwhile, your box creates it's own TLS/SSL session out to the
real server on the Internet, and does it's own handshake. It then
proxies all the data back and for between the client and the server,
but because it is decrypting/re-encrypting in the middle of the
conversation, your box can actually inspect the cleartext protocol
inside the SSL and can mess with it, can rewrite it, can just outright
deny the conversation if it doesn't like what it's seeing.

"But isn't the whole point of SSL certificates that it prevents this
sort of chicanery!" comes the objection from the back of the audience,
swiftly followed by "But that breaks client certificates!" And while
both statements are nominally true, the fact is that aside from the
mainstream graphical browsers, many applications don't actually bother
with the server certificate checks, and I hardly ever see client
certificates. And even when the client does check the server's cert
and signatures, most end users hardly think twice about clicking
"okay" when presented with an "untrusted signature!" dialog.

And for Windows clients and mainstream browsers which *do* check the
server certificate, that is worked around in controlled environments
(schools, corporations, armies, etc) by generating a private root
server certificate on the box which is doing the interception, and
pushing out that new CA key to all workstations with their next batch
of Windows updates.

While the above form of interception for SSL mitigation works, and can
protect clients from hostile servers and protect a "private" network
from unauthorized tunnels, that doesn't mean I don't personally
believe it presents a huge invasion of privacy, among many other risks
and objections. But evil or not, it does work.

Kevin
Received on Fri Jun 22 2007 - 20:11:12 MDT