Really Understanding the SSL/TLS Vulnerability (Part 1)

This is a two part blog post. In the first part I will try to explain the vulnerability so we can get a better handle on it, and in the second part we'll examine possible countermeasures and mitigation strategies.

There was some big news in the security world on November 4, 2009 when Marsh Ray released details about a newly published SSL/TLS vulnerability. Of course, selling security is all about creating Fear, Uncertainty and Doubt (FUD) and as such a number of websites and blogs also picked up the story. Most notably:

The real question is whether you should be worried or not. I think that in order to answer this question we need to really dig into the details of how the attack works and then analyze the risk and potential mitigation factors from there. This particular attack is called a chosen plaintext attack. A successful attack will allow the attacker to do two things:

(1)   Execute a chosen HTTP transaction on the server. This could be any HTTP request that eventually does something important on the server side. For instance, a bank account transfer comes to mind as well as single message transactions such data insertion, but it could be any server-side action triggered by a specifically chosen HTTP request.

(2)   Gain information regarding the shared symmetric key used in an SSL session. (for a limited time). If the attacker knows a specific HTTP transaction produces a given plaintext, or plaintext sequence, he or she might be able to choose which plaintext blocks to encrypt and obtain the matching results. This may yield some information about the key. In this case, the attacker might accumulate many examples of the plaintext and matching cipher-text. As we will see, a sophisticated
attacker acting as a man-in-the-middle (MITM) will be able to inject plaintext and then have access to the corresponding ciphertext, and if he or she knows any information about the generated response, there may be a stretch of time (before the next renegotiation) where a chosen-plaintext attack is feasible.

In order to understand how this man in the middle attack (MITM) works, we have to first understand what happens inside an SSL handshake. SSL works in two broad phases: First, the handshake phase, and second, the application data phase. The handshake phase is where the shared, symmetric key is computed which is subsequently used in the application data phase of the protocol to encrypt application data traffic. The goal of SSL is to provide secure socket communication between two endpoints. In this respect, SSL is really a layer 4 protocol as it is communicating over standard sockets. I think we take SSL for granted due to its ubiquity, but the handshake is actually performing a cryptographic feat:  a shared symmetric key is securely generated between two parties that have never met before.

The protocol itself requires no initial shared secret information, only a set of trusted certificate-authority (CA) certificates on the client side (at a minimum). We also take these for granted because the certificate-authority vendors have placed "trusted" CA certificates in our browsers. As an exercise you can check your browser to see who you implicitly trust. In Firexfox 3.5.x this is under Tools > Options > Advanced > Encryption tab > View Certificates. In the latest Firefox I count 70 CA certificates (roughly).  Moreover, the protocol supports client authentication as well, which requires CA certificates be provisioned on the server similar to what we see in the browser.

Certificates are important in two respects for SSL. First and foremost they contain the public key used by the client to encrypt the pre-master secret during the handshake, and second, they are used to validate one or both sides of the communication using X.509 certificate path validation. Certificate path validation is the process of validating the trust on a certificate by checking that you trust the issuer of the certificate. This is done by looking at the issuer's issuer and so on, up the chain until you reach an implicitly trust CA certificate, called a root CA.

The limitation that Marsh Ray uncovered has to do with renegotiation of the shared secret, which I will call the renegotiation gap. SSL allows for either side to renegotiate the master secret at any time by sending an appropriate message, either from the client or server. Renegotiation can be done for any number of reasons – to refresh the shared secret, to change the cipher, or to change the mode of the protocol to a different form. It can also be done for no good specific reason, simply by having the client send a new client hello. Usually, however, renegotiation is a move from one-way SSL (server authentication) to two-way SSL (client authentication).The first thing we will do in order to understand the renegotiation gap is dig into the handshake.

The SSL Handshake

To see the problem, you have to put yourself in the mind of the attacker and treat the handshake like an information game with state changes along the way. The goal of the game depends on the mode of the protocol, and for SSL this will either be a shared secret with server-side authentication, or a shared secret with both client and server authentication. In the case of server side authentication, the end goal is to generate a shared secret key where the client knows the identity of the server based on the limitations of PKI technology (certificate validation). In the case of client authentication, the goal of the game is to generate a shared secret where both sides know the identity of each other, again based on the limitations of PKI technology. Once you understand the additional information state at each stage of the handshake, it becomes trivial to see how a man-in-the-middle attack can work, and further, how the renegotiation gap changes the rules of the game.

First, let's lay out the handshake in 13 possible steps as follows. The table below is meant to be read from left to right and the ">" arrow denotes a message flowing from the client to the server. Similarly, the "<" indicator denotes a message from the server to the client. Once the handshake is finished, the game is over with one of two "normal" outcomes: (1) A shared secret was generated and the server was authenticated or (2) The shared secret was generated and both sides were authenticated. A critical point here is that a man in the middle of the SSL handshake changes the rules of the game and the information state.

In the table below note that "*" is used to denote optional messages in the SSL handshake, used in the case of client authentication. This implies that the shortest possible handshake (for server side authentication) is an exchange of 8 messages and the full handshake is 12 messages. It should be noted for completeness that the Server Key Exchange is only used when the certificate doesn't contain a public key, such as in the case of DSA. Also, for completeness, there is a mode for SSL called "anonymous Diffie-Hellman" which requires neither side authenticate, but we won't cover it since it is infrequently used.

Handshake Phase

 Step

Client Message

Server Message

Information State

1

Client Hello >

  

 The first handshake message that contains the protocol version, random bytes, a session ID (or null), supported cipher-suites, and optional supported compression methods

2

  

< Server Hello

 The second message contains a selected cipher-suite, the highest mode of SSL supported by the server, session ID and compression methods

3

  

< Server Certificate

 ASN.1 encoded certificate or certificate chain goes back to the client.

4

  

< Server Key Exchange*

 (Skipped for this discussion but included for completeness)

5

  

< Certificate Request*

 Contains acceptable certificate types and list of acceptable CAs

6

  

< Server Hello Done

 Indicates the server is finished with its side of the handshake

7

Client Certificate* >

  

 The client sends its certificate or certificate chain

8

Client Key Exchange >

  

 The pre-master secret is encrypted for the server using the public key in the server's certificate

9

Certificate Verify* >

  

 Client-generated signature over the master  previous handshake messages

10

Change Cipher Spec >

  

 Signal message with version and a single byte

11

Finished >

  

 Two hashes of the handshake messages, master secret, identifier and padding

12

  

< Change Cipher Spec

 Signal message with a version and a single byte

13

  

< Finished

 Two hashes of the handshake messages, master secret, identifier and padding

  
 

  • Step 1: There is no significant shared information state yet. The client has asked to start a new SSL session with some basic parameters. One important point here is that if the client wishes to resume a session, it must include the session ID.
  • Step 2: There is still no significant shared state – the server responds with a chosen cipher-suite, but the client still has not authenticated the server
  • Step 3: The server sends its certificate or certificate chain to the client. It might be tempting to think that at this point the client can authenticate the server, but this is simply not the case. The reason why is because certificates are public by design, so thinking like an attacker here means that the server could (at this point) have any X.509 certificate. The only thing that guarantees authentication in the PKI model is the existence of the private key, which the server doesn't actually prove until it sends its finished message in step 13. In other words, the client can perform certificate path validation on this certificate and achieve a valid result, but has no guarantee that the server owns the private key corresponding to this certificate. One possible (non-cryptographic) way of adding some measure of authentication here is to verify the hostname against any hostname declared in the certificate's common name, but this is a de-facto practice and not part of the actual protocol specification. It also doesn't work if the man in the middle is actively installed below layer 4 in the network infrastructure.
  • Step 4: We will skip for our purposes here as it pertains to certificates that do not contain a usable public key
  • Step 5: The server optionally requests the client's certificate. This message contains the acceptable certificate types and Certificate Authority Certificates (CAs), which are trusted, root certificates.
  • Step 6: The server indicates that it is finished with its side of the handshake. Even if the client verifies the server's certificate, it still does not have any guarantee that the server is who it says it is.
  • Step 7: Even if we assume the client has sent its certificate, from an information state point of view, the server has no guarantee yet that the client is authenticated, even by validating the certificate. The reason is the same as in step 3 or 6 for the server; the client has not yet demonstrated proof of possession of the private key that matches the certificate.
  • Step 8: The client generates a 48-byte pre-master secret.  This value is encrypted using the server's public key and sent to the server.  The pre-master secret is a two byte client protocol version and 46 bytes of random data.  The client version helps prevent version roll-back attacks. It should be emphasized that until the server proves it can decrypt the secret there is no evidence that the server is authenticated. So even after step 8, the server has proven nothing to the client from a cryptographic standpoint.
  • Step 9: The client finally generates proof of possession of the private key. It does this by digitally signing a hash of previous handshake messages. This further implies that in terms of the information game, in the case of two-way SSL, the server is the first to know the true identity of the client.
  • Steps 10 and 11: The change cipher spec message is sent as a signal that we are about to begin the application data phase. Immediately following this the client sends its finished message, which contains two hashes (MD5 and SHA-1) of the master secret, handshake messages, string identifier and padding. From an information state perspective, the server is still not authenticated.
  • Steps 11 and 12: The server is finally forced to prove that it can decrypt the encrypted secret sent in step 8. Here the server must be able to compute a signature over the secret and the client must verify that this is the case.

With this background, we can now insert the attacker into the flow to see how the attack works. It is easy to think of SSL as an "encrypted" channel safe from an intruder, but if there is a man in the middle actively intercepting packets from the inception of the protocol, he or she can exploit the renegotiation gap.

 The Man-in-the Middle is actively waiting between the client and server under the following preconditions:

  • The MITM is waiting from the inception of the handshake phase and assumes that the SSL protocol begins with server-side only authentication
  • The MITM waits for a client hello that he or she knows will trigger server-side authentication
  • The MITM goes through the full handshake with the server and because the server is not authenticating the client, the server does not know it is talking to a man-in-the-middle
  • Eventually, some trigger occurs that causes the server to ask for a client certificate. I will call this the renegotiation trigger message (RTM). This trigger can be a renegotiation of the SSL handshake, triggered by either the client or the server, for any reason. I received a blog comment regarding this point (thanks Steve) and one point made here is that the renegotiation may be triggered simply by sending a new client hello at any time. This is a critical point - the SSL specification allows for a client hello to be sent at any time and doing so will trigger negotiation. This means that the RTM can just be a client hello with no change to the cipher-suite or strenght of the SSL/TLS session
  • The MITM is not passing through each message as they flow, but collecting and saving up the messages he or she wants

 
Let's look at how the man in the middle can intercept messages during the handshake. In the following table I've highlighted certain portions of the handshake important to making the attack to work.

 Handshake Phase with Man-In-The-Middle (MITM)

 Step

Client Message

Man in the Middle

Server Message

Information State

1

Client Hello >

Client Hello >

  

The server receives a client hello as normal; the MITM caches the initial client hello and starts a new session with the server, sending a new client hello

2

  

MITM caches the server hello without passing it on.

< Server Hello

 The server responds with a server hello. The client is still waiting for this message

3

  

 MITM caches the server certificate.

< Server Certificate

 The client is still waiting for a server certificate

4

  

  

< Server Key Exchange *

 (Skipped) – Does not affect this case

5

  

  

< Certificate Request *

 (Skipped) – The MITM must start with a handshake that does not trigger a certificate request

6

  

  

< Server Hello Done

 Server sends the server hello done.

7

  

Client Certificate* >

  

(Skipped) – The MITM has chosen a handshake with no client certificate request

8

  

Client Key Exchange >

  

The pre-master secret is encrypted for the server using the public key in the server's certificate

9

  

Certificate Verify* >

  

(Skipped) – The MITM has chosen a handshake with no client certificate request

10

  

Change Cipher Spec >

  

Signal message with version and a single byte

11

  

Finished >

  

Two hashes of the handshake messages, master secret, identifier and padding (MITM)

12

  

  

< Change Cipher Spec

Signal message with version and a single byte

13

  

  

< Finished

Two hashes of the handshake messages, master secret, identifier and padding (Server)

14

  

Renegotiation Trigger Message (RTM)  > (This can be as simple as a new client hello)

  

  

15

  

  

< Hello Request

The server sends a hello request based on the trigger message (RTM), which starts a new handshake

17

  

Replayed Client Hello from Step 1 >

  

  

18

  

< Server Hello

< Server Hello

The server responds with a certificate. This matches the response the client expects after Step 1.

19

  

< Server Certificate

< Server Certificate

The server responds with its certificate which is passed on by the MITM

20

  

< Certificate Request

< Certificate Request

The server requests the client certificate – the RTM in this case triggers a stronger form of SSL

21

  

< Server Hello Done

< Server Hello Done

Server sends the server hello done which is passed through to the client

23

Client Certificate >

 Client Certificate >

  

 The client sends its certificate

24

Client Key Exchange >

 Client Key Exchange >

  

MITM passes along the client key exchange containing encrypted the shared secret

25

Certificate Verify >

 Certificate Verify >

  

MITM passes along the client's proof of possession message

26

Change Cipher Spec >

 Change Cipher Spec >

  

 Signal message with version and a single byte

27

Finished >

 Finished >

  

 MITM passes along the finished message from the client

28

  

 < Change Cipher Spec

< Change Cipher Spec

 Signal message with version and a single byte

29

  

 < Finished

< Finished

 MITM passes along the finished message from the server

30



< HTTP Response

< HTTP Response

The server retroactively applies the authentication to the message sent in step 14, allowing the transaction through

The MITM – Handshake Explanation

The Man-in-the-Middle (MITM) is present from the inception of the first client hello and acts in such a way as to make both the client and server believe the handshake is legitimate, while at the same time executing a chosen plaintext attack. I have highlighted the important parts of the attack in the previous table.

  • Step 1: The client sends its initial client hello and all it eventually sees is a server hello in step 18. The MITM works the attack between Step 1 and Step 18, acting as if he is the client.
  • Step 14: This is where the MITM must choose an appropriate renegotiation trigger message (RTM). This message must be a legitimate HTTP request that triggers the server side to start a new SSL session. Two ways of doing this are to choose an HTTP request that triggers either a stronger cipher-suite or a client certificate. In the example here, we assume the RTM triggers a renegotiation for a client certificate. In practice this would be done using an HTTP request to a "protected" or "higher security' URL location on the server. It should be noted that the attack can also be made to work if the client triggers a renegotiation, though this isn't shown here.
  • Step 18: Once the server hello is passed back to the client, the attack is nearly complete. From here on out the server will look to the authenticity of the true client, with the MITM as a silent go-between. The server will retroactively allow the message in Step 14 based on the future authentication state from the true client. It is this specific behavior that results in the compromise.
  • Steps 23-25: The client sends its valid certificate along with the encrypted master secret and proof of possession of the private key. It should be noted that the MITM cannot snoop on the communication at this point, but will have access to the encrypted response and knows at least part of the matching plaintext, which was part of the message in step 14. This is the second weakness that may result in information that allows the MITM to derive the key, but this is still quite difficult.
  • Step 30: This is the confirmation of the content of the renegotiation trigger message (RTM) in step 14. The MITM has successfully executed a one-way HTTP transaction using the authenticity of the client. I say this is one-way because they cannot read the actual response.

 Another way of seeing how the attack can work is consider the behavior from the client

  • Client's Perspective: The client starts an SSL session by making an HTTP request to a web server and is prompted for a client certificate. The client presents their certificate. They notice that the first HTTP response (web server communication) they get back doesn't match their initial request. They shrug it off and send the request again, this time getting a valid result. They may also be surprised to find that they are asked for a client certificate when in the past they weren't, but it doesn't matter as the client would just assume security policies have increased on the server side. The client may notice the handshake took a little longer.
  • Server's Perspective: The server receives a request for a new SSL session from a particular client IP address. The server processes the handshake normally, authenticating itself. The client subsequently asks for a URL that is protected with a higher level of security. The server caches the HTTP request for this protected URL and renegotiates the SSL session with the client, this time asking for the client to authenticate itself. The client authenticates itself and the server sends the resulting URL location (or response) back to the client.

Conclusion

As you can see, there is very little to indicate a compromise on either the client or server side. The key weakness is the SSL renegotiation, which can be triggered by the client or server. Worse, renegotiation is valid at any point during the protocol communication and may be done simply for the purposes of refreshing the key. In principle the weakness can be exploited anywhere the renegotiation occurs assuming the MITM is watching for this state from the inception of the handshake. In the next blog post we will look at the current and proposed mitigation strategies for this attack.

 

Posted by Blake Dournaee on 11:43 AM

8 comments:

Steve said...

Nice write-up. A couple of points of clarification, though.

First off, there is no need to use client certificates, or even to "trigger" the server into renegotiating. The mitm can simply forward on the original client hello, and any vulnerable server will start renegotiating. The stuff about needing an upgrade in cipher suite or a client cert is true, as far as it goes, but client-initiated renegotiation is possible without any of that. I think you basically said this in the middle, but I wanted to punch it up for clarity, since it greatly influences the severity of the flaw.

Secondly, the description is slightly off on one point. The MITM caches the client's original Client Hello packet and initiates his own SSL session with the server using a brand new CH packet. Only once he's ready to hook the original client up to the connection (after having injected his plaintext) does he then forward on the cached CH packet.

One other very minor point- don't forget that a new symmetric key is negotiated once renegotiation is triggered, so the chosen plaintext attack trying to derive the symmetric key won't do you any good (or perhaps I misunderstood what you wrote).

Looking forward to part 2!

-Steve

Blake Dournaee said...

Thank you very much for taking the time to read through the write-up. I was stunned when I read about the vulnerability and felt I needed to describe it more fully.

I changed my original blog post to reflect 2 of your 3 comments. I checked the SSL specification and you are indeed correct - renegotiation can happen for no good reason - e.g. simply by resending the client hello. This makes the problem just a little worse in my view (Section 7.4.1.2. Client hello from RFC 2246).

On your second point, I corrected the description of the behavior of the MITM with respect to its client hello, which would be a new client hello rather than forwarding the original client hello.

Finally, for the last point, let me see if I can explain my rationale on the chosen plain-text attack.

Let's agree on the following:

1. The MITM does NOT have access to the symmetric key used to encrypt a corresponding response to his injected plain-text in step 14.

2. The MITM has some corresponding cipher-text to some easily guessable plain-text, triggered by the message sent in step 14. That is, he doesn't have the directly corresponding plain-text in step 14, but has access to to the response triggered by this chosen plain-text. In this sense, it is a once-removed chosen-plain-text attack.

In the best case the attacker could have chosen an HTTP request that generates a known response. Here, something like an "echo" service comes to mind. The attacker will be able to generate a plain-text/cipher-text pair.
In the worst case, he or she would know part of the plain-text as the response would likely be HTTP 200 OK, for instance. The MITM receives this cipher-text in step 30.

3. The cipher-text in step 30 is the cipher-text encrypted with the just negotiated key. So, in theory (until the next renegotiation), the MITM has a greater chance (but certainly not a perfect chance) of gaining some key information. This information may be increased if the attacker knows any information about the response encrypted in step 30. In other words, a sophisticated attacker could use this vulnerability not to inject code to cause havoc, but to aid in breaking the key used in a renegotiated session. I think this is a low-risk vulnerability compared to the renegotiation gap, but I still think it needs to be highlighted.

I am basing this reasoning on the "paranoia" model for protocol security - if there is a weak link we can assume the attacker will find it.

Any further comments are welcome!

Anonymous said...

I think it is unlikely that this vulnerability was announced on November 4, 2010 unless you have some kind of time machine. :-)

Blake Dournaee said...

Thanks anonymous - I fixed the typo :)

オテモヤン said...
This comment has been removed by a blog administrator.
niz said...

Hello .. firstly I would like to send greetings to all readers. After this, I recognize the content so interesting about this article. For me personally I liked all the information. I would like to know of cases like this more often. In my personal experience I might mention a book called Generic Viagra in this book that I mentioned have very interesting topics, and also you have much to do with the main theme of this article.

buy viagra cheap said...

I am thoroughly convinced in this said post. I am currently searching for ways in which I could enhance my knowledge in this said topic you have posted here. It does help me a lot knowing that you have shared this information here freely. I love the way the people here interact and shared their opinions too. I would love to track your future posts pertaining to the said topic we are able to read.

transgender dating site said...

I discovered your web site via Google while looking for a related subject, lucky for me your web site came up, its a great website. I have bookmarked it in my Google bookmarks. You really are a phenomenal person with a brilliant mind!

Followers

About Me

My Photo
I have been working in the XML/SOA and security space for about 10 years. I currently work at Intel Corporation in their software group. I wrote the first book on XML Security and am a co-author of SOA Demystified from Intel Press. My interests are an eclectic mix of computing, security, business, technology and philosophy