Researchers Devise New Attack Techniques Against SSL 33
alphadogg writes "The developers of many SSL libraries are releasing patches for a vulnerability that could potentially be exploited to recover plaintext information, such as browser authentication cookies, from encrypted communications.The patching effort follows the discovery of new ways to attack SSL, TLS and DTLS implementations that use cipher-block-chaining (CBC) mode encryption. The new attack methods were developed by researchers at the University of London's Royal Holloway College. The men published a research paper and a website on Monday with detailed information about their new attacks, which they have dubbed the Lucky Thirteen. They've worked with several TLS library vendors, as well as the TLS Working Group of the IETF, to fix the issue."
Could this be the NSA's secret crack? (Score:3, Insightful)
Rumors have been going around for a while that the NSA is able to crack certain forms of SSL or lower-level AES, and their new data center is for a "store now, decrypt later" operation. Could this be what they have?
Re: (Score:3, Informative)
No.
Paranoid though I am, this is a timing attack needing multiple packets. Not something you can do 'offline'
Re:Could this be the NSA's secret crack? (Score:5, Insightful)
Yes, the NSA has broken AES, which is why all of the encryption standards they use for their secrets are based on it. Beccause, if they can break it, there's no way someone like, I don't know, China could.
I consider myself on the paranoid side of tech, but even I treat rumors about the NSA seccretly breaking low level schemes the same way I treat rumors about UFOs.
Re: (Score:1)
Well it's not so far fetched as you think. They talk about it themselves:
http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/ [wired.com]
Meanwhile, over in Building 5300, the NSA succeeded in building an even faster supercomputer. “They made a big breakthrough,” says another former senior intelligence official, who helped oversee the program. The NSA’s machine was likely similar to the unclassified Jaguar, but it was much faster out of the gate, modified specifically for cryptanalysis and targeted against one or more specific algorithms, like the AES. In other words, they were moving from the research and development phase to actually attacking extremely difficult encryption systems. The code-breaking effort was up and running.
The breakthrough was enormous, says the former official, and soon afterward the agency pulled the shade down tight on the project, even within the intelligence community and Congress. “Only the chairman and vice chairman and the two staff directors of each intelligence committee were told about it,” he says. The reason? “They were thinking that this computing breakthrough was going to give them the ability to crack current public encryption.”
Start buying more tinfoil!
Re: (Score:3)
Re: (Score:2)
Don't worry, we have "Researchers" on it. Top "Researchers".
I'm safe (Score:5, Funny)
The attack relies on the slight difference in processing time of certain packets.
My ISP is so over-subscribed that latency here varies from packet to packet by 1 second.
They are obviously doing this on purpose to protect their clients.
Break the internet (Score:1)
Workaround for the Cheap, Lazy, and/or Incompetent (Score:2)
Slashdot has long had a solution for avoiding many potential SSL/TLS security-breach incidents: Deny users the privilege of utilizing SSL/TLS and that precious certificate unless there's a damn good reason, e.g., logging in. After that single use, dump 'em back to unauthenticated plaintext.
This same tease & denial [wikipedia.org] technique is employed on all of the rest of Dice Holdings holdings—including SourceForge (albeit in a slightly more lenient manner)—logged-in users enjoy all-you-can-eat HTTPS (and
Re: (Score:2)
Maybe you should look up SSL stripping attacks, and then there is just sniffing the session cookies out of the air, please see firesheep for a tool designed to do this.
ASLR for HTTP headers? (Score:2)
One of the attack requirements is to find the target data at a fixed offset in the SSL packets. This is the case for session cookies, which aresend back and forth in HTTP headers Set-Cookie and Cookie.
Why don't we just randomize HTTP headers order? Such a defense, inspired by ASLR for native programs, seems cheap to implement, and would make the attacker life more difficult. There could even be padding HTTP headers inserted at random places. Something like X-Padding: foobarbuz
New Timing Attack (Score:5, Informative)
It only works in datagram TLS (DTLS) because regular TLS terminates a session after one incorrectly padded message. It also only works over LAN where you can get really precise timing.
Re: (Score:3)
So... (Score:2)
Since CBC is discouraged after the BEAST attack (Score:2)
Re: (Score:2)
Unless you're trying to get PCI compliance, in which case expect to be told that mitigating BEAST attacks isn't good enough, you need to not be vulnerable to them at all!
Is this the same PCI that asserts "secure" hash algorithms can be used to tokenize credit card numbers?
Why are idiots even allowed to write security specifications and why do the rest of us tolerate it?
The world has gone insane (Score:1)