The most effective way to promote good security is to hack the bad stuff. The vulnerabilities of non-SSL logins were known for years, but no real progerss was made until Firesheep got released (and we're still not there yet). The numerous cross-browser flaws around clearing persistent web data were known, but were barely discussed until Evercookie came out. BEAST might be the thing that pushes modern browsers off of obsolete security protocols. (TLS 1.0 was hacked; 1.2 is not vulnerable and it's been available for years.)
If you want a secure web, support your local hackers.
Snazzy headline, but not entirely true, and cool tool-name (BEAST).
As of yet it's unclear what an attacker can really do with that.
From the looks of it, it seems an attack would have to be twofold: 1. get a piece of code (Java, Javascript) on the victim machine, which can inject known-plaintext into the communications stream, and thus shift the data the attacker's interested in to block boundaries 2. sniff the SSL packets on the wire, and run a known-plaintext attack on them, thus cracking the interesting data one byte at a time, per request
If this first analysis holds, it's more of an academic attack - more tomorrow, once they release actual detail.
Don't underestimate the implications, however. Code injections are common in browsers, and getting some native code into the machine to run the actual cracking wouldn't be too hard (especially since that piece of code doesn't need to break out from a sandbox). And you can also easily unload the decrypting from the known-plaintext on another, dedicated, machine.
The good news is that there are two ways to combat this attack: one is to get out the TSL 1.2 system (hard to do, since that will require two parts to do the updating), the other is to make code injection harder (and here the browser makers are making good strides forward).
I guess this once again shows that no system is stronger than its weakest link, and there are plenty of weak links in the security systems on the net.
At the moment we here think that mitigating this should be doable in the browsers, as it relies on a gazillion requests, plus at least for the big content providers like FB, google, spamazon, as they should be able to detect this also due to the amount of requests (as long as the connection's not MITMed, of course!). Both probably easier, at least in the short term, than to migrate the necessary portion of browsers and providers beyond SSL3.0/TLS1.0.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2011-09-22 01:50 am (UTC)If you want a secure web, support your local hackers.
(no subject)
Date: 2011-09-22 02:32 am (UTC)(no subject)
Date: 2011-09-22 06:40 am (UTC)As of yet it's unclear what an attacker can really do with that.
From the looks of it, it seems an attack would have to be twofold:
1. get a piece of code (Java, Javascript) on the victim machine, which can inject known-plaintext into the communications stream, and thus shift the data the attacker's interested in to block boundaries
2. sniff the SSL packets on the wire, and run a known-plaintext attack on them, thus cracking the interesting data one byte at a time, per request
If this first analysis holds, it's more of an academic attack - more tomorrow, once they release actual detail.
(no subject)
Date: 2011-09-22 09:09 am (UTC)The good news is that there are two ways to combat this attack: one is to get out the TSL 1.2 system (hard to do, since that will require two parts to do the updating), the other is to make code injection harder (and here the browser makers are making good strides forward).
I guess this once again shows that no system is stronger than its weakest link, and there are plenty of weak links in the security systems on the net.
(no subject)
Date: 2011-09-22 09:16 am (UTC)Both probably easier, at least in the short term, than to migrate the necessary portion of browsers and providers beyond SSL3.0/TLS1.0.
(no subject)
Date: 2011-09-22 10:21 am (UTC)