Protect your server against TLS renegotiation and man-in-the-middle vulnerabilities.

Introduction

A flaw in the design of the TLS v. 1/SSL v. 3 (TLS/SSL) handshake process was discovered in 2009, and RFC 5746 (Feb. 2010) was released to update the protocol specification. Since then, most system manufacturers have released patches to fix this flaw. Still, as of June 2011 approximately half of the systems using TLS/SSL on the Internet have not implemented the patches needed to close this security hole. This vulnerability affects the secure transport of HTTP, IMAP, SMTP, and other protocols that rely on TLS/SSL. Industry representatives and security researchers who have looked into the problem note that sites with the TLS patch may still be vulnerable to this attack, known as the TLS renegotiation Man-In-The-Middle attack (TLS Renego MITM). DigiCert is taking a proactive approach to this problem by contacting its customers to advise them of this potential vulnerability in their systems. At some point in the future, connectivity problems may occur because of server non-compliance with RFC 5746.

In other words, when RFC 5746 is fully deployed browser clients will refuse to connect to unpatched servers.

Background

TLS/SSL allows both servers and clients to initiate a refresh or complete renegotiation of the encryption parameters used for TLS/SSL connections. This ability gives the communicating parties an abbreviated process to resume a previously existing TLS/SSL session, often with a more secure set of cryptographic parameters. However, the design of the initial handshake and the renegotiation process had a gap that could allow a third party to send a “client hello” and splice content into a client’s TLS/SSL session and then intercept TLS/SSL communications between the server and the client.

Just to provide you with a brief overview, the typical TLS/SSL handshake process involves the following:

client hello (highest TLS/SSL version supported, random number, suggested ciphers, suggested compression methods and, if the client is attempting renegotiation, previous session ID)
server hello (TLS/SSL version, random number, cipher suite and compression chosen and, if server is attempting renegotiation, previous session ID)
server sends TLS/SSL certificate
server hello done

client key exchange (preMasterSecret exchange and MasterSecret calculation)
client change cipher spec
client finished (hash and MAC of previous handshake messages)

server change cipher spec
server finished

GET /secure HTTP/1.1\r\n...

(For more information, see Wikipedia's article on TLS handshakes).

Using the TLS Renego MITM vulnerability, an attacker can either form a TLS connection to the server first, before the client (for example, on a compromised machine in response to the client’s attempt at connection) or can use session renegotiation to effectuate the attack. Even mutual certificate-based client authentication connections are vulnerable to the TLS Renego MITM attack. More details on how various attack scenarios play out are provided in RFC 5746 and related discussions provided here and here.

Solution

The TLS/SSL specification in RFC 5746 applies to both full handshakes and session resumption handshakes. Because pre-existing TLS/SSL specifications required systems to ignore a ClientHello extension if they did not understand it, RFC 5746 specifies that the ClientHello either contain an empty “renegotiation_info" extension or a Signaling Cipher Suite Value (SCSV) as a pseudo cipher suite with the same semantics as an empty "renegotiation_info" extension. When a client receives the ServerHello, it must check to see if the server supports the "renegotiation_info" extension. Assuming that secure renegotiation is supported per RFC 5746, then for TLS renegotiation, the client can send the "renegotiation_info" extension. If the server does not respond in accordance with RFC 5746, the client MUST abort the renegotiation handshake. Similarly, if a client does not respond in accordance with RFC 5746, then the server MUST abort the renegotiation handshake.

For backward compatibility, a compliant client will be configurable for either allowing insecure renegotiation or aborting an attempt to renegotiate. However, because some TLS servers do not support renegotiation at all there will be a transition period where problems will be encountered. From a server side, if the server does not receive the "renegotiation_info" extension or the SCSV, then RFC 5746 specifies that the “secure_renegotiation” flag be set to FALSE. Thereafter, if a ClientHello for renegotiation contains an empty “renegotiation_info" extension or the SCSV, then the server MUST abort the handshake.

Product Information

Further Steps to Take for Secure TLS/SSL Communication

Finally, in addition to the fixes described above for the TLS Renego MITM attack, DigiCert recommends that server administrators disable SSL version 2 and disallow the use of weak cipher suites. SSL version 2 provides no protection for the session negotiation handshake at the beginning of, nor at the end of the connection. This means that a MITM attack can happen at any point during the communication (e.g. the MITM simply creates a false termination message, splices into the SSL session, and deceives the parties into thinking their communication is still secure). Allowing weak ciphers also creates a problem. A weak cipher is one with less than 128 bits of encryption (i.e. a string of 1 and 0s shorter than 128). For example, the international versions of IE 3 and Netscape used to provide only 40 bits of encryption. Today, the minimum standard of 128 bits offers 88 additional bits of key length, which means that there are 2^88 more possible combinations one would have to try in order to crack strong encryption. Because support for SSL 2.0 and weak 40-bit and 56-bit ciphers has been removed completely from several current browsers, such server configurations should no longer be necessary.

Return to Main News Page