BEAST attack

BEAST attack
Name	BEAST attack
Discovered	2011
Affected	SSL 3.0, TLS 1.0
Mitigated by	Updated TLS implementations, cipher suite changes

BEAST attack is a cryptographic attack against protocols based on the Secure Sockets Layer and Transport Layer Security standards that demonstrates a practical chosen-plaintext vulnerability in block cipher modes used by those protocols. First publicized in 2011, the attack targeted real-world deployments of OpenSSL, Microsoft Windows, Mozilla Firefox, Google Chrome, and other implementations relying on Secure Hash Algorithm-based constructions and Cipher Block Chaining mode. Researchers and organizations including Thai Duong, Juliano Rizzo, University of California, Berkeley, NIST, and ENISA contributed to analysis, disclosure discussions, and mitigation guidance.

Background

The attack exploited the interaction of Cipher Block Chaining mode with predictable protocol structures in TLS 1.0 and SSL 3.0 implementations used by servers and clients such as Apache HTTP Server, NGINX, IIS (Internet Information Services), Lighttpd, and libraries like OpenSSL. Historical development of TLS traces to work at Netscape Communications Corporation, standards at the IETF, and cryptographic primitives designed by entities including Ronald Rivest, Adi Shamir, and Leonard Adleman whose RSA (cryptosystem) influenced public-key negotiation in these protocols. Prior vulnerabilities in protocol design and implementation had been examined by groups at University of California, Berkeley, MIT, Stanford University, and Cambridge University contributing to a rich literature on block cipher modes, padding oracle attacks, and MAC-then-encrypt versus encrypt-then-MAC debates championed by researchers such as Philippe Flajolet and Shai Halevi.

Technical details

BEAST leverages a chosen-plaintext attack against the use of Cipher Block Chaining in TLS record-layer construction when combined with predictable initialization vectors, fixed record boundaries, and a MAC-then-encrypt composition specified in RFCs by the IETF. Implementation targets included libraries such as OpenSSL, GnuTLS, NSS (software) used by Mozilla Foundation, and SChannel in Microsoft Windows NT family. The exploit uses repeated injection of attacker-controlled plaintext via mechanisms like Cross-site scripting in browsers such as Mozilla Firefox, Google Chrome, Internet Explorer, and Opera (web browser), or via hostile HTTP cookie manipulation between clients and servers like Apache HTTP Server and Tomcat (software). The attack recovers secret bytes by observing ciphertext blocks and exploiting predictable positions of session cookies, authentication tokens generated by services like Facebook, Gmail, Yahoo! Mail, and Twitter. Its success depends on control over plaintext prefix alignment, timing, and multiple TLS records as found in interactions with HTTP/1.1, AJAX, XMLHttpRequest, WebSocket pre-standard implementations, and content delivery systems such as Akamai Technologies.

Discovery and disclosure

Public disclosure came in 2011 when researchers including Thai Duong and Juliano Rizzo published demonstrations and whitepapers, following coordinated vulnerability reporting workflows similar to practices of CERT Coordination Center, US-CERT, and industry disclosure norms advocated by organizations like FIRST. Prior discussions involved cryptographers linked to IETF TLS Working Group, academics at University of California, Berkeley and Vrije Universiteit Amsterdam, as well as maintainers of OpenSSL and major browser vendors including Mozilla Foundation, Google, and Microsoft Corporation. The timetable mirrored earlier incidents like the disclosure of Heartbleed and later informed disclosure approaches used for POODLE and DROWN.

Impact and exploitation

Real-world exploitation potentially allowed recovery of session cookies and authentication tokens enabling session hijacking against services hosted by Google, Facebook, Twitter, Amazon, eBay, PayPal, Bank of America, and other web platforms relying on TLS. Operational risk affected deployments of Apache HTTP Server, NGINX, Tomcat (software), and proprietary servers from vendors like Microsoft Corporation and Oracle Corporation. Security teams at Mozilla Foundation, Google, Microsoft Corporation, Apple Inc., and CDN providers such as Akamai Technologies and Cloudflare responded with mitigations. The attack illustrated weaknesses also examined in academic venues including USENIX, ACM CCS, IEEE S&P, and CRYPTO proceedings.

Mitigations and defenses

Short-term mitigations included client-side changes by browser vendors—implementations in Mozilla Firefox, Google Chrome, Microsoft Internet Explorer—and server-side updates to OpenSSL, GnuTLS, and NSS (software). Defenses recommended by bodies like IETF and NIST included prioritizing TLS versions that support Authenticated Encryption with Associated Data modes such as AES-GCM, adopting Encrypt-then-MAC proposals by researchers associated with Ronald Rivest and Silvio Micali, and deploying TLS 1.1/1.2 where protocol changes moved IV handling away from the vulnerable construction. Operational mitigations included disabling vulnerable cipher suites on Apache HTTP Server, NGINX, and IIS (Internet Information Services), applying patches from OpenSSL and vendors, enabling HTTP Strict Transport Security for sites like Wikipedia, GitHub, and Bank of America, and encouraging use of secure cookie attributes employed by OWASP guidance.

Legacy and related vulnerabilities

The BEAST disclosure accelerated adoption of newer TLS features and spurred further research into protocol-level attacks such as POODLE, DROWN, CRIME, BREACH, and later layered weaknesses found in Heartbleed and other TLS/SSL related defects. It influenced standards work at the IETF TLS Working Group and informed cryptographic advice from NIST and ENISA. Long-term impacts affected major platforms including Google, Mozilla Foundation, Microsoft Corporation, Apple Inc., Amazon Web Services, and Cloudflare through deprecation of legacy cipher suites and promotion of TLS 1.3 specifications ratified by the IETF that incorporate AEAD constructions and improved handshake semantics. The episode remains part of curricular material at institutions like MIT, Stanford University, University of Cambridge, and ETH Zurich and is cited in security guidance from organizations such as OWASP and SANS Institute.

Category:Computer security