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).

Re:Javascript

[Hatta]

For one, /. works a lot better with javascript disabled.

Re:Javascript

[vlm]

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.

Re:OpenVPN, Tor, others

[GameboyRMH]

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:Javascript

[increment1]

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:Javascript

[dissy]

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:Webserver deployment flexibility

[izomiac]

Fall back to regular HTTP then. There's no point in insecure HTTPS. Security is the "S" in these protocols and the sole reason for their existence. Someone who opts to use them has explicitly requested security, not compatibility, as most sites lack any form of SSL.

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 stolen or civil rights activists being killed, that's why anyone puts up with the inconvenience of security in the first place.