Vulnerability Note VU#864643

SSL 3.0 and TLS 1.0 allow chosen plaintext attack in CBC modes

Original Release date: 27 Sep 2011 | Last revised: 08 Dec 2011


A vulnerability in the specification of the SSL 3.0 and TLS 1.0 protocols could allow an attacker to decrypt encrypted traffic.


The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are commonly used to provide authentication, encryption, integrity, and non-repudiation services to network application protocols such as HTTP, IMAP, POP3, LDAP, SMTP, and others. Several different versions of the SSL and TLS protocols have been standardized and are in widespread use. These protocols support the use of both block-based and stream-based ciphers.

A vulnerability in the way the SSL 3.0 and TLS 1.0 protocols select the initialization vector (IV) when operating in cipher-block chaining (CBC) modes allows an attacker to perform a chosen-plaintext attack on encrypted traffic. This vulnerability has been addressed in the specification for the TLS 1.1 and TLS 1.2 protocols.

While this vulnerability exists in the underlying specification of the affected protocols, a practical attack called BEAST has been demonstrated in the context of a web browser and the use of the HTTPS protocol. Because of the software functionality available to an attacker in this environment, it represents the most likely attack vector and the most significant risk for affected users. An effective BEAST attack appears to require a cross-domain vulnerability that allows the attacker to issue specially crafted HTTPS requests. A blog post by Thái Duong discusses "...a way to bypass the same-origin policy (SOP)..." using a Java applet.


An attacker with the ability to pose as a man-in-the-middle and to generate specially-crafted plaintext input could decrypt the contents of an SSL- or TLS-encrypted session. This could allow the attacker to recover potentially sensitive information (e.g., HTTP authentication cookies).


We are currently unaware of a practical solution to this problem.


Some vendors have published specific mitigation advice for the attacks related to this issues. Please see the Vendor Information section of this document for more information.

The following general workarounds can be effective in mitigating this issue:

  • Prioritize the use of the RC4 algorithm over block ciphers in server software
    Note that this workaround is not feasible to implement on systems that require FIPS-140 compliance since RC4 is not a FIPS-approved cryptographic algorithm.
  • Enable support for TLS 1.1 and/or TLS 1.2 in the web browser
  • Enable support for TLS 1.1 in server software
    Note that both the web servers and the client web browser must support TLS 1.1 or TLS 1.2 for these workarounds to be effective. The session will fallback to an earlier version of the TLS or SSL protocol in the event that either is incompatible with TLS 1.1 or TLS 1.2.

Vendor Information (Learn More)

VendorStatusDate NotifiedDate Updated
GoogleAffected-27 Sep 2011
Microsoft CorporationAffected-27 Sep 2011
MozillaAffected-28 Sep 2011
OperaAffected-08 Dec 2011
Apple Inc.Unknown-27 Sep 2011
GnuTLSUnknown-27 Sep 2011
OpenSSLUnknown-27 Sep 2011
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A



Thanks to Thái Duong working with Matasano and Juliano Rizzo of Netifera for reporting the practical attack against this vulnerability. Wei Dai and Bodo Möller identified the underlying flaw in the context of SSL and TLS.

This document was written by Chad R Dougherty.

Other Information

  • CVE IDs: CVE-2011-3389
  • Date Public: 08 Feb 2002
  • Date First Published: 27 Sep 2011
  • Date Last Updated: 08 Dec 2011
  • Severity Metric: 3.37
  • Document Revision: 36


If you have feedback, comments, or additional information about this vulnerability, please send us email.