> 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
