Slashdot Mirror


Researchers Devise New Attack Techniques Against SSL

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

33 comments

  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!

    4. Re:Could this be the NSA's secret crack? by Anonymous Coward · · Score: 0

      Yes, the NSA has broken AES

      You convinced me. I'm now preparing to foil my network ports with aluminum foil I found my mothers kitchen closet. The machine will be air-tight, although not the DP+oral kind of way

    5. Re:Could this be the NSA's secret crack? by Anonymous Coward · · Score: 0

      “They were thinking that this computing breakthrough was going to give them the ability to crack current public encryption."
      Presumably he means public-KEY encryption, most likely RSA. In other words, the NSA found a faster way to factor prime numbers, which is quite likely. Definitely more likely than "they broke AES."

  2. RIP Internet by Anonymous Coward · · Score: 0

    At what point will the Internet cease being a useful tool, because it is insecure?
    The criminal won't relent and the software meant to protect is never completely secure.

    1. Re:RIP Internet by YodasEvilTwin · · Score: 2

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

    2. 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.
  3. 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.

  4. Break the internet by puddingebola · · Score: 0

    Maybe they can break the internet (tee-hee hee). Maybe they can split it open, and make all the information inside it come tumbling, gushing out.

    1. Re:Break the internet by Anonymous Coward · · Score: 0

      Maybe they can break the internet (tee-hee hee). Maybe they can split it open, and make all the information inside it come tumbling, gushing out.

      It could cause all those series of tubes to burst.

  5. 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
  6. 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

    1. Re:ASLR for HTTP headers? by Anonymous Coward · · Score: 0

      That's just not practical, but I've also been thinking about this issue for a while (repeating text in SSL). I was thinking about adding a bit of random junk at the beginning of the transfer and encrypting the data with a very dumb (read: fast) method that contained the key in the transfer header (after the junk). So each transaction - after the handshake - would look like this:

      Here are a few bits of random data. Here's an (say) XOR key. Here's the data encrypted with the XOR key.

      And ALL that encrypted with the standard encryption methods. That would avoid repeating text.

    2. Re:ASLR for HTTP headers? by Anonymous Coward · · Score: 0

      That's more or less what modern on-disk crypto looks like already. You split the encryption key into two halves: The first half is used to encrypt the block index number. That gets xor'd with the data and the result is encrypted with the second half of the key. So if two blocks of data happen to be identical, they will look different on the disk.

      I always assumed that something similar were done for SSL streams, like you suggest. Guess I should study more.

  7. 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 Anonymous Coward · · Score: 0

      The summary says it also applies to TLS?

    2. Re:New Timing Attack by Anonymous Coward · · Score: 0

      a nice one!!! way to go and congratulations to Nadhem J. AlFardan and Kenneth G. Paterson (:

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

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

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

    --
    It must have been something you assimilated. . . .
  9. Re:On the internet, nothing is private by Anonymous Coward · · Score: 0

    So your secretary just took diction and posted this for you?
    Lazy fuck.

  10. 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 Anonymous Coward · · Score: 0

      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!

    2. 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?

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

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

  13. Re:Sexist language is dead? by Anonymous Coward · · Score: 0

    The women, who had no vagina's and instead had penises, published a research paper...

    Happy now?