Security Advisor

You Can't Always Trust SSL

Don't be fooled by that lock icon in your browser. Outgoing SSL traffic can still give you something to worry about.

• By Joern Wettern
• 01/01/2009

SSL was designed to enable authentication between a client and a server, and to allow these computers to securely exchange session keys that are then used to encrypt the remainder of the session. In the process, the Web server sends a certificate to the client and uses the corresponding private key to prove its identity. Assuming that the certificate has been issued by a certificate authority (CA) the client trusts, the connection gets established and nobody can intercept the communications between the two computers. Obviously, confidential communication is what makes electronic commerce possible and is also a prerequisite for many other uses of the Internet. At the same time, this encryption makes it impossible to inspect the traffic anywhere other than at the client or the server, and this can create a threat to your network's security. No matter how good your firewalls and intrusion-detection systems are at inspecting HTTP traffic, they won't be able to look into the encrypted SSL traffic to detect viruses, spyware or activities that are against company policy.

Breaking End-to-End Security
Firewalls that can inspect incoming connections to Web servers have become fairly common. For example, Microsoft's ISA Server has included SSL Bridging for several years. When publishing a Web server to the Internet with ISA Server or similar products, you can install the certificate and private key at the firewall. As a result, the firewall can impersonate the Web server to the client. Because it's the endpoint of the client's session, it can examine the traffic and forward legitimate requests to the Web server.

However, if it encounters undesired traffic, such as attacks against the Web server, it can simply drop it. Technically, doing such SSL inspection is a man-in-the-middle attack, as the edge device pretends to be your Web server. However, because you use a certificate that has been issued to your organization, users are still assured that they are indeed connecting to the right company and that the traffic across the Internet can't be intercepted by anyone. Technically, a bridged connection is not the same as a direct connection to your Web server, but it fulfills the authentication and confidentiality expectations while allowing you to protect your network.

[Click on image for larger view.]

Outgoing SSL connection for content inspection.

Today, few companies are inspecting outgoing SSL traffic, but this is changing as more firewalls and proxy servers are starting to offer the capability to do so. There are good reasons to scrutinize these connections. Even though they're initiated from inside your network, malicious software may infiltrate your network through them. Most often this occurs when a user inadvertently clicks a link that points to dangerous content. If this is a link to an SSL site, the HTTP response is encrypted and received by the client computer without letting the firewall or intrusion detection system inspect it. Companies that restrict or log their employees' Web traffic have also long been frustrated by SSL because a user who may be blocked from accessing certain Web content over HTTP can bypass existing controls by connecting to a disallowed site using SSL. Enterprising users may also access sites you're blocking via an external proxy server and SSL to hide what they're doing. So, whether you're concerned about scanning Web traffic for dangerous content or controlling users' Web browsing, there's a real need to look into outgoing SSL traffic.

How Does It Work?
To perform SSL inspection, proxy servers and other gateway solutions establish two separate sessions. The session from the client is terminated at the proxy, which then establishes a separate connection to the external Web server. Traffic flowing across each of these connections is encrypted, but the proxy server can decrypt it, filter it and then immediately re-encrypt it.

Considering that SSL promises end-to-end security, you may think that cracking open the secure tunnel isn't possible without alerting the user that something unusual is going on. For example, when a user connects to Redmondmag.com, the Web browser expects the server to prove that its certificate matches the site name and that the certificate was issued by a trusted CA. When a proxy server acts as the endpoint of an SSL tunnel to the client, it certainly doesn't have a valid certificate for Redmondmag.com or any of the millions of other Web sites that users may try to access.

To get around this, SSL inspection solutions normally create certificates on the fly that they present to the client. This can be done very quickly and for any Web site a user may try to access. Creating certificates on the fly leads to a problem, though. Unless the certificate was issued by a trusted CA, the Web browser will warn the user and recommend against proceeding. Users should certainly heed this warning because they generally can't verify whether the certificate was issued by a device on their network or some impostor on the Internet. To make everything look normal, you must configure each browser to trust certificates that were created by the proxy server. To do this, you add its certificate to the browser's list of trusted root CAs. You can even centralize the deployment of the certificate by using Group Policy, for example.

Beyond Technology
Any organization that's currently inspecting outgoing Web traffic should consider adding SSL inspection to their arsenal of network defenses. However, doing so requires some careful planning. The technical aspects of implementing SSL encryption are easy compared to dealing with user reactions. Inspecting SSL traffic potentially allows you to capture traffic that your coworkers expect to be confidential. Imagine the reaction when someone who checks her bank account during the lunch break finds out you might be able to look at the traffic and see that her account is overdrawn. SSL inspection will be viewed as an invasion of users' privacy unless your company already has a clear policy against Internet use for personal reasons. Whether users are allowed limited personal use of the network or not, there needs to be clear procedures determining who can review firewall logs and what traffic may be captured. Your policies should make it clear that SSL traffic may be reviewed or filtered to help secure the company network, and these policies should be well publicized. Depending on where you're located, there may also be legal implications of monitoring employee network traffic, so you may have to get additional advice for designing this part of your security policy.

SSL inspection is rapidly transforming from a niche technology to a standard feature in proxy servers and firewalls as an increasing number of vendors of such devices add this capability. If you haven't implemented this protection in your network yet, you may have to soon. Before that time comes, think thoroughly about how you will sell it to your coworkers.