Red alert: HTTPS has been hacked

BEAST attack breaches browser connections

Only a handful of exploits per decade reveal a vulnerability that is truly significant. Thai Duong and Juliano Rizzo's BEAST (Browser Exploit Against SSL/TLS) attack will rank among them because it compromises the SSL and TLS browser connections hundreds of millions of people rely on every day. BEAST cannot break the latest version of TLS — the current standard based on SSL — but most browsers and nearly all websites that support secure connections rely on earlier versions of the SSL and TLS protocols, which are vulnerable to BEAST attack. Browser vendors and websites that host secure connections are already scrambling to upgrade to TLS 1.1 or 1.2. How quickly that occurs depends on how many attacks occur in the wild. The BEAST tool, presented last Friday at the 2011 Ekoparty Security Conference in Argentina, made real a theoretical SSL/TLS vulnerability first documented 10 years ago. It allows an attacker with previous MitM (man-the-middle) access to compromise a user's SSL/TLS-protected HTTPS cookie. This would allow an attacker to hijack the victim's active HTTPS-protected session or listen in on the previously cryptographically protected network stream. (Download Duong and Rizzo's paper on the BEAST attack [pdf]) MitM attacks are fairly easy to do when the attacker and victim are located on the same local network (such as wireless networks, VPNs, or corporate LANs). Some hacking tools, such as Cain & Abel, make MitM attacks and network packet sniffing truly a click of a button. An old flaw turns critical

BEAST takes advantage of the fact that versions of TLS and SSL prior to TLS 1.1 (often referred to as SSL 3.2) do not use an implicit random IV (initialization vector) with each subsequent data stream initiated in an HTTPS connection. This particular SSL/TLS flaw was first discussed at an OpenSSL development forum in 2002. It's similar to the cryptographic weakness found in the WEP protocol, which significantly weakened the protection of wireless networks. The flaw isn't new, but many defenders counted on the fact that creating the conditions necessary to exploit it were "nontrivial," a term that in cryptography circles means nearly impossible to accomplish. Duong and Rizzo, two accomplished vulnerability experts, figured it out. The BEAST tool works by creating additional "known" plaintext data blocks that are encrypted using known IVs. In cases of TLS 1.0/SSL 3.1 and earlier, RFC 2246 dictates that the IV of one packet or data stream is the last ciphertext block from the previous packet or data stream. This is inherently weak, because many of today's cryptographically protected data streams use cipher-block chaining, or CBC mode, for speed. In CBC mode, each block of plaintext is encrypted with information from the previous encrypted block. What makes each subsequent enciphered block unique (and uncrackable) from the previous block is a randomly generated IV. At least that's what is supposed to happen, but sometimes, as early versions of SSL and TLS (and WEP), it doesn't. BEAST uses JavaScript running in a victim's Web browser to initiate many different encrypted data blocks, each time knowing the IV and the plaintext that is being encrypted (in an appropriately designed encryption system, neither of these conditions should be possible as it gives the attacker far too much known information to crib from). This is known as a "block-wise adaptive chosen plaintext attack." This attack was first theorized against SSL/TLS in 2006 by Gregory V. Bard [7]. It led to the formation of TLS 1.1 and is implemented in OpenSSL 0.9.6d and later. Unfortunately, TLS 1.1 and 1.2 versions are not enforced anywhere by default -- and to be effective, all other previous HTTPS protocols must be disallowed by at least one side of the connection. Most HTTPS-protected websites will probably not upgrade to TLS 1.1 or 1.2 for some time; if you upgrade your browser to TLS 1.1 and disallow any other type of connection, you will not be able to establish connections to most HTTPS hosts. TLS 1.1 browser support

Only some of today's popular browsers currently support TLS 1.1, and even then, it may not be enabled by default. The latest versions of Microsoft Internet Explorer, Opera, and Windows versions of Safari support TLS 1.1 or 1.2. Google Chrome should have a fix out soon. For more detail, see Thierry Zoller's TLS/SSL Hardening & Compatibility Report 2011 (PDF). Most observers expect all current capable browsers will enable TLS 1.1 and 1.2 by default soon. Microsoft offers built-in cipher support through its Schannel mechanism as an inherent part of Microsoft Windows. Both Microsoft Internet Explorer (5 and later) and Apple Safari (running on Windows) use Schannel. Schannel currently only offers support for TLS 1.1 and 1.2 on Microsoft Windows 7/Windows Server 2008 R2 (and later). It is unknown what Microsoft plans to do regarding earlier versions of Windows. In current versions of IE, TLS 1.1 and 1.2 are available, but are not enabled by default. All readers with Internet Explorer should enable TLS 1.1 and 1.2 now. To enable in IE, from the menu choose Tools, Internet Options, and then the Advanced tab. Go to the bottom of the Settings options and enable TLS 1.1 and 1.2. Opera 10.x and later supports TLS 1.1 and 1.2. Unfortunately, you really aren't fully protected unless you disable all other HTTPS protocols prior to TLS 1.1 and 1.2. Although you can do this in IE and Opera, you'll quickly find out that most websites don't yet support the newer protocols. Some early website surveys are reporting less than 1 percent of HTTPS websites support TLS 1.1 or 1.2. Google Chrome, Mozilla Firefox, and Safari running on Mac OS X use their own custom cipher engines. Chrome and Firefox use the NSS (Network Security Services) for SSL/TLS support. NSS does not currently support TLS 1.1 or 1.2, so neither Chrome nor Firefox currently support them without an upgrade or fix. Google Chrome will have a custom fix out soon that defangs the BEAST attack by inserting more randomness into TLS 1.0. Mozilla has had bug requests asking for newer TLS support for Firefox going back to March 2008, but so far has not publicly announced its intentions to combat the BEAST attack. Safari on Mac OS X only supports TLS 1.0. For the time being, some users are reverting to IE or Opera for HTTPS-protected websites. It's another question about whether your mobile device or smartphone supports TLS 1.1 or 1.2. WebKit, which is used by Safari and other browsers, was updated in November 2010 to support the latest versions, but you'll have to test to see if your mobile device has that version. The BEAST attack is a serious threat against browsers. The MitM requirement will probably slow down the attack's spread in the wild — which will give websites and browser vendors a window of opportunity to roll over to TLS 1.1 or TLS 1.2 with all deliberate speed. We've known about this vulnerability for at least 10 years. It's a shame that it has taken a real-world attack tool to spur us to abandon protocols that are at least half a decade old. BEAST is not likely to impact millions of users immediately, but it has serious implications for the unlucky victims. If we're lucky, the BEAST attack will be recorded in history as a wake-up call rather than a wholesale security disaster.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags SSLTLSSecurity IDbeast

Show Comments
[]