Ok, surely not the freshest topic out there as we are looking at going back to the end of 2011 but the BEAST issue does, however, remain valid today as several (slightly worried) customers of ours have made queries to us about it over the last few months. These customers aim to gain a better understanding of what kind of “animal” we're actually dealing with and whether their apps may be presently running a concrete risk of compromise through such an attack.


The fact that there is still no official stance from the Council on this topic so far only increases the concern. The lack of a stance is reasonable, however, since when dealing with technical specifications the PCI SSC simply redirects you to industry standards and similar resources such as NIST’s special publications. Apparently, NIST has not yet updated the specific SP 800-52, dated June 2005, focused on TLS (“Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations”).

Moreover, Qualys (as well as many other ASVs), though labeling the issue - tagged CVE-2011-3389 - under the naming "SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Vulnerability" and giving it a CVSS score greater than 4.0, have not yet included it in the list of PCI-affecting items. This brought us to thinking that it could be worth posting some lines on this matter in the hope that it helps clarify the nature of the issue somewhat, especially when it comes down to deciding whether to address it or not.

The story basically begins some months ago (more or less 10 months), with a couple of researchers discovering a potential vulnerability in TLS v1.0 and SSL v3.0 - the decade-old cryptographic standard that protects web addresses using the https prefix.

Apparently, the vulnerability may allow attackers to silently decrypt data that’s passing between a web server and an end-user browser. This vulnerability can be exploited using a cookie-based technique called “BEAST” (acronym for “Browser Exploit Against SSL/TLS”) that leverages block-oriented cipher implementations such as AES and TripleDES. It turns out that by tampering with an encryption algorithm's CBC (cipher block chaining) mode, hackers could secretly decrypt portions of the encrypted traffic. Qualys even outlines how "for low entropy data it is possible to guess the plain-text block with relatively few number of attempts. For example, for data that has 1000 possibilities the number of attempts can be 500".

As a general clarification on the nature of the issue it might be worth mentioning that SSL/TLS, as a channel encryption protocol, is utilized to encrypt not just a single file but a series of records as part of a data flow. For instance, a single SSL/TLS connection can be used for a series of HTTP requests, each of which is split into one or more records sent over the course of seconds to minutes. All the records (in each direction) are encrypted with the same traffic key.

Normally we have two basic ways to use CBC in this kind of environment

  1. Treat each record as if it were independent; generate a new IV (initialization vector) and encrypt the record as described above.
  2. Treat the records as if they were concatenated into a single large object and just continue the CBC state between records, meaning that the IV for record “n” is the last block (the CBC residue) for record “n-1”.

SSLv3 and TLS 1.0 rely on the second option. This turned out to be an issue and thus, the starting point to devise the BEAST attack which is illustrated by the author himself at the following link: http://vnhacker.blogspot.com/2011/09/beast.html

Apparently, in order to inherently address the issue, recent upgrades of TLS to version 1.1 and 1.2 switched it to the first approach. However, such versions have compatibility issues since not all modern browsers effectively support them. 

In terms of the attack's complexity, - apparently significant but not necessarily applicable to any application context - further requirements for successful exploitation include the need to have a target domain which allows cross-origin requests that:

  • Contain some user secret (e.g. a cookie) in a predictable location.
  • Allow scripts from the attacker's origin to tightly control additional data on the same HTTPS connection as the user secret. Basically, this is done by deploying an ad-hoc Java/Javascript vector in order to establish a kind of MiTM (Man-In-The-Middle) condition. 

It is important to point out that no exploit or proof-of-concept has been made publicly available to date, so any testing activities may be focused solely on the analysis of the cipher suites being negotiated upon putting up the secure channel with the customer's server end. The aim would be to detect the presence of possible ciphers, based on CBC encryption algorithm, which could lead to security exposures related to the matter in question.

In case one wanted to carry out a quick check on his own, without necessarily having to run a full-blown vulnerability scan, a relatively straightforward bespoke script based on command-line OpenSSL can be helpful. The script, reported hereafter for the sake of clarity, acts as an SSL client that iterates several handshakes with the server on the basis of the available ciphers. This is done in order to determine which cipher suites are accepted at the server side.


ciphers=`openssl ciphers 'ALL:eNULL' | sed -e 's/:/ /g'`

echo Obtaining cipher list from `openssl version`.

for cipher in ${ciphers[@]}
echo -n Testing $cipher…
result=`echo -n | openssl s_client -host $SERVER -port $PORT -cipher "$cipher" 2>&1`
if [[ "$result" =~ "Cipher is " ]] ; then
echo YES
if [[ "$result" =~ ":error:" ]] ; then
error=`echo -n $result | cut -d':' -f6`
echo NO \($error\)
echo $result
sleep $DELAY

Here is a sample output from the script:

tester@checkbox$ ./ssltest.sh
Obtaining cipher list from OpenSSL 1.0.1c 10 May 2012.
Testing ADH-SEED-SHA…NO (sslv3 alert handshake failure)
Testing DHE-RSA-SEED-SHA…NO (sslv3 alert handshake failure)
Testing DHE-DSS-SEED-SHA…NO (sslv3 alert handshake failure)
Testing SEED-SHA…NO (sslv3 alert handshake failure)
Testing ADH-AES256-SHA…NO (sslv3 alert handshake failure)
Testing DHE-RSA-AES256-SHA…NO (sslv3 alert handshake failure)
Testing DHE-DSS-AES256-SHA…NO (sslv3 alert handshake failure)
Testing AES256-SHA…NO (sslv3 alert handshake failure)
Testing ADH-AES128-SHA…NO (sslv3 alert handshake failure)
Testing DHE-RSA-AES128-SHA…NO (sslv3 alert handshake failure)
Testing DHE-DSS-AES128-SHA…NO (sslv3 alert handshake failure)
Testing AES128-SHA…NO (sslv3 alert handshake failure)
Testing ADH-DES-CBC3-SHA…NO (sslv3 alert handshake failure)
Testing ADH-DES-CBC-SHA…NO (sslv3 alert handshake failure)
Testing EXP-ADH-DES-CBC-SHA…NO (sslv3 alert handshake failure)
Testing ADH-RC4-MD5…NO (sslv3 alert handshake failure)
Testing EXP-ADH-RC4-MD5…NO (sslv3 alert handshake failure)
Testing EDH-RSA-DES-CBC3-SHA…NO (sslv3 alert handshake failure)
Testing EDH-RSA-DES-CBC-SHA…NO (sslv3 alert handshake failure)
Testing EXP-EDH-RSA-DES-CBC-SHA…NO (sslv3 alert handshake failure)
Testing EDH-DSS-DES-CBC3-SHA…NO (sslv3 alert handshake failure)
Testing EDH-DSS-DES-CBC-SHA…NO (sslv3 alert handshake failure)
Testing EXP-EDH-DSS-DES-CBC-SHA…NO (sslv3 alert handshake failure)
Testing DES-CBC-SHA…NO (sslv3 alert handshake failure)
Testing EXP-DES-CBC-SHA…NO (sslv3 alert handshake failure)
Testing EXP-RC2-CBC-MD5…NO (sslv3 alert handshake failure)
Testing RC4-SHA…YES
Testing RC4-MD5…YES
Testing EXP-RC4-MD5…NO (sslv3 alert handshake failure)
Testing DES-CBC3-MD5…NO (sslv3 alert handshake failure)
Testing DES-CBC-MD5…NO (sslv3 alert handshake failure)
Testing EXP-RC2-CBC-MD5…NO (sslv3 alert handshake failure)
Testing RC2-CBC-MD5…NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5…NO (sslv3 alert handshake failure)
Testing NULL-SHA…NO (sslv3 alert handshake failure)
Testing NULL-MD5…NO (sslv3 alert handshake failure)

This outcome basically says that sample host secure.example.com negotiates the following cipher suite:

• RC4-MD5

While the first two suites are based on stream ciphers, and hence not affected by the vulnerability, the last one represents a typical CBC encrypting algorithm that falls, instead, within the vulnerable range. Through a simple connection to the SSL server-side end, it is finally possible to verify which preferred ciphers, from the list above, is actually being negotiated. The following command can be then run:

tester@checkbox$ openssl s_client -host secure.example.com -port 443

At the bottom of the generated output, something similar to the following should appear:

No client certificate CA names sent
SSL handshake has read 4537 bytes and written 440 bytes
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 7E5DE278F2B99AB4B03BD4D7B60070EA0AA075A7FC725F437A68816283A67870
Master-Key: A2707AE91D01AE9FD37462AC2C881D2E02457ADBAE788CFA46B1DC6181D07992F4F3B748F55A07BAF78B91C915F22F76
Key-Arg : None
Start Time: 1320761437
Timeout : 300 (sec)
Verify return code: 0 (ok)

In the above example, there would be no risks since the default algorithm is based on a stream cipher. This, of course, is not the only way to carry out the check above. There are plenty of good online tools that can help to do this. One that is quite handy being, for instance:


When the Beast firstly came out, TLS v.1.0 and SSL v.3.0 were still considered compliant protocols. Thing have changed nowadays so we suggest you to learn more about this topic and stay up to date because the threat landscape is continuously evolving.

If someone wanted to implement a practical countermeasure to protect himself with the aim of improving overall security posture and further mitigate any residual risks, the following should be enough: disable any CBC-based cipher suites leaving only stream cipher-based encryption support enabled. Any other long-term countermeasure would inevitably involve enabling TLS v1.1 and TLS v1.2 support.

A good trade-off that would address both security and compatibility issues could be to put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients (which are not vulnerable) followed by RC4 for TLS 1.0 clients.

Update: When the Beast firstly came out, TLS v.1.0 and SSL v.3.0 were still considered compliant protocols. Things have changed nowadays so we suggest you to learn more about this topic and stay up to date because the threat landscape is continuously evolving.

Marco Borza

Written by Marco Borza

I am the Founder of Advantio.
Technology has been my passion since I was a kid; when I first heard the handshake of an old 300bps modem I realised security would be key in an interconnected world. Since then it has become my passion and primary focus.
The reason why I've started my own business is to make IT Security simple.

Certifications: CISSP / CCSA (Checkpoint) / ITIL Foundations / ACSA (ArcSight)/ Linux+/ PCI-QSA / PA-QSA