Feeds

Google preps Chrome fix to slay SSL-attacking BEAST

20-line patch targets plaintext recovery exploit

Beginner's guide to SSL certificates

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. ®

Protecting users from Firesheep and other Sidejacking attacks with SSL

More from The Register

next story
Spies would need SUPER POWERS to tap undersea cables
Why mess with armoured 10kV cables when land-based, and legal, snoop tools are easier?
Early result from Scots indyref vote? NAW, Jimmy - it's a SCAM
Anyone claiming to know before tomorrow is telling porkies
Jihadi terrorists DIDN'T encrypt their comms 'cos of Snowden leaks
Intel bods' analysis concludes 'no significant change' after whistle was blown
TOR users become FBI's No.1 hacking target after legal power grab
Be afeared, me hearties, these scoundrels be spying our signals
Hackers pop Brazil newspaper to root home routers
Step One: try default passwords. Step Two: Repeat Step One until success
China hacked US Army transport orgs TWENTY TIMES in ONE YEAR
FBI et al knew of nine hacks - but didn't tell TRANSCOM
Microsoft to patch ASP.NET mess even if you don't
We know what's good for you, because we made the mess says Redmond
NORKS ban Wi-Fi and satellite internet at embassies
Crackdown on tardy diplomatic sysadmins providing accidental unfiltered internet access
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
WIN a very cool portable ZX Spectrum
Win a one-off portable Spectrum built by legendary hardware hacker Ben Heck
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
Protecting users from Firesheep and other Sidejacking attacks with SSL
Discussing the vulnerabilities inherent in Wi-Fi networks, and how using TLS/SSL for your entire site will assure security.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.