TCP 443 The Universal Firewall Port? Not!

Most network security administrators will by default not allow outbound VPN connections from their networks to other networks. This makes good sense, since once an outbound VPN connection is established from your network to another network, you immediately expose any security issues on that network to your network. You have no idea what they’ve done on the other side of the VPN connection to secure their network, so it’s wise to block outbound VPN connections.

So what’s this have to do with the concept of the “Universal Firewall Port”? TCP 443 is often referred to as the Universal Firewall Port because almost all firewalls allow outbound access to TCP port 443 to any location and any content. This is somewhat black humor, since they refer to TCP 443 as the Universal Firewall Port because they feel helpless about controlling what moves over the encrypted SSL channel. Regardless of whether you’re using a stateful packet inspection firewall or a Web proxy based firewall, you’re not going to be able to see the contents of that SSL communication (maybe — read on).

Now, what does VPN and the Universal Firewall Port have in common? The new Microsoft VPN protocol, the Secure Socket Tunneling Protocol or SSTP. SSTP is essentially PPP/SSL, which means that you no longer have to worry about firewalls that block outbound PPTP or L2TP/IPSec connections. Since all firewalls and Web proxies allow outbound SSL (TCP 443), SSTP will work in just about any environment.

This might make you believe that you’re helpless at blocking SSTP VPN connections, since the Universal Firewall Port TCP 443 is almost always be opened outbound. You might think that you’ll no longer be able to control outbound VPN connections because the SSL session cannot be inspected. Hence, the sense of helplessness.

Fortunately, the fact is that TCP 443 is not a Universal Firewall Port. True, if you’re using a simple stateful packet inspection only firewall, you’re out of luck, but you’ve been out of luck for quite some time. However, many proxy based firewalls and dedicated Web proxies are able to look at the information in the HTTP header and block connections based on that header information. This is true for SSTP.

If you check out the RRAS Team Blog, you’ll see that there is a value in the HTTP CONNECT header that you can configure your firewall to block (SSTP_VERSION:*). By configuring your Firewall (such as an ISA Firewall) to block connections that include SSTP_VERSION:* in the CONNECT header, you can block the SSTP connection. So much for the myth of the Universal Firewall Port.

But, SSTP isn’t the only issue. What about Web content that’s downloaded over an SSL connection? CONNECT header control isn’t going to allow you to control access to that content. Same is true for anonymous Web proxies. So are we helpless and has the Universal Firewall Port gained some credibility?

No. There are solutions that allow firewalls and Web proxies to inspect the contents of SSL encrypted sessions. These devices are able to do this by performing “outbound SSL bridging” where the clients terminate their SSL session with the firewall and the firewall impersonates the destination Web site. The firewall essentially acts as a Good Guy in the Middle (GGITM) to make sure that users aren’t downloading exploits and malware into your network over an encrypted SSL tunnel.

ISA Firewalls with Collective Software’s ClearTunnel (www.collectivesoftware.com) and Blue Coat Web proxies are the two most common devices used to perform this kind of SSL content inspection. Devices like these prove that there is no “Universal Firewall Port”, that is, unless you don’t want to shut down the SSL hole on your network by failing to deploy these solutions.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: [email protected]
MVP – Microsoft Firewalls (ISA)