How to render SSL Useless – video version

A while back I posted on the  How to render SSL Useless deck from Ivan Ristic of SSL Labs (now with Qualys) on common mistakes in the deployment of SSL. There is now a video of Ivan presenting this deck at a recent OWASP conference, available at ThreatPost.

Detecting SSL/TLS legacy session Renegotiation

Back in November I posted on The TLS Renegotiation Attack for the Impatient, which I hoped was a plain English explanation of this new weakness in SSL and TLS (at the end of the post you can find less plain explanations and links). The weakness was quickly addressed by the IETF a few months later. There is a new review of the attack from nCircle and also a link to the detailed steps that can be taken to specifically detect servers which still run legacy versions of the protocols susceptible to the attack.

Why use SSL?

Here is a short introductory post on the advantages of using SSL, and a nice FAQ as well. Cost and performance are listed as the main disadvantages. However you may want to also check out How to Render SSL Useless from Ivan Ristic and the additional comments here at Pat’s Daily Grind.

How to Render SSL Useless

This is the title of a recent talk from Ivan Ristic of SSL Labs on common mistakes in the deployment of SSL. This talk expands upon his SSL Threat Model that I posted about a few months ago. The main deployment mistakes Ristic sees for SSL are

• Self-signed certificates
• Own CA certificates
• Mixing SSL and plain-text
• Not using secure cookies
• Using incomplete certificates
• Not using EV certificate
• Not using SSL
• Mixed page content
• Different sites on 80 and 443
• Using SSL for “important”bits
• Inconsistent DNS configuration

This is a great presentation which really gets to the heart of why SSL security has lately been the focus of much attention.

(via SSL Shopper)

Plugging the Authentication Gap in SSL

The IETF has announced a draft document that specifies changes to the SSL protocol which closes the "authentication gap" exploited by the renegotiation attack announced last November. I posted a plain English explanation of the attack here, and you can find better graphical explanation here by Thierry Zoller (check for updates at his blog). The IETF and several vendors, including Google, Microsoft, and PhoneFactor, have been working on plugging this authentication gap since October. Until now, the best defence against the attack was to disable renegotiation in SSL.

The attack was initially dismissed as a quirk in the protocol - unexpected yet harmless - but it has ultimately resulted in several relatively small yet fundamental changes to SSL that introduce cryptographic state from one run of the handshake protocol to the next. The threat profile of the attack was raised when proof-of-concept code was written to demonstrate how the attack could be applied to steal Twitter passwords. PhoneFactor has described the attack as the most "severe" against the core SSL protocol to date.

The vulnerability that was uncovered is the observation that SSL does not distinguish between the initial protocol handshake of the client connecting to server, and any subsequent in-band handshakes for the renegotiation of cryptographic parameters. An attacker can establish an SSL session with a server and then later highjack an initial client SSL connection request to the same server, and splice the client request into the existing SSL session that the attacker has with the server. This is possible since the server interprets the client connection request as a renegotiation by the attacker. Any pending commands that the attacker has established with the server are then injected into the next client SSL-protected web session and executed in the context of the client (using the client cookies for example).

The solution proposed by the new IETF draft is for both client and server to cache the validation data that is currently computed and exchanged as the last step in the existing handshake protocol. A new protocol field has been introduced which indicates if the handshake is an initial or subsequent run (renegotiation), and in the latter case, the cached validation data is included in the renegotiation protocol. This prevents two independent sessions from being spliced together since the required validation data will either be absent or mismatched between the client and server.

It now remains to make any final tweaks to the protocol and to then deploy the revised protocol in existing SSL and TLS libraries, which is expected to be a slow and tedious undertaking. One of the authors of the new draft, Eric Rescorla, was a co-author in a recent study to examine the rate at which weak keys produced by a flaw in the random number generator of OpenSSL on Debian from 2008 were being patched. The study tracked a collection of approximately 50,000 public web servers over a period of 6 months. Initially around 1.5% of the servers (751 to be exact) were using Debian-flawed keys in their certificates, and 30% of the Debian-flawed certificates were still not re-issued after almost 180 days. Let’s hope for a better rate of patching in this case.

A Threat Model for SSL

I traced a link to my post How fast are Debian-flawed certificates being re-issued? to SSL Shopper, a new site for me, and I looked back through their news items and found a link to an SSL Threat model proposed by Ivan Ristić, the principle author of ModSecurity and a leader in Apache security.

Referring to the origins of his threat model, Ivan states that

SSL is easy to use but also very easy to use incorrectly. The ecosystem, which is built of the specifications, the implementations, the CAs and the PKI, is full of traps, each of which is very easy to fall into. Once I started to spend significant time thinking about SSL I set out to build a model of the ecosystem, for my own education and to ensure that I understand it all. That's how I arrived to the SSL Threat Model.

His threat model is represented as a FreeMind map, available as a graphic as shown below. The threat model considers clients, servers, PKI, protocols, users and attacks, and perhaps the model needs to be updated in light of the new The TLS Renegotiation Attack.

Ivan admits that the model needs some additional clarification, but it is probably more useful as a published draft rather than waiting for him to find the time to perfect the model (the same reasoning lead me to releasing my outline of a password book).

How fast are Debian-flawed certificates being re-issued?

In 2008 it was discovered that the OpenSSL package in Debian had been producing low entropy public keys for about a year and a half on its Etch distribution. While it was relatively easy to patch the offending code (only a few lines), it was going to be more difficult to track down and re-issue all the weak public keys that had found their way into SSL server certificates. From my post on the topic

An article in the Register, called Debian's Epic SSL Blunder, states that the number of SSL certificates that may need replacing could be in the hundreds of thousands or even millions. So while the OpenSSL PRNG code can be easily patched, identifying and replacing all the weak keys generated by the flawed code is a big operational headache. It may be months or years before all the weak keys and their corresponding certificates are tracked down and upgraded.

At the Internet Measurement Conference (IMC) held in early November, researchers Scott Yilek, Eric Rescorla, Hovav Shacham, Brandon Enright, and Stefan Savage presented a study on the rate at which Debian-flawed SSL server certificates were being replaced. In short, the news could have been better.

The researchers tracked a collection of approximately 50,000 public web servers over a period of 6 months. Initially around 1.5% of the servers (751 to be exact) were using Debian-flawed keys in their certificates, and the observed rate at which these certificate were being re-issued  is shown in the graph below

The researchers stress that as compared to typical patching rates for general vulnerabilities, re-issuing certificates for the sample of weak servers was very slow. A long term study by Qualys reported this year that the patching half-life for vulnerabilities is 30 days, and so over a 6 month period we should see an exponential decrease in unpatched endpoints. However the graph above is approximately linear, and 30% of the Debian-flawed certificates were still not re-issued after almost 180 days. The authors conclude that

… unlike other vulnerabilities which have been studied and typically show a short, fast, fixing phase followed by levelling off, certificates were replaced on a slower cycle with substantial fixing extending well past five months after the announcement. We also found that in some cases certificate authorities continued to issue certificates to weak keys long after the vulnerability was announced.

Incidentally the researchers also found that approximately 2% of the sampled servers (1000 or so) were still using 512-bit RSA keys. While such keys are not as weak as those produced by the Debian flaw, recovering the associated private keys was recently shown to require nothing more than a  3-day desktop calculation. Nonetheless, this fraction of 512-but keys is a dramatic improvement over the results of a  survey conducted in 2000 which found that almost a quarter of the 8,000 servers sampled were using 512-bit keys.

The TLS Renegotiation Attack for the Impatient

There are many posts and news articles of late on the TLS Renegotiation Attack. I had hoped that just by skimming a large number of these that some process of web osmosis would magically transfer an understanding of this vulnerability to me. But alas the topic has remained impenetrable and I had to dedicate some time to tracking down the details. By the end of this post you should have a better idea of what descriptions of the attack like this one actually mean

The vulnerability in the transport layer security protocol allows man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL session.

The TLS Handshake

TLS has a handshake protocol that performs authentication, negotiates cryptographic parameters and generates a session key, called a bulk encryption key in TLS-speak. The cryptographic parameters include a key exchange/establish method (usually RSA or Diffie-Hellman), the bulk encryption algorithm and a hash algorithm for MAC-ing session data. Collectively this information is called a cipher suite, and the set of acceptable cipher suites are pre-defined by TLS.

So the TLS handshake negotiates a cipher suite for the client and server, as well as a matching bulk encryption key. Any time during an active TLS session either the client or server may choose to renegotiate the cipher suite. One reason for doing this would be to refresh a bulk encryption key that had been used to encrypt a large amount of session data. Also, the client for example could decide to change from AES128 to AES256 for additional security.

The point is that in all three cases – negotiating a initial cipher suite, refreshing a session key or upgrading a key – the TLS handshake protocol is used, and therefore these operations are indistinguishable to TLS. This is the vulnerability that is exploited by the attack.

Splicing TLS Sessions

To explain the attack further, let’s assume that there is a client, server and an attacker (the usual suspects). The attacker establishes a normal TLS session with the server, which we will denote as TLS(A, S). Now let’s assume that the attacker is able to hijack sessions from the client, so that any TLS traffic from the client is routed through the attacker.

When the client attempts to create a TLS session with the server - call it TLS(C, S) - the handshake data is sent to the attacker. Now the attacker sends this client handshake data into TLS(A, S) which will be interpreted by the server as a renegotiation of TLS(A, S). Note that this is possible since the handshake for initial negotiation and renegotiation looks identical. When the server replies the attacker just relays the message to the client, and continues relaying messages between the client and server until the handshake is complete and the session TLS(C, S) is created. Traffic between the client server will now be encrypted and unreadable by the attacker.

The point here is that an attacker can splice a client request for a TLS session with the server into an existing TLS session with the server that the attacker has established.

Plaintext Injection Attack

Even though splicing TLS sessions together is an unintentional property of the TLS protocol, it is not malicious as we have described it. It may even seem charitable of the attacker to give up his TLS session with the server for the client.

However some mischief can be undertaken. TLS is typically used to provide security for an application layer protocol, most often the HTTP traffic of a web application. Now if a partial or incomplete web command is sent to a web server then it will cache that partial command until the remainder of the command is received, whereupon the now complete command will be executed.

Recall that the attacker has created a TLS session with the server, TLS(A, S), and the attacker can send a partial HTTP command to the web server, which it caches, pending further input. When the attacker splices the client-requested TLS session TLS(C, S) into TLS(A, S) then the first HTTP commands and data sent by the client will be added to the chosen HTTP command of the attacker that is pending in the web server cache, and then executed as a valid command.

This is being called a plaintext injection attack (PIA) – even though the attacker does not have access to the encrypted TLS traffic, he can inject a portion of a HHTP command into the decrypted traffic sent by the client. It is also being called a prefix attack since the attacker is manipulating the initial part of the HTTP command.

The point here is that the attacker can create a pending HTTP command within a web application, and then have the command completed and executed using HTTP commands sent by the client session that is spliced into the attacker's TLS session with the server.

What have we learned?

Let’s return to the short summary of the renegotiation attack given at the beginning of this post

The vulnerability in the transport layer security protocol allows man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL session.

The vulnerability being referred to is the inability of TLS to distinguish between initial and subsequent runs of the handshake protocol. This allows an attacker to splice together a TLS session of their own creation with a newly requested session by an unsuspecting client. The attacker can introduce (command) text at the beginning of the client’s web session since he can arrange for a partial command to be pending in the cache of the web server.

This may all seem a bit theoretical, but the Register recently reported a practical implementation of this attack by Turkish grad student Anil Kurmus to “steal Twitter login credentials that passed through encrypted data streams”.

The simple and immediate workaround for TLS is to disable session renegotiation, with the long term solution being to explicitly distinguish between the first and subsequent runs of the TLS handshake protocol. Eric Rescorla has a detailed post on the renegotiation attack, including both long and short term solutions.