Hackers Break Browser SSL/TLS Encryption 110
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).
yikes (Score:2)
Re: (Score:2)
You do realize that 90% of websites out there still use only 2.0 as they are not 3.0 compliant?
Re: (Score:2)
Who do you do your banking with, I want to see if they are still using 2.0, as I know 90% ofg websites are still on 2.0 as we speak
Javascript (Score:4, Informative)
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.
Re:Javascript (Score:4, Informative)
Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!
Re:Javascript (Score:5, Insightful)
For one, /. works a lot better with javascript disabled.
Re:Javascript (Score:5, Funny)
No way man, this place is so much better with ja
Working...
v
Working...
ascr
Working...
ip
Working...
*Ctrl+W*
Working...
*Ctrl+WWWWWWWW*
Working...
*Alt+F4*
Re: (Score:2)
For quite a while, Apple's actually worked decently without javascript. Heck it even renders pretty much the same (it was only until I noticed things were a bit "off" that I realized NoScript was blocking it).
I think though the iTunes pages have completely broken now as have a few others. But until recently, they had a site that worked and acted pretty good withou
Re: (Score:2)
Re: (Score:2)
Not even those, any more many sites use JS to check for Flash and the installed version :/
Re:Javascript (Score:4, Insightful)
Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!
A good first order approximation is any website that is even vaguely attempting to be ADA compliant probably works fine without javascript.
Run with "noscript" for awhile, maybe a couple years, and you'll come to agree.
ADA... (Score:3)
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/ [w3.org]
http://www.w3.org/WAI/ [w3.org]
That it's related to backwards compatibility has to do with vlm's point AFAIK.
Re: (Score:2)
Most people don't even know what ADA compliant even means. Furthermore, what the heck does a client-side language have to do with disabled people? How does javascript inherently prevent a disabled person from interacting with a website?
I don't have a single website that does not use javascript via JQuery. It just works.
NoScript? Fine. As a default that is. You will run into more sites that require javascript to do something, than ones that do not. We just redirect to a page that asks you to turn on j
Re: (Score:2)
So do you provide a costume-making service, or do you service the costume-makers?
Re: (Score:2)
Re:Javascript (Score:5, Insightful)
Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!
As a happy noscript user I was about to reply similarly to VLM below...
But instead it prompted me to check how many entries are in my noscript whitelist after using the same firefox profile for a bit over 3 years, and there are only 275 entries, of which 80 are various internal IPs for work related webapps and testing/development (Which I really need to clean out)
I don't think it's too bad of a sign that in 3 years only 200 websites I've visited were 'broken' without javascript! I was actually expecting a much higher number.
Even with that 200, or lets include the internal webapp sites at work and say 300, with the number of websites I've visited over the past three years it has to be in the high four digits. That is a pretty awesome ratio!
Most websites really do not break enough to matter when rolling without javascript. Even in mitigating this type of attack, I would rather white list the few sites that need it than leave javascript blanket open to every website out there.
Of course this solution isn't 100% perfect (It's "only" mostly perfect), so it will no doubt get poopoo'ed here on slashdot for not being over 100% perfect in every way
Re: (Score:2)
Re: (Score:2)
Don't you use the temporary permissions? I use them for most websites which I don't visit regularly, and AFAIK those don't appear in the whitelist.
Re: (Score:1)
Don't you use the temporary permissions? I use them for most websites which I don't visit regularly, and AFAIK those don't appear in the whitelist.
You are correct that temp items are not added to the whitelist (At least not the one you can export)
I don't really use it though. Not in this way at least.
When I first decide I want to allow a function on a website, if there are multiple domains listed (Usually embedded video pages are the worst at this), I will use temporary allow/block to find the right domain to allow just what I am wanting.
Once I figure out which domains need allowed however, I go back and make them permanent. If I don't trust the web
Re: (Score:2)
Doesn't Gopher have security vulnerabilities too? ;)
Re: (Score:1)
Re: (Score:2)
Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!
Javascript will be long gone from mainstream by then.
Re: (Score:2)
There are something on the order of a few million websites out there, maybe a few hundred million.
95% of the time, you're probably visiting the same small set of websites, so just whitelist those. The other 5%? Temporary whitelist when you visit them. If they're worth visiting again, then maybe you whitelist them next week.
Which is a big step up from let
Re: (Score:2)
Re: (Score:1)
Okay then how do we get malware infections from reputable sites? Yeah the easy way is just to buy ads, the info you harvest would make it well worth the investemnt. And as always human stupidity is unpatchable, you would be surprised by how many people click on links sent to them still.
Re: (Score:1)
me thinks you have spoken too soon. The right answer is "it depends". But, there are ways to get arbitrary javascript to run on web pages. cross site scripting, simple form submission of JS code, MiTM injection, malicious code on the server, etc.
OR, you know something I don't. If so, please share.
Re: (Score:2)
Most of those won't work on an SSL connection. I think the only one that would is a compromised server, but if a (eg) Paypal server is compromised then you've got a lot bigger problems to worry about.
Re: (Score:2)
This is Man-in-the-Middle attack which injects the JavaScript code in the webpage in the SSL-stream I guess...?
Or do it on the HTTP-page...?
I guess we'll know in a few days.
Re: (Score:2)
This is Man-in-the-Middle attack which injects the JavaScript code in the webpage in the SSL-stream.
SSL prevents that (it would be pretty useless otherwise...)
Re: (Score:2)
Re: (Score:2)
If the question is simply a matter of figuring out the plaintext, why bother with javascript at all? After all, somewhere in the middle of this page is going to be the plaintext "If the question is a matter of figuring out the plaintext, why bother with javascript at all?"
Re:Javascript (Score:5, Informative)
Re: (Score:2)
Javascript injection into an SSL connection is a bit more difficult...
Re:Javascript (Score:4, Insightful)
I think the idea is to inject the Javascript before the connection goes SSL. So maybe something like:
1. You go visit www.gmail.com
2. They intercept and return an http version of the page to you with the javascript injected
3. The Javascript opens up an https connection with gmail.com, establishing the IV over a persistent connection.
4. The Javascript redirects to the https page, so you don't notice the lack of https.
5. You log in to the https page as normal, using the browsers already established https connection which they can apparently decrypt.
If not for step 4, this attack would be little different than just intercepting and returning a non-https page and hoping that you didn't notice the difference. Depending on how long your browser keeps a persistent https connection open, I wonder if it is possible to have the javascript on an independent page, making the https requests to the target site to establish the connection before you even go to the target site.
Re: (Score:2)
Unless I'm very mistaken, SSL doesn't work like that. SSL is designed to prevent man-in-the-middle attacks. The session key for the encryption has to be signed using Google's public key - which the attacker can't do.
(Or maybe they can, after all the recent hacks...)
Re: (Score:2)
Unless I'm very mistaken, SSL doesn't work like that. SSL is designed to prevent man-in-the-middle attacks. The session key for the encryption has to be signed using Google's public key - which the attacker can't do.
The SSL session is signed, but according to this new attack, if an attacker can inject known plaintext and see the sniffed encrypted text of the same, then they can somehow manage to decrypt some portion (or all) further communication. So it is not breaking the establishment of the SSL connection (as a normal MITM attack would), it is directly decrypting the encrypted communication (the confidentiality component of SSL).
Re: (Score:2)
Re: (Score:2)
That makes much more sense, I would expect to see the 'some of the data is not encrypted warning' with what increment1 proposed.
Re: (Score:3)
Re: (Score:2)
Should we disable TLS 1.0 in browsers? (Score:1)
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.
Re:Should we disable TLS 1.0 in browsers? (Score:4, Informative)
Re: (Score:2)
Re:Should we disable TLS 1.0 in browsers? (Score:4, Informative)
Stolen from the thread on this on reddit [reddit.com]:
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.
Re: (Score:2)
SSL2 has been gone in any decent browser for a long time now. The latest versions of Chrome (currently 15.0.874.1) don't even have checkboxes for SSL3/TLS any more, so fuck knows what data it's leaking behind my back...
Re: (Score:3)
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.
Re: (Score:2)
I'll repeat myself: in 15.0.874 those boxes are gone.
Not very fast? (Score:5, Interesting)
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.
Re: (Score:1)
Re: (Score:2)
At least with my bank, I can sign multiple transactions with a single OTP. If you can intercept the connection, you can insert another transfer into the list and then alter the HTML to not display that entry, but I'd still sign it along with the others I actually want to do.
Re: (Score:2)
With a high enough amount, my bank will also require to input the total sum in the calculator. A long time ago they did not say what the number meant (which is weird, because people will enter it without checking) but now it has been made explicit.
Speculation on the attack (Score:3)
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 [blogspot.com]
Re: (Score:2)
I don't at all mind the blog whoring, but copy-paste is pretty easy.
Re: (Score:2)
XOR symbols, images and boldface text don't copy paste very nicely.
Re: (Score:2)
That post should be TFA this thread is discussing! Thanks for sharing.
Ah ha! (Score:5, Funny)
Re: (Score:1)
Thanks, that is the first time ./ has made me laugh in a while.
Webserver deployment flexibility (Score:2)
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 serv
Re: (Score:2)
SSLv2 being accepted by the server is a misconfiguration.
I manage multiple sites used by Fortune 100 companies (who are often slow to upgrade clients) and have had SSLv2 turned off on the server for years.
Re: (Score:3, Insightful)
For most bugs, you're right. Convenience trumps most other things in software. Security is not one of them. Your users are trusting you to keep them safe. An insecure browsing session will eventually (quickly?) lead to money being stole
Re: (Score:2)
> Fall back to regular HTTP then. There's no point in insecure HTTPS.
But there is a point in insecure HTTP??
> Security is the "S" in these protocols and the sole reason for their
> existence.
I know this is hard for guys like you to accept, but the much-touted "S" has become a ridiculous notion. Especially when coupled with some outlandish DEV-belief, that users "have a sense of security", trained or otherwise.
SSL IN ITS CURRENT FORM IS BROKEN AND HAS BEEN SINCE THE BEGINNING!!
wait what (Score:2)
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?
Re: (Score:2)
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?
That seems to be what they are claiming. If you know at least SOME of what is encrypted, it becomes much easier to decrypt the rest.
Re:OpenVPN, Tor, others (Score:4, Insightful)
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.
Re: (Score:2)
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).
Isn't SSL 3.0 affected as well? (Score:2)
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.
Re: (Score:3)
Yea, to the Slashdot editors:
Note that this only affects SSL 3.0 and TLS 1.0
Re: (Score:2)
Nice. Guess which are the only two options available on this browser...
Re: (Score:2)
Yea, SSL 2.0 has worse flaws, not only the protocol flaws but also that Netscape 1.x's random number generator was not really random too.
Re: (Score:2)
Yea, to the Slashdot editors:
Note that this only affects SSL 3.0 and TLS 1.0
The editors are too busy telling us that this is the first article from the submitter to be accepted; you can't expect them to perform that important function and actually glance at the article, now can you?
Yes, SSL 3.0 and TLS 1.0 are both affected. (Score:1)
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/ [filetransf...ulting.com]
SSL v3 (Score:2)
So does it now affect sslv3 even with TLS1.0 activated? If not, then upgrade firefox. Version 6.0.2 has ssl2 disabled.
Re: (Score:1)
While reading this, I received notification from Firefox that an update was available. Was thinking "That was quick!", but alas - is a fix for reducing memory footprint.
In Soviet Russia... (Score:1)
The Browser break hackers!
Apache2 fix (Score:2)
SSLProtocol -all +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM#SSLv3:+HIGH:+MEDIUM
If they won't disclose, I will (Score:1)
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 w
Did anyone read the story? (Score:1)
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?
Re: (Score:3)
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.
Already fixed in OpenSSL in TLS 1.0? (Score:1)
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.
SSH Tunneling (Score:3, Informative)