Slashdot Mirror

← Back to Stories (view on slashdot.org)

Researchers Devise New Attack Techniques Against SSL

Posted by samzenpus on from the protect-ya-neck dept.

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

16 of 33 comments (clear)

  1. Could this be the NSA's secret crack? by GameboyRMH · · Score: 2, 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?

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
    1. Re:Could this be the NSA's secret crack? by Anonymous Coward · · Score: 3, Informative

      No.

      Paranoid though I am, this is a timing attack needing multiple packets. Not something you can do 'offline'

    2. Re:Could this be the NSA's secret crack? by Anonymous Coward · · 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.

    3. Re:Could this be the NSA's secret crack? by PartyBoy!911 · · 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/

      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!

  2. I'm safe by GloomE · · 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.

  3. Workaround for the Cheap, Lazy, and/or Incompetent by cffrost · · Score: 1

    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 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 the nightmarish specter of its subsequent compromise); unknown, cookie-free scum can rot... We can't have casual passersby getting fingerprints all over that precious certificate, now can we?

    FFS Dice Holdings, how about a little Dice Improving?

    --
    Thank you, Edward Snowden.

    "Arguments from authority are worthless." —Carl Sagan
  4. Re:RIP Internet by YodasEvilTwin · · Score: 2

    What, because cash and paper documents are oh-so-secure?

  5. ASLR for HTTP headers? by manu0601 · · Score: 1

    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

  6. New Timing Attack by cryptizard · · Score: 5, Informative

    For lazy people a quick overview of this attack is that it uses very small differences between the amount of time it takes to decrypt a correctly padded TLS record and the time it takes to reject an incorrectly padded record (think of the padding as kind of a checksum). An attacker can modify encrypted records, send them to the server and discover whether the decryption is correctly padded or not based on the amount of time it takes to respond. With this knowledge, an attacker can interactively decrypt a record bit by bit, testing the padding over and over.

    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.

    1. Re:New Timing Attack by cryptizard · · Score: 2

      Well its a theoretical attack against TLS because you can restart the connection and currently browsers will use the same parameters if you have a certain cookie set, giving you a chance to try again. It takes millions of tries though and each TLS handshake is rather slow so it isn't currently possible to use this attack on TLS even under the best conditions.

  7. So... by fahrbot-bot · · Score: 1

    ...Firefox 18.0.3 in 3...2...1... (sigh)

    --
    It must have been something you assimilated. . . .
  8. Since CBC is discouraged after the BEAST attack by Chrisq · · Score: 1

    Since the use of CBC-based cipher suites in TLS is discouraged since BEAST attacks this is just adding more weight to the argument.

    1. Re:Since CBC is discouraged after the BEAST attack by WaffleMonster · · Score: 1

      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?

  9. Re:Workaround for the Cheap, Lazy, and/or Incompet by ewanm89 · · Score: 1

    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.

  10. Re:RIP Internet by sycodon · · Score: 1

    Don't worry, we have "Researchers" on it. Top "Researchers".

    --
    When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
  11. The world has gone insane by stilnesv · · Score: 1

    Once upon a time, these tax leaching researchers with Asperger's syndrome were tucked away in their dungeons. Unfortunately, someone let them out and they are now screaming loud. Don't be fooled by their screaming.