Support for TLS 1.1 and 1.2 is virtually non-existent, Qualys Director of Engineering Ivan Ristic says
Posted on 09/21/2011 10:51:06 AM PDT by ShadowAce
Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that's passing between a webserver and an end-user browser.
The vulnerability resides in versions 1.0 and earlier of TLS, or transport layer security, the successor to the secure sockets layer technology that serves as the internet's foundation of trust. Although versions 1.1 and 1.2 of TLS aren't susceptible, they remain almost entirely unsupported in browsers and websites alike, making encrypted transactions on PayPal, GMail, and just about every other website vulnerable to eavesdropping by hackers who are able to control the connection between the end user and the website he's visiting.
At the Ekoparty security conference in Buenos Aires later this week, researchers Thai Duong and Juliano Rizzo plan to demonstrate proof-of-concept code called BEAST, which is short for Browser Exploit Against SSL/TLS. The stealthy piece of JavaScript works with a network sniffer to decrypt encrypted cookies a targeted website uses to grant access to restricted user accounts. The exploit works even against sites that use HSTS, or HTTP Strict Transport Security, which prevents certain pages from loading unless they're protected by SSL.
The demo will decrypt an authentication cookie used to access a PayPal account, Duong said.
The attack is the latest to expose serious fractures in the system that virtually all online entities use to protect data from being intercepted over insecure networks and to prove their website is authentic rather than an easily counterfeited impostor. Over the past few years, Moxie Marlinspike and other researchers have documented ways of obtaining digital certificates that trick the system into validating sites that can't be trusted.
Earlier this month, attackers obtained digital credentials for Google.com and at least a dozen other sites after breaching the security of disgraced certificate authority DigiNotar. The forgeries were then used to spy on people in Iran accessing protected GMail servers.
By contrast, Duong and Rizzo say they've figured out a way to defeat SSL by breaking the underlying encryption it uses to prevent sensitive data from being read by people eavesdropping on an address protected by the HTTPs prefix.
“BEAST is different than most published attacks against HTTPS,” Duong wrote in an email. “While other attacks focus on the authenticity property of SSL, BEAST attacks the confidentiality of the protocol. As far as we know, BEAST implements the first attack that actually decrypts HTTPS requests.”
Duong and Rizzo are the same researchers who last year released a point-and-click tool that exposes encrypted data and executes arbitrary code on websites that use a widely used development framework. The underlying “cryptographic padding oracle” exploited in that attack isn't an issue in their current research.
Instead, BEAST carries out what's known as a plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness. During the encryption process, the protocol scrambles block after block of data using the previous encrypted block. It has long been theorized 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.
At the moment, BEAST requires about two seconds to decrypt each byte of an encrypted cookie. That means authentication cookies of 1,000 to 2,000 characters long will still take a minimum of a half hour for their PayPal attack to work. Nonetheless, the technique poses a threat to millions of websites that use earlier versions of TLS, particularly in light of Duong and Rizzo's claim that this time can be drastically shortened.
In an email sent shortly after this article was published, Rizzo said refinements made over the past few days have reduced the time required to under 10 minutes.
“BEAST is like a cryptographic Trojan horse – an attacker slips a bit of JavaScript into your browser, and the JavaScript collaborates with a network sniffer to undermine your HTTPS connection,” Trevor Perrin, an independent security researcher, wrote in an email. “If the attack works as quickly and widely as they claim it's a legitimate threat.”
Duong and Rizzo said the underlying vulnerability BEAST exploits is present in virtually all applications that use TLS 1.0, making it possible to apply the technique to monitor private communications sent through many instant messenger and Virtual Private Networking programs.
Although TLS 1.1 has been available since 2006 and isn't susceptible to BEAST's chosen plaintext attack, virtually all SSL connections rely on the vulnerable TLS 1.0, according to a recent research from security firm Qualys that analyzed the SSL offerings of the top 1 million internet addresses.
Chief culprits for the inertia are the Network Security Services package used to implement SSL in Mozilla's Firefox and Google's Chrome browsers, and OpenSSL, an open-source code library that millions of websites use to deploy TLS. In something of a chicken-and-egg impasse, neither toolkit offers recent versions of TLS, presumably because the other one doesn't.
“The problem is people will not improve things unless you give them a good reason, and by a good reason I mean an exploit,” said Ivan Ristic, Qualys's director of engineering. “It's terrible, isn't it?”
While both Mozilla and the volunteers maintaining OpenSSL have yet to implement TLS 1.2 at all, Microsoft has performed only slightly better. Secure TLS versions are available in its Internet Explorer browser and IIS webserver, but not by default. Opera also makes version 1.2 available but not be default in its browser.
Support for TLS 1.1 and 1.2 is virtually non-existent, Qualys Director of Engineering Ivan Ristic says
Ristic, who presented his findings at the Black Hat security conference in August, has found additional evidence that websites often delay deploying upgrades that fix SSL security holes. His analysis found that as much as 35 percent of websites had yet to patch a separate TLS vulnerability discovered in November 2009 that made it possible to inject text into encrypted traffic passing between two SSL endpoints.
Researches said upgrading TLS is proving surprisingly difficult, mostly because almost every fix breaks widely used applications or technologies. A technology recently added to Google Chrome that significantly reduces the time it takes websites to establish encrypted connections with end-user browsers is just one example, said cryptographer Nate Lawson, principal of the Root Labs security consultancy.
Duong and Rizzo said there are many more examples.
"Actually we have worked with browser and SSL vendors since early May, and every single proposed fix is incompatible with some existing SSL applications," Duong wrote. “What prevents people is that there are too many websites and browsers out there that support only SSL 3.0 and TLS 1.0. If somebody switches his websites completely over to 1.1 or 1.2, he loses a significant part of his customers and vice versa.” ®
Yikes!
Thanks for the ping.
Ping.
For folks on IE, you can change to TLS 1.2 via tools>Internet Options then hit the “advanced” tab, scroll down to the “Security” section uncheck TLS 1.0 and check TLS 1.2 and “apply” then restart IE
Do these hacking techniques rely on the browser running on a Windows machine, or do they work on any OS?
Except that very few sites support TLS 1.2. Pages that use SSL either won't load or load the unencrypted version.
This particular threat is not in the wild so there's no reason to panic yet.
So--this is real for all OSes that use TLS 1.0 encryption.
Regarding the time they mention in the article (minutes to seconds per byte), remember that the attacks only get better with time. Expect some smart boffin to come up with a real-time (or near enough to not matter) implementation of this.
PING!
You might wanna take a look at this.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.