BEAST attack on SSL/TLS

Analysis of BEAST attack on SSL/TLS

Isaac D. Mao

1               What is SSL/TLS

1.1           SSL/TLS in Internet Protocol Suite

SSL/TLS are protocols used to provide communication security (i.e. authentication and data encryption) over the Internet. In the Internet protocol suite[1], SSL/TLS are implemented on top of the Transport Layer protocols (e.g. TCP) by encapsulating some Application Layer protocols (e.g. HTTP, SMTP and FTP).

1.2           History

SSL (Secure Sockets Layer) was introduced by Netscape with the highest version as SSLv3 and then evolved into TLS (Transport Layer Security) v1.0, v1.1 and v1.2. There is also a draft TLS v1.3. In general, the higher the version of TLS, the more secure the protocol could be. As we will see later, a well-configured TLSv1.1/v1.2 can prevent the BEAST attack that can break web sites running on SSLv3/TLSv1.  

1.3           Scenario of Using SSL/TLS

Suppose a company BOB wants to secure communications to their web server BOB will first create a public key PubKB and private key PriKB for, which is also known as “SSL Certificate”. BOB will then submit application to a reputable third party Certificate Authority (CA, e.g. GeoTrust) for verification of BOB’s identity and the right to use domain. Once the verification is done, the CA will issue BOB a certification with an updated public key PubKB2. The certification is encrypted using the CA’s private key PriKCA.

Suppose Alice wants to make a secure connection to The server will send back its CA-issued certification of PubKB2 to Alice. Alice will use the CA’s well-known public key PubKCA to decrypt the certification and validate whether the PubKX2 can be trusted for accessing

If Alice trusts the certification of PubKX2, then she can choose an SSL Cipher to use from the list of encryption methods provided by,[2]  and generate a confidential symmetric key KA that will be used for the SSL Cipher. Alice will then encrypt KA using PubKB2 and send it back to the server. [3]

Eventually the KA is shared by Alice and the server, which means that Alice can communicate with by encrypting all data using the KA and the chosen SSL Cipher. 

1.4          Potential issues of SSL/TLS

There are basically two possible threats on SSL/TLS.[4]  

·     Ciphers: SSL/TLS uses one of many possible encryption algorithms to perform the symmetric encryption. Thus, a cipher could be compromised in some circumstances. As we will see later, BEAST attack makes use of AES and other conditions.
·     Trust: If BOB company simply have their keys approved by themselves; or another bogus company got a BOB certification from a careless third party, then SSL/TLS cannot assure the secure communication with the intended company.

2               BEAST Attack

2.1            Vulnerability of CBC Mode to BEAST Attack

BEAST (Browser Exploit Against SSL/TLS) Attack makes use of a chosen-plaintext attack by which the attacker could play a game to see if the encryption of the plaintext guess matches the known cipher-text.

To defeat a chosen-plaintext attack, SSL/TLS usually uses initialization vector (IV) and cipher block chaining mode (CBC). Because IVs are random and should be different for any two plaintexts encrypted with the same key, therefore, multiple encryptions of the same plaintext don’t result in the same ciphertext.

[2]  (Complete Cipher Suites used by SSL/TLS)
[3]    For the sake of clarity, we simplify the key exchange process here. In fact, client must first securely transmit a Pre-Master Secret to the server, and then both client and server hash the Pre-Master Secret with respective random values to create a shared Master Secret. The Master Secret is used to create four keys that are shared by the client and server.


SSL/TLS is a channel encryption protocol used for encrypting a series of packets in each direction. SSLv3/TSLv1 treats all the packets as a single large object and just continues CBC state between packets.  Therefore, the IV for packet N is the last block (the CBC residue) for packet N-1.

Since an IV already used is not a secret and is sent in the clear, suppose the attacker Mallory wants to guess that secret x might be mi, she can inject a constructed next plaintext block mj to the encryption oracle and get cj as:
         cj = Ek [c(j-1)  (mj) ] = Ek [c(j-1)  ( mi  c(i-1)  c(j-1) )] = Ek [mi  c(i-1) ] = ci           (1)
if cj = ci  then the guess of secret x is correct.

2.2           How BEAST Attack Be Practical

When Alice signs in her account on a secure website (e.g. Google Storage), once she is authenticated, her browser should receive a session cookie with an encapsulated token. [5]  The server will use the session cookie to authenticate Alice on every request. Fig. 1 shows a typical authentication process about accessing Google Cloud Storage.

Fig. 1. Authentication Process for Accessing Google Storage (Source: Google.[6])

Whoever gets the session cookie can then get access to Alice’s account. The session cookie will be active until the client leave the site and close the browser.

The attacker Mallory who can see encrypted messages sent by Alice will know the session cookie’s location and then the IV used for the session cookie. In addition, Mallory also knows the IV’ that will be used at the beginning of the next message packet, which is actually the last ciphertext block from the current message packet. In BEAST attack, Mallory will try to choose a plaintext message sent on behalf of Alice, and then guess on the session cookie to see if the ciphertext matches.

[5]    There is also a Token-Based Authentication that relies on a signed token corresponding to accessing a specific resource. Such token is sent to the server on each request. However, for BEAST attack, such token still could be guessed out.


The question then becomes the following three requirements for a successful attack:
 1.  The attacker can capture encrypted HTTPS requests sent by the client. A network sniffer will be working.
 2.  The attacker can control where the cookie is in the message by adjusting the boundaries of the encryption blocks.
 3.  The attacker can inject chosen plaintext blocks and then use the client browser as an encryption oracle. In addition, the multiple injections must be done in the same living SSL/TLS session.
Doung and Rizzo demonstrated a live BEAST attack against Paypal in 2011.[7] They attack SSL in client-side browsers. The BEAST consists of a network sniffer and JavaScript/applet agents. When client loads an agent, BEAST will decrypt all the client-side cookies byte by byte until getting the session identifier cookies. Then they can access Paypal with the decrypted session cookie value.

If Mallory has to guess whole blocks, then this attack is not very practical because the attacker would have to guess on the order of the block size of the cipher algorithm (e.g. 2128 for AES). However, if Mallory can control the block boundaries to guess the secret just one byte at a time, then it could be practical.

For  example, in a HTTP request sniffed:

POST /login HTTP/1.1
Cookie: a=cm9vdDo1MEJDMDQxRDpqb-Ta9QfP9hpdPjHLxNTKg_Hf9w

In above code, the value of cookie a is in ciphertext, Mallory wants to guess the plaintext of cookie (e,g, _Session_Token:Edx29PabwebM9s). She can adjust the string into two parts “_Session_Token:?”, and “dx29PabwebM9s”, and then guess out the first character (at the position of ‘?’) of the cookie plaintext as ‘E’. Once she knows the first character, she can shift the boundary by one byte and then guess the next character, and so on.

Mallory stands up a malicious website ( and induces Alice to visit it through advertising or another attack. The malicious site contains a script that can force Alice’s browser to initiate a HTTPS connection (normally, POST requests) to, if allowed. Once she has captured the encrypted block with the cookie, she can try to guess the session cookie byte by byte and see if the resulting ciphertext matches the previously recorded session cookie ciphertext.



3               Counter Measures

3.1           Client-Side Mitigations

BEAST attack targets the vulnerability in SSLv3/TSLv1 and earlier version. The attack was mitigated in TLS v1.1. However, for client compatibility reason, most severs still require support for SSLv3/TSLv1. Therefore, client-side mitigations are recommended as below:
·     Ensure the browser is of the latest version that has implemented a workaround to address the vulnerability to BEAST attack.  (e.g. Firefox 10+, Chrome 16+)
·     Enable TLS v1.1 and v1.2.
·     Migrate the SSL/TLS VPN to TLS v1.2, so that the attacker can hardly mix the traffic with the client’s traffic.

3.2           Other Considerations

For the server side, disable cross-origin requests when they are not needed. We should also encourage clients to support TLS v1.2.

BEAST attack shows that vulnerabilities considered to be theoretical still can be dangerous if attackers put effort in the implementation. A systematic approach is always needed to evaluate and ensure the information security. 


   1.    Sarkar P.G., Fitzgerald S.: ATTACKS ON SSL. (2013)
   2.    Ristic I.: SSL/TLS Deployment Best Practices. Qualys SSL Labs (2013)
   3.    Meyer C., Schwenk J.: Lessons Learned From Previous SSL/TLS Attacks, IACR Cryptology (2013)

No comments:

Post a Comment