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.com. BOB will first create
a public key PubKB and private key PriKB for BOB.com,
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 BOB.com 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 BOB.com. The BOB.com 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 BOB.com.
If Alice trusts the
certification of PubKX2, then she can choose an SSL Cipher to use
from the list of encryption methods provided by BOB.com,[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 BOB.com server. [3]
Eventually the KA
is shared by Alice and the BOB.com server, which means that Alice can
communicate with BOB.com 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.
[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 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
Host: BOB.com:5983
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 (http://attacker.com) 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 https://Bob.com,
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.
References
1. Sarkar P.G., Fitzgerald S.: ATTACKS ON SSL. https://www.isecpartners.com (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