Google preps Chrome fix to slay SSL-attacking BEAST
20-line patch targets plaintext recovery exploit
Google has prepared an update for its Chrome browser that protects users against an attack that decrypts data sent between browsers and many websites protected by the secure sockets layer protocol.
The fix, which has already been added to the latest developer version of Chrome, is designed to thwart attacks from BEAST, proof-of-concept code that its creators say exploits a serious weakness in the SSL protocol that millions of websites use to encrypt sensitive data. Researchers Juliano Rizzo and Thai Duong said they've been working with browser makers on a fix since May, and public discussions on the Chromium.org website show Chrome developers proposing changes as early as late June.
It's hard to know how effective BEAST will be at quickly and secretly cracking the encryption protecting online bank passwords, social security numbers and other sensitive data, but Google appears to be taking no chances. Rizzo and Duong have released only limited details of their attack ahead of a presentation scheduled for Friday at the Ekoparty security conference in Buenos Aires.
Until recently, many cryptographers speculated it refined attacks described in 2004 and later in 2006 (PDF) by researcher Gregory Bard. In a series of recent tweets, Duong discounted these theories, saying he and Rizzo read Bard's paper weeks after the genesis of BEAST. Instead, he said it was based on work by cryptographer Wei Dai.
Short for Browser Exploit Against SSL/TLS, BEAST performs what's known as a chosen plaintext-recovery attack against AES encryption in earlier versions of SSL and its successor TLS, or transport layer security. The technique exploits an encryption mode known as cipher block chaining, in which data from a previously encrypted block of data is used to encode the next block.
It has long been known that attackers can manipulate the process to make educated guesses about the contents of the plaintext blocks. If the attacker's guess is correct, the block cipher will receive the same input for a new block as for an old block, producing an identical ciphertext.
The change introduced into Chrome would counteract these attacks by splitting a message into fragments to reduce the attacker's control over the plaintext about to be encrypted. By adding unexpected randomness to the process, the new behavior in Chrome is intended to throw BEAST off the scent of the decryption process by feeding it confusing information.
The approach is similar to one introduced in 2002 by developers of the OpenSSL package that many websites use to implement SSL. That change added empty plaintext fragments to the the cipher block chain before sending the actual payload. The technique was effective in preventing the cracking of SSL-protected data sent from the server to browsers, but not the other way around. It was never widely adopted because many Microsoft products weren't compatible with it.
Like the unadopted change in OpenSSL, the Chrome fix is designed to protect SSL encryption against plaintext-recovery attacks while remaining compatible with TLS version 1. A quick review of Mozilla's developer website showed no signs that a similar fix is being planned for the Firefox browser.
Most of cryptographers who know the details of Rizzo and Duong's work have agreed not to disclose them ahead of Friday's talk. One of them is Adam Langley, a security researcher for Google. On Monday, shortly after publications including The Register previewed BEAST, he posted the following comment to the Hacker News website:
I happen to know the details of this attack since I work on Chrome's SSL/TLS stack. The linked article is sensationalist nonsense, but one should give the authors the benefit of the doubt because the press can be like that.
Fundamentally there's nothing that people should worry about here. Certainly it's not the case that anything is 'broken'.
He didn't elaborate, and so far Google has had nothing public to say about how BEAST might affect its users. With the discovery that the company's developers have spent the past three months working on a fix, we have some explanation for their insouciance. ®
Sponsored: Becoming a Pragmatic Security Leader