SSL Protocol Vulnerability

November 9, 2009

One hundred and fifty years ago to the month, Charles Darwin dropped a bombshell on the world when he published his theory of evolution by natural selection in the book "On the Origin of Species". He had been building evidence to support his hypothesis for over twenty years. But the previous summer he had received a letter from his colleague Alfred Russell Wallace in which it became clear that he (Wallace) was developing an evolutionary theory that closely resembled Darwin's.

This week, security researchers released a bombshell of more modest proportions. But one that, nevertheless, has significant implications for the security of information networks, including the World-Wide-Web. They had been working in a small group of experts to understand the implications of their discovery and plan a remediation strategy, with a publication date in early 2010 in mind, when (independently) another researcher stumbled upon the same vulnerability and described it on an IETF mailing list. The first group thought it advisable to go public with their findings immediately in order to ensure that product developers and system architects had access to the best information available to help them develop defenses, but before they had agreed how best to mitigate the vulnerability.

The problem that has been identified is in the SSL (or TLS) protocol, which is a protocol commonly used to protect communications between computers, including communications between browsers and Web servers. TLS is the IETF's version of SSL. The problem lies deep in the protocol specification itself; not with specific products or systems. Hence, a patch from any particular vendor is not the answer. Rather, the protocol designers (members of the TLS working group of the IETF) have to update the specification, vendors will then have to patch their products and system administrators will have to deploy those patches. It will take several years before the problem is completely eradicated.

The TLS working group has started work on a revision to the protocol specification; a fix has been proposed and agreement amongst the TLS experts is likely to occur in the next few weeks. Perhaps, the trickiest part of the solution is going to be deciding upon suitable rules to allow for interoperability between patched and unpatched implementations during the transition period, without making things worse than they already are.

The flaw arises from the way that TLS end-points negotiate a common cipher suite. As well as allowing the cipher suite to be negotiated at the beginning of a session, it allows renegotiation dynamically, at the instigation of either the client or the server, part way through a session. The problem is that the procedures for negotiation and renegotiation are indistinguishable. So, one party (e.g. the victim client) may believe it is involved in an initial negotiation, while the other party (e.g. the server) may believe it is involved in a renegotiation. This can occur when a Man-In-The-Middle establishes an unauthenticated session with a server and then proxies another authenticated session between the client victim and the same server. In this situation it is possible for the MITM to trigger a renegotiation and for the last message received from the MITM by the server prior to the renegotiation to be attached to the first message received from the victim client after the renegotiation. Depending upon the design of the Web application, this vulnerability may be exploitable by the Man-In-The-Middle to execute a transaction that will be attributed to the victim client.

In order to succeed, an attacker must first establish itself as a Man-In-The-Middle. While tools may soon become available to help "script-kiddies" mount an attack, those attacks will still have to be adapted to the specific design of the application hosted by the vulnerable server.

Clearly, this is a situation that cannot be allowed to persist. And, over time, all uses of TLS will have to be repaired. However, there are many situations that are not vulnerable to this flaw. And for those that are vulnerable, it may be possible to reconfigure the server to disallow renegotiation.

Entrust's SSL/TLS certificates are not affected in any way by this disclosure. However, several of Entrust's software products are affected. Entrust will implement the revised protocol as soon as it stabilizes and work with its customers to ensure that systems are updated in a timely fashion. We will also monitor events and update our guidance as new information comes to light. In the meantime, users are encouraged to review the available materials on the topic and understand its applicability to their own implementations of TLS and the remediation options available to them.

Resources

• Understanding the TLS Renegotiation Attack

• How does SSL work?
• What is EV?
• SSL Certificates Types