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 Post summaries the credible information available.
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
TOC
- Introduction to BEAST, TLS and CBC
- Relevant Papers
- Proposed countermeasures
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 ?
- 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 on why TLS 1.1 was not introduced sooner in the NSS stack (Currently used by Chrome, Firefox and various servers) :
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.
Proposed Countermeasures
Generic Server Recommendations :
- Short-Term : Prioritize the RC4 Algorithm over CBC based ciphers (AES, DES). See the recommendations by PhoneFactor .
- Short to 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
In the works :
- 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. (Empty Application Data Records) - it is currently pushes to Chromium Beta channels for testing
- Various vendor discuss countermeasures in this Bugzilla entry
Literature
Advisories