In-Depth
Removing the Risks of SSL -- Part 1 of 2
Despite its name, Secure Sockets Layer isn't totally secure. We explain the risks that arise from increased use of SSL within enterprise networks.
by David Wells
Secure Sockets Layer (SSL) provides a secure communications mechanism that authenticates the server being communicated with and encrypts data to prevent it from being intercepted and read while within the network. SSL is one of the foundation blocks for all e-commerce activities and is also a key element in the use of cloud computing environments and Web 2.0 applications.
Internet users trust Web sites using SSL, indicated by names beginning https:// and the appearance of a padlock in the browser, and use it to communicate sensitive information including financial transactions. This makes SSL an attractive target for those with malicious intent. By tricking a user into believing that a “fake” Web site is actually a Web site users can trust because they are accessing the site using SSL, criminals can capture valuable information.
Likewise, illegally intercepting a user's SSL traffic within the network and capturing data without the user being aware provides another opportunity for crime. As a consequence, SSL includes strong mechanisms to prevent either of these malicious activities from happening. However, as recent Black Hat conferences have shown, there are ways that SSL can be attacked.
Some of these attacks rely on weaknesses in the Public Key Infrastructure (PKI) certificate-issuing mechanism rather than any weakness in SSL itself. The combination of certificate issuers with weak methods of validating the purchaser of a certificate and systems that allow “illegal” characters such as the “null” character in a certificate's common name, can allow “fake” sites to fool current browsers into thinking they are somewhere they are not. Breaking SSL authentication in this way allows a “fake” site to appear to be the genuine site the user was attempting to access.
Such attacks can be countered by changes to the browser code and by improvements in the certificate-issuing infrastructure, both of which are currently happening. The most recent versions of mainstream browsers can detect and prevent this type of attack, as can devices such as transparent SSL proxies in enterprise networks that allow policy control over the use of SSL.
An attack on the authentication element of SSL is unusual in that it can be carried out without the need for equipment installed that the SSL traffic passes through. Most attacks on SSL require that the SSL traffic pass through the equipment being used to launch the attack, hence the term “man-in-the-middle” (MITM) attack. Physical network security is the first line of defence against MITM attacks, since an MITM attack is not possible if the attackers cannot install equipment that the SSL traffic will pass through.
One new form of MITM attack described at the Black Hat conference was actually an MITM attack on HTTP rather than on HTTPS. This relies on the fact that many users initially go to an HTTP site before being re-directed to an HTTPS site. For example, the home page of an e-banking site may be http://whatever.com and when a user clicks on the login button it re-directs them to https://whatever-login.com. By intercepting the re-direct and preventing an SSL session from being set up with the client, the attacker can see the user's session because it is not encrypted. Typically, the MITM will have an HTTPS session to the server and an HTTP session to the client. To trick the user, the Web pages presented by the MITM will be made to look as if they are being accessed over HTTPS.
MITM attacks on HTTP are easy to avoid; the user simply needs to go directly to the HTTPS site rather than via an HTTP site. Bookmarking the login screen (such as https://whatever-login.com) results in no initial HTTP session and would prevent the attack.
MITM attacks on HTTPS are much harder because the SSL protocol is specifically designed to prevent this type of attack. To successfully use an MITM attack on an HTTPS session, the attacker not only must be able to install equipment that the SSL traffic will pass through and requires access to either the SSL server or the client system involved in the session. A successful MITM attack results in the client and server believing that they had an “end-to-end” SSL session between each other and that no-one was “in the middle.”
Attacks Using SSL Sessions
As the level of SSL traffic in networks increases, enterprises are becoming aware that SSL traffic is increasing the risks to their network, although it may seem paradoxical that increased use of encryption can increase the threats to an enterprise. To understand the threat, consider a typical enterprise network running a number of internal SSL servers hosting services for customers and also having internal users connecting to SSL services on the public Internet. The problem arises because the current enterprise security system that prevents incoming attacks on servers over HTTP cannot detect or prevent attacks over HTTPS. Therefore, devices such as Intrusion Detection Systems (IDS) or Intrusion Prevention Systems (IPS) are essentially blind to SSL traffic. At the same time, any enterprise security systems in place to detect and prevent unauthorized data leakage are also incapable of performing their function if the data leakage occurs within an SSL session.
To address the increased risk, enterprises require the means to allow the existing security infrastructure to work when the traffic is SSL. This can be achieved if an un-encrypted copy of the SSL flow is made available to the security appliance.
As noted earlier, to carry out a successful MITM attack on an SSL session, the MITM equipment must be placed within the network and requires configuring with information from the SSL server, the SSL client, or both. Although achieving this in a network that is not under one’s control is very difficult, it can be done within an enterprise network by the enterprise network manager.
To reduce the risks from increased use of SSL, an enterprise network can set up a transparent SSL proxy that will make un-encrypted versions of SSL flows available to the existing security appliances in the network. In reality, a transparent SSL proxy is just another term for an enterprise-controlled MITM attack.
For example, consider a network with an IPS deployed to prevent threats within incoming traffic reaching a server running HTTP. Upgrading the server to use HTTPS or to support both HTTP and HTTPS means that any threat within HTTPS traffic will not be detected and blocked and will reach the server. Deploying a transparent SSL proxy with the IPS attached to it will overcome the problem. Non-SSL traffic passes from the network to the SSL proxy, to the IPS, back from the IPS to the SSL proxy, then out to the network. The IPS can detect and block any threats in this non-SSL traffic. SSL traffic, on the other hand, is processed so that there is an SSL session from client to SSL proxy and from SSL proxy to server while the traffic to/from the IPS is un-encrypted.
Another example would be with a Data Loss Prevention (DLP) appliance that is responsible for preventing the leakage of sensitive data from the enterprise network. The DLP device may be inspecting outgoing Web-mail traffic to Gmail by monitoring the HTTP session from an enterprise client machine to the Gmail HTTP server. However, recently Gmail changed its default behavior to use HTTPS instead of HTTP; DLP device can no longer see what is being sent out of the enterprise over Web mail. Deploying a transparent SSL proxy that provides the DLP appliance with an unencrypted version of the Gmail session allows it to continue detecting and preventing sensitive data leaking from the enterprise. Only recently, SSL was used to successfully “leak” sensitive trading software from a US bank to a Web server in Germany.
Part 2 of this article will explain how transparent SSL proxies work and how they are typically used in enterprise networks to assist in providing protection from these “blind spots” in the security infrastructure.