First solutions for SSL/TLS vulnerability
Security specialists have suggested using RC4 to remedy the SSL/TLS vulnerability that became known to the wider public last week. Unlike AES, which is used on most servers, the stream encryption algorithm doesn't use the Cipher Block Chaining (CBC) mode. The CBC implementations in all versions up to SSL 3.0/TLS 1.0 are vulnerable to "chosen-plaintext" attacks.
At the heart of the problem are initialisation vectors (IVs) that aren't randomised for every block – the vectors are supposed to ensure that identical blocks don't generate the same cipher – this allows cookies that are transmitted in encrypted form to be determined much quicker with "educated guesses" than with brute force. To be successful, however, a Man-in-the-Middle attack (MitM) must be used to intercept the victim's server connection and communicate with the server in the victim's context.
The problem can be solved by switching to the TLS 1.1 standard, which was adopted in 2006; there, the IVs for CBC are randomised, which renders the described attack ineffective. However, switching is potentially problematic because not all servers and browsers support the standard.
According to analysis by security specialist Thierry Zoller, Chrome and Firefox use the Network Security Services (NSS), which only support TLS 1.0. Windows Vista, XP, 2000 and Server 2003 as well as Server 2008 are also incapable of using TLS 1.1 by default. Only Windows 7 and Server 2008 R2 can use TLS 1.1. Opera 10, on the other hand, even works with TLS 1.2 servers. However, it is no use changing the browser configuration if the server doesn't support the standard.
OpenSSL, which tends to be used with Apache web servers, doesn't yet offer TLS 1.1; there, the only effective measure is to switch to GnuTLS or RC4. The cipher suites to be used can be defined in the ssl.conf OpenSSL configuration file. Instructions on how to modify an IIS 7 can be found in Cipher Suite Mitigation for BEAST.
Meanwhile, Google has implemented a fix in the developer version of Chrome that had been proposed by the OpenSSL developers back in 2004. To make it more difficult for attackers to control the plain text to be injected, packets are split up, and an empty one is added before each packet. The addition of empty packets as a protective measure has been implemented in OpenSSL for some time. However, Zoller said that the measure isn't enabled by default for compatibility reasons.
So far, most developers and web server operators have been tentative with their problem assessment; one reason for this could be that the BEAST tool hasn't become publicly available yet.