Beat the BEAST with TLS 1.1/1.2 and More

Juliano Rizzo and Thai Duong presented a new attack on Transport Layer Security (TLS) at the Ekoparty security conference in Buenos Aires, Argentina. This presentation has received a lot of media attention and also has caused a lot of confusion, especially since all the details were unknown. The researchers named their proof-of-concept tool “Browser Exploit Against SSL/TLS” (BEAST) and are suggesting that it can decrypt secure cookies in minutes. The protocol deficiency they are highlighting is a problem that is due to the way that block ciphers are used in SSL/TLS.

There are several ways that block ciphers generally operate (i.e., how encrypted blocks are manipulated to ensure complete confidentiality).  Cipher Block Chaining (CBC mode), is used in SSL for all block ciphers, including AES and Triple-DES (3DES). The BEAST attack relies on a weakness in the way CBC mode is used in SSL/TLS.  In addition to CBC mode there are other non-CBC cipher suites, such as those using the RC4 stream encryption algorithm, that are not vulnerable to the BEAST.  Additionally, TLS versions 1.1 (RFC 4346) and 1.2 (RFC 5246) are not affected by this issue. In TLS version 1.1 the implicit Initialization Vector (IV) was replaced with an explicit IV. Also, Datagram Transport Layer Security (DTLS) protocol versions 1.0 and 1.2 are not affected (DTLS is defined in RFC 4347).

Note: Nickm from the Tor Project does a good job introducing the basics on his blog for people who don’t know all the technical details about the TLS protocols and CBC.

Another thing to highlight is that OpenSSL implemented a feature where they send an “empty TLS record” immediately before they send a message. This empty TLS record causes a change in the CBC state where people consider it to give the message “a new IV” that the attacker can’t predict.  This feature in OpenSSL is disabled with the “SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS” option and it’s also included in the “SSL_OP_ALL” option.  In OpenSSL versions 0.9.6d and later, the protocol-level mitigation is enabled by default, thus making it not vulnerable to the BEAST attack.

For applications that use OpenSSL, this “empty-record” trick can be enabled as a workaround. For a more permanent solution, the adoption of TLS 1.1/1.2 is what’s needed.  Unfortunately, even though TLS 1.1 has been out since 2006 it isn’t widely implemented or deployed. TLS versions 1.1 and 1.2 are now supported in OpenSSL version 1.0.1-stable, which you can get from the “snapshot” section of the OpenSSL website. Once OpenSSL 1.0.1 is “officially out,” it is expected that many people will be migrating to it. The main challenge is compatibility with some browsers. Microsoft Internet Explorer 9 and Opera web browsers support TLS 1.1 and 1.2.  Safari, Chrome and Mozilla Firefox do not support TLS 1.1 and 1.2. Chrome has a fix for this issue and Safari/Chrome teams are already working on one, as well.

In summary, this attack is not the end of the world. However, it certainly highlights the importance of migrating to TLS 1.1/1.2. The following are a few interesting blog posts and articles that also talk about the attack and mitigations/workarounds:

• Slaying BEAST: Mitigating the latest SSL/TLS Vulnerability

• Tor and the BEAST SSL attack

• BEAST Hack Threatens Security of Webmail, Online Shopping