Two researchers recently discovered a known vulnerability that existed in CBC based ciphers, but was considered theoretically impractical, until then. This vulnerability exists in all CBC based ciphers used in SSL V3/TLS 1.0. The researchers Juliano Rizzo and Thai Duong demonstrated proof-of-concept code called BEAST (Browser Exploit Against SSL/TLS) at the Ekoparty security conference held in late September, 2011.
If you don’t remember, these 2 are the same guys who last year discovered the “Padding Oracle” crypto attack in ASP.NET.
I will try to be as explanatory as possible. One of the researchers (Thai Duong) has published this on his blog here: http://vnhacker.blogspot.com/2011/09/beast.html. This blog contains a video link demonstrating the attack.
After this Microsoft released a Security Advisory article and a HOTFIX addressing the vulnerability on 26th September 2011. http://technet.microsoft.com/en-us/security/advisory/2588513 http://support.microsoft.com/kb/2588513
Now, before we proceed ahead, we need to understand few semantics of SSL in order to understand this vulnerability. As I aforementioned, this vulnerability exists in all CBC based ciphers used in SSL V3/TLS 1.0.
I also want to mention that I referred few things from internet, mostly from Wikipedia, and what I remember from my college days. I am glad I was one of the few that opted for Cryptography as one of the topics back in my engineering days.
SSL Protocol: These are the following list of protocols which have been released till date:
NOTE: Windows Server 2008 R2 and Windows 7 are the only 2 OS which support TLS 1.1 and TLS 1.2 as of now. All the OS’s before this don’t support these 2 protocols.
Please refer the following blog post by me on support for SSL/TLS protocols on Windows. http://blogs.msdn.com/b/kaushal/archive/2011/10/02/10218922.aspx
CIPHERS: Ciphers are cryptographic algorithms used for performing encryption/decryption. A “Plain text” is fed as input to CIPHERS to generate an encrypted text also known as “Cipher text”. There are 2 kinds of Ciphers generally used during SSL handshake:
CBC (Cipher-block chaining): It is a symmetric key algorithm, used for encryption/decryption. It is also referred as a block cipher. It firsts partitions the input message into separate cipher blocks of equal length. The nth or the last block sometimes may have to be padded to match the cipher’s block length. Now these blocks are encrypted one at a time.
In CBC, the plain text is XOR’d with the Initialization vector (IV) in the first block and with the cipher texts of the previous blocks before undergoing encryption. The IV is generally sued to make each message unique. Here is where the problem arises. I will explain this in the later section.
The below images below explain the encryption/decryption. The images from articles on Wikipedia helped me draw out these images in a colorful way, however they lacked continuity. So I used few dotted lines to indicate continuation of cipher operations.
The dotted lines below indicate continuity from 1st and second blocks to the nth block and vice-versa.
Encryption in CBC Mode Courtesy: http://en.wikipedia.org/wiki/File:Cbc_encryption.png
Decryption in CBC Mode Courtesy: http://en.wikipedia.org/wiki/File:Cbc_decryption.png
SSL Handshake: SSL handshake is too big of a topic to be discussed here. Anyways we don’t need to discuss the complete handshake, What we need to know is, the 2 communicating entities, client and the server, decide on a common SSL/TLS protocol and cipher (Block Ciphers or Stream Ciphers) that they will be used to perform the encryption/decryption. The public key cryptography is used to decide these and during the latter part of the handshake, they decide on symmetric keys and perform encryption/decryption using the generated symmetric key and the ciphers decided earlier.
I invested some time and chalked out the image below. This explains the SSL handshake between client and server. This in reference to the Microsoft KB article 257951 on SSL handshake.
Chosen Plain-text recovery attack:
One of the methods used by the attackers, in order to gain access to the secret key being used by the communicating entities involved in a SSL handshake. In this method, the attacker choses arbitrary plain-texts and obtains corresponding cipher texts. The attacker makes predictive guesses depending upon the obtained cipher text, to form the original plain text.
This sounds unrealistic, as the attacker has to make predictions in order to crack it. However, modern day cryptography has become lot more easier as there are powerful hardware and software, capable of performing millions of calculations per second.
BEAST: Discussing the vulnerability
Remember the use of implicit IV’s while XOR’ing the plain text for successive blocks after the first block. This was a problem. The thing is that IV’s are supposed to be unique. Since the cipher text of the previous block is used as an IV in the current block mode of operation, the uniqueness is actually lost, and as I know that my previous cipher text is the IV for the current block.
Server Side Fix:
Warning: Web clients that don’t support TLS 1.1 or 1.2 will perform the SSL negotiation with lower SSL/TLS versions, voiding the workaround. So better implement both the workarounds on IIS 7.5.
The above KB article adds the following registry key when run on server side:
NOTE: Unfortunately the above solution doesn’t apply to Windows Server 2003/Windows XP, the cipher suites prority is hard coded. On Windows Server 2003, they will probably have to disable the CBC based ciphers; however this might cause incompatibility with clients trying to connect to these servers.
Browser Side Fix:
Among browsers as of now only 2 of them include support for TLS 1.1 and TLS 1.2
IE, like IIS relies on SCHANNEL for encryption or decryption, hence it supports only those protocols that are supported by the underlying OS. However, this is not true for non-Microsoft products; they have their own implementation and include support for these protocols specifically.
Recommended reading on this:
The irony is that major internet browsers (Chrome, Firefox and Safari) still don’t provide support for TLS 1.1 and TLS 1.2. They continue to use a security protocols which is a decade old. Its been 5 years since TLS 1.1 was released, yet this hasn’t been implemented by them.
Even OpenSSL doesn’t include support for TLS 1.1/TLS 1.2, so as a result, even Apache doesn’t support these protocols. Hopefully, they would realize the importance of security and adopt these new IETF standards.
Its time that we move on and adapt the new security protocols. I guess the time has arrived.