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).
gee golly I guess we better just turn it all off and call it quits before the hackers get us.
Get a web developer
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!
What would be the ramifications of disabling TLS 1.0 in the browser (Opera)? By default, TLS 1.0 is enabled and TLS 1.1 & 1.2 is disabled. Also, SSL 3 is enabled and there is no option for earlier versions, so I assume SSL 2 is already disabled in Opera.
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.
Surely Javascript sent from the server with which the SSL session has been made has the opportunity to read what's being transmitted to/from the server anyway? And third party Javascript doesn't get access to random SSL connections with other domains?
What are these guys claiming? That known plaintext at the start of an SSL session plus access to all packets passing between client and server means further characters can eventually be worked out?
It looks like the summary above is mistaken. TFA says that TLS 1.0 and before are affected. Shouldn't that include SSL 3.0 as well as 2.0? It matters because if the summary is correct, we can tell our browsers not to use TLS 1.0 but keep using SSL 3.0. If not, we're stuck waiting for fixes from, well, everybody.
So does it now affect sslv3 even with TLS1.0 activated? If not, then upgrade firefox. Version 6.0.2 has ssl2 disabled.
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
Here's a page that's tracking this for file transfer applications that includes a nice discussion of general purpose web servers and browsers and their current "support of TLS v1.1" status at the end: http://www.filetransferconsulting.com/file-transferbeast-tls-vulnerability/
The Browser break hackers!
This sig is not paradoxical or ironic.
SSLProtocol -all +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM#SSLv3:+HIGH:+MEDIUM
This attack uses Javascript (previously-injected) to try to perform an adaptive chosen-plaintext attack (explicit mention of which dates from 2002[1]). TLS 1.1 and up use explicit random IVs for each CBC block to mitigate that attack, but TLS 1.0 and the older SSL protocols use the previous trailing ciphertext block as the IV for the next packet.
I question whether it really brings anything new to the table as Javascript injection brings the ability to do much more devious things rather than messing around with encryption trying to determine a single session key, but I thoroughly encourage everyone to be running TLS v1.2 already anyway. There's no excuse for having it switched off - all older, incompatible implementations should have been phased out already as they probably don't have fixes for the renegotiation vulnerability anyway.
[1] http://www.openssl.org/~bodo/tls-cbc.txt
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.
It says "against a victim who is on a network on which they have a man-in-the-middle position" so they have installed monitoring software on the victims computer that gives them full access in which case why would they need this is the first place?
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
According to this post, OpenSSL using TLS 1.0 should not be susceptible:
http://marc.info/?l=openssl-dev&m=131654410924995&w=2
Don't know about NSS though.
From what I understand this attack requires known data to be sent through from the public key (client) side, so that attack is pretty useless - if an attacker can force known data through your Tor connection from your side he's either broken into your computer or the .onion site (to plant the malicious JS on it).
"When information is power, privacy is freedom" - Jah-Wren Ryel
If you have a computer at home running on a secured network, then SSH tunneling traffic while you're elsewhere should avert the problem.