Views
4 years ago

Cracking SSL/TLS Using BEAST ISA 564 Aaron Doty (adoty@gmu ...

Cracking SSL/TLS Using BEAST ISA 564 Aaron Doty (adoty@gmu ...

Introduction Secure

Introduction Secure Socket Layer (SSL) 3.0 and Transport Layer Security (TLS) 1.0 are very similar protocols developed to secure network communications. SSL/TLS uses cryptography to encrypt/decrypt the Session Layer of the OSI network stack, and were designed to provide confidentiality and integrity to otherwise insecure application protocols. For example, HTTP in and of itself sends all messages between a client and server in the clear, and no encryption is utilized at any communication layer so an attacker could sniff or manipulate the exchanged data. HTTPS, on the other hand, uses the same Application Layer messages as HTTP, but utilizes SSL/TLS to encrypt client/server communication at the transport layer with a shared secret key and prevents an eavesdropping attacker. SSL 3.0 was a complete redesign of a flawed SSL 2.0 implementation, and was released in 1996 by Paul Kocher and his Netscape engineering team [1]. TLS 1.0 was later released in 1999, through RFC 2246, and its security is based on the SSL 3.0 cryptographic implementation. TLS consists of two layered protocols that provide a secure client/server communication session: 1) TLS Handshake Protocol – provides a method for client/server authentication, encryption algorithm negotiation, and cryptographic key exchange; and 2) TLS Record Protocol – provides symmetric cryptography of exchanged data (e.g. AES, DES, RC4, etc.) and data integrity checking using a hash algorithm (e.g. MD5, SHA, etc.) with a keyed MAC[2]. Each of these protocols is implemented using similar methodologies within SSL 3.0. This purpose of this project is to thoroughly investigate the concepts behind the recent research into “cracking” SSL 3.0/TLS 1.0. The problem lies within the way Cipher Block Chaining (CBC) mode is implemented in SSL/TLS for block ciphers (namely AES and DES), which will be discussed in some detail within this paper. This exploit was accompanied by an application called BEAST, which utilizes this exploit to expose HTTPS headers and secure session cookies, and was developed by Juliano Rizzo and Thai Duong and released at the Ekoparty Security Conference in Buenos Aires in September 2011. SSL/TLS CBC Implementation and History Behind Attack The SSL/TLS standard states that all block chaining within block encryption ciphers is performed using CBC mode[2]. In CBC mode, an IV is XOR'ed with the first plaintext block, P 1 , which is then encrypted using a block cipher encryption algorithm to produce a ciphertext, C 1 , for that block. C 1 is used as the IV for the next plaintext block, P 2 , which is also encrypted to produce C 2 . Essentially, C n-1 is always the IV for P n , creating a chaining effect. Decryption is the reverse of encryption in that each block of ciphertext, C N , is decrypted and XOR'ed with the previous block of cipher text C n-1 to produce the plaintext P n . Encryption and decryption are depicted in Figure 1[3]:

Figure 1 – CBC Encryption and Decryption Methods Standard implementations of CBC involve selecting a fresh IV for each block of an encrypted method. However, SSL/TLS's standard involves selecting the initial IV in a psuedo-random manner, then utilize the last ciphertext block of the previous message to serve as the new IV for the next message. Within SSL, it is worth noting that each plaintext/ciphertext block is 2 14 bytes in length. In 2004, Dai pointed out a vulnerability within SSH v2 in which the predictability of an IV could lead to a chosen-plaintext attack in [3]. SSH v2’s implementation of CBC is similar to SSL 3.0/TLS 1.0 in that the ciphertext block from the previous message is always used as the IV for the next message. Dai describes the simplicity of this attack as: Suppose the attacker suspects that plaintext block P_i might be x, and wants to test whether that's the case, he would choose the next plaintext block P_j to be x XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j XOR C_(j-1)) = Encrypt(P_i XOR C_(i- 1)) = C_i, and so he can confirm his guess by looking at whether C_j = C_i. Also in 2004, G. Bard detailed how the predictability of the IV within SSL could potentially lead to Dai's chosen-plaintext attack within SSL in [3], using a browser plug-in or Trojan Horse. The steps involved in such an attack were summarized as follows: 1. An attacker should learn and identify the plaintext format of the information that they wish to capture (e.g. HTTP header information, HTML fields, Javascript code implemented, etc.). 2. An attacker could develop a browser plug-in or trojan horse to inject chosen-plaintext into the SSL session. 3. An attacker could provide the target's network traffic to the plug-in using TCPdump, or something similar, so that the plug-in has access to previously sent and received ciphertext. 4. The plug-in needs to ensure that it times its chosen-plaintext injection so that the information is buffered into the first block of a new message (so that the IV is known). Application layer blocks are inserted into a buffer and separated into 2 14 byte-sized blocks by SSL. There are idle periods in message exchanges, such as when a user is reading a loaded webpage, when this plug-in could inject the chosen-plaintext to receive the desired results. The potential for this attack was closed by IETF and the TLS working group in 2006 with the introduction of TLS 1.1 in RFC 4346, which uses explicit IVs for each new message [4]. However, since