Experts propose workarounds for BEAST SSL/TLS attack

SECURITY EXPERTS AND BROWSER VENDORS are trying out workarounds for an attack against many SSL/TLS implementations that was disclosed at a security conference last week.

On Friday, security researchers Juliano Rizzo and Thai Duong demonstrated their Browser Exploit Against SSL/TLS (BEAST) attack at the ekoparty security conference in Buenos Aires, revealing technical details about how it works and the vulnerability it exploits.

The flaw leveraged by BEAST has been known for almost a decade and affects SSL/TLS ciphers that use the Cipher Block Chaining (CBC) mode. These include the popular AES and Triple-DES encryption methods.

The vulnerability was addressed back in 2006 in TLS 1.1, but most libraries still use the 1.0 version of the protocol for compatibility reasons. Even worse, some web browsers still support the 12-year-old SSL 3.0 specification in addition to TLS, which is also vulnerable.

So, even if they were to update TLS 1.0 to 1.1, attackers could still force a fallback to SSL 3.0 and exploit the vulnerability. This makes it very hard to fix the problem at the web browser level without breaking anything.

Google Chrome engineer Adam Langley points out that Chrome developers have already tested a known workaround for TLS 1.0 and SSL 3.0, but they had to revert it because it caused too many incompatibilities.

Fortunately, the team has since come up with another solution that should theoretically generate fewer problems and has added it to the Chrome dev and beta channels. This will allow the patch to be tested thoroughly before moving it into the stable version.

Langley stresses, however, that BEAST is not an easy attack to pull off. The attacker needs to be on the same wireless network as his victim, which makes it less of an issue than, say, drive-by downloads.

"An attacker with MITM [man-in-the-middle] abilities doesn't need to implement this complex attack. SSL stripping and mixed-scripting issues are much easier to exploit and will take continued, sustained effort to address," he concludes.

Meanwhile, the issue is easier to address for a webmaster. According to Steve Dispensa, CTO and co-founder of multi-factor authentication company Phonefactor, the easiest route is to switch to an encryption algorithm that doesn't use CBC, like those based on the RC4 stream cipher.

"Servers can protect themselves by requiring a non-CBC cipher suite. One such cipher suite is rc4-sha, which is widely supported by clients and servers," Dispensa says. There is already a good example of such an implementation. Google has already been using RC4 for its SSL/TLS processing for years. µ