Lots of good information floating on the internet on the Proof of Concept (dubbed 'BEAST) against TLS 1.0 by Juliano Rizzo and Thai Duong at the Ekoparty.
This blog post will be continuously updated as new items and possible mitigation emerge.
Subscribe to the RSS feed in case you are interested in updates.
Updates
Subscribe to the RSS feed in case you are interested in updates.
Updates
- 27.09.2011: Added Thai blog post and POC Video
- 27.09.2011: Added CVE-2011-3389 , Bugzilla entry , Microsoft Advisory 2588513
- 27.09.2011: Added BID, Secunia and Opera Advisory
- 28.09.2011: Added Whitepaper and Proof of concept code
- 28.09.2011: Added a Rant by Adrian Dimcev
- 29.09.2011: Added Microsoft Blog Post "Is SSL broken? – More about Security Advisory 2588513"
- Introduction to BEAST, TLS and CBC
- Proposed countermeasures
- Literature
- Advisories
Introduction to BEAST, TLS and CBC
Juliano and Thai presented a Proof of Concept of an attack against TLS 1.0 is first documented in 2001 and discussed in papers in 2005 and 2006. It was thought to be an impractical attack back then and solved by adding empty fragments into the IV.
- This issue was addressed in TLS 1.1 (2005-6) and OpenSSL by inserting Empty Fragments into the message.
So why is this still and issue today ?
- First and foremost, TLS 1.1 is not supported by many SSL stacks, server or client side. Although the protocol exists there was no real incentives to move over to TLS 1.1 (or 1.2). Attacks were documented, some countermeasures implemented in some SSL stacks, but deemed impractical and forgotten.
- Secondly the OpenSSL option "SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS" is activated by default as it caused incompatibilities with certain SSL stacks. Activating here means removing the mitigation against this attack. It is known that Tomcat, Apache mod_ssl, and Exim disable this feature in OpenSSL by default. Note : The proposed NSS patch (see countermeasures) adds empty application data records, which appears to be more compatible.
To quote Nelson Bolyard on why TLS 1.1 was not introduced sooner in the NSS stack (Currently used by Chrome, Firefox and various servers) :
"There is no significant market demand for TLS 1.1, so we've been working on improvements in other areas,such as sharable DBs and full RFC 3280 compliance. Once TLS 1.2 finally becomes an RFC, we will work on that some time thereafter. We believe there will be a demand for TLS 1.2 and some of the new cipher suites that require TLS 1.2 as a prerequisite." Source
Source: TLS/SSL Compatibility Report 2011 |
What is TLS ? What is CBC ?
Putting it in layman terms, TLS is the new name for SSL. SSL was developed by Netscape and was renamed and reworked into TLS when handed over to the IETF.
More details are available on Wikipedia - The post by the TOR team does an excellent job of explaining TLS, CBC and the attack itself, I highly recommend reading it especially if you are interested in the details, followed by "Security impact of the Rizzo/Duong CBC BEAST attack"
How does the Attack work ?
The attack has the CVE number CVE-2011-3389 - Thai himself explains the attack and how it was discovered in his blog post "Beast"
Proposed Countermeasures
Generic Server Recommendations :
- Short-Term : Prioritize the RC4 Algorithm over CBC based ciphers (AES, DES). See the recommendations by PhoneFactor . (Note: Please take my recommendation and use this as a short term solution only, RC4 is not the strongest solution but the only non CBC cipher...)
- Mid-Term : Enable and Offer TLS1.1 or TLS1.2 (Note: Firefox and chrome do not support TLS 1.1 and will fallback). For a compatibility overview look here
- The publication by Juliano and Thai should create the necessary incentive for Vendors to implement and use TLS1.1 and/or TLS 1.2. I will keep an eye on the usual suspects and collect all relevant support in the "TLS/SSL compatibility Report"
- The Phone Factor (the guys behind the TLS session renegotiation vulnerability) propose prioritizing RC4 over AES or DES as a short term mitigation.
- The chrome team has created patches to NSS fixing the issue client-side. (Splits non-empty Application Data Records, image below) - it is currently pushed to Chromium Beta channels for testing
2 separate Application Data Records - Image courtesy of Adrian Dimcev |
- Various vendor discuss countermeasures in this Bugzilla entry
- The BEAST Paper by Julian and Thai
- Thais' blog post with a full recap
- A Rant by Adrian Dimcev
- CBC Attacks first documented in 2001 and discussed in papers in 2005 and 2006
- Security impact of the Rizzo/Duong CBC "BEAST" attack
- Recap by the TOR Team
- Recommendations by the PhoneFactor
- Microsoft Blog Post "Is SSL broken? – More about Security Advisory 2588513"
- Chrome Team has an summary of their countermeasure