Slashdot Mirror
Hackers Break Browser SSL/TLS Encryption
First time accepted submitter CaVp writes with an article in The Register about an exploit that appears to affect all browsers and can decrypt an active TLS session. From the article: "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."
A full disclosure is scheduled for Friday September 23rd at the Ekoparty conference. Note that this only affects SSL 2.0 and TLS 1.0; unfortunately, most web servers are misconfigured to still accept SSL 2.0, and TLS 1.1 and 1.2 have seen limited deployment. The practicality of the attack remains to be determined (for one, it isn't very fast — but if the intent is just to decrypt the data for later use, that isn't an impediment).
From the looks of it, they use javascript on the target computer to capture some plain text which helps them break the keys. So as a temporary measure, disable javascript until browser makers catch up.
Give me Classic Slashdot or give me death!
The attack can apparently be completed in about 5 minutes. That is plenty of time for attacking the average online banking session, never mind gmail and other sites that people log in to for hours at a time.
The attack appears to use javascript to push known plaintext over HTTPS to the web site before the actual login request is sent, so that the login credentials are transferred as part of a persistent SSL connection which now has a known IV. If this is correct, then the attack could be avoided by disabling persistent HTTPS connections in the browser. There is a performance cost to this, but I think most people would prefer to feel secure, and wouldn't really notice the extra costs of opening and closing individual HTTPS sessions for each browser request. Proxies might break that though.
Now we know what that 30,000 node EC2 cluster was for...
Uh, I'm pretty sure the web server is required to have enough flexibility for people to view the content. If the user demands security, that should to be negotiated by the client trying to use the most secure option possible. Saying a server is "misconfigured" might be nice for someone living in a bubble where everything is up to date and users have a clue, but in the real world servers don't have this option.
The ramification is that you won't be able to use HTTPS on the vast majority of web sites. According to the Register, of 1 million web servers sampled: 604,242 supported TLS v1.0, 838 supported TLS v1.1, and 11 supported TLS v1.2.
Stolen from the thread on this on reddit:
That's actually exactly how it's supposed to work. See Appendix E of the TLS 1.2 RFC. The client sends its highest-supported version in its first message, and the server replies with the highest-supported version that is less than or equal to the version the client sent.
Unfortunately, some older (mostly third-party) servers break entirely if they receive something that they don't recognize. As such, TLS 1.1/1.2 is often disabled by default for compatibility reasons, even if it is supported.
NSS (Mozilla/Firefox) and OpenSSL (used in Apache's mod_ssl) also only support up to TLS 1.0 in their stable versions, as there hasn't really been a compelling reason for them to add TLS 1.1/1.2 support until now.
Its not what it is, its something else.
Yea, to the Slashdot editors:
Note that this only affects SSL 3.0 and TLS 1.0
Not really. This attack makes the encryption easier to brute-force later on by first passing known data over it. It's like if an attacker could force a known file onto your encrypted disk and know its exact location on the disk, that would then make it easier to brute-force the key.
So yeah it shows that there are some weaknesses in the algorithm, but if another party can inject known data into your SSH/Tor/OpenVPN session you have much bigger problems anyway.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Sure they do: Options -> Under the Hood. There's a checkbox for SSL 3.0, and one for TLS 1.0. So, similar to what the poster above you said, it looks like they don't expose TLS 1.1/1.2 in releases yet.
I vote based on politicians' actions, unless contrary to my preconceptions. Often wrong, never uncertain. #iamthe99%
Americans With Disabilities Act, not American Dental Association
Reminds me of a web-design instructor in highschool who was real big on trying to make one's sites disabled-accessible. For instance, make the site decipherable and navigable by screen readers for the blind
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/
http://www.w3.org/WAI/
That it's related to backwards compatibility has to do with vlm's point AFAIK.
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
Here's my description/speculation about how it works. Apologies for the blog whoring, I can't type it all up again:
http://practicalcrypto.blogspot.com/2011/09/brief-diversion-beast-attack-on-tlsssl.html
It's "man-in-the-middle" because it requires a javascript injection. That might be possible through vulnerabilities in particular websites (eg embedded ads with javascript, or a crafted link, etc). It could also be injected by an ISP.
If you have a computer at home running on a secured network, then SSH tunneling traffic while you're elsewhere should avert the problem.