

"Lucky Thirteen" attack snarfs cookies protected by SSL encryption - dsr12
http://arstechnica.com/security/2013/02/lucky-thirteen-attack-snarfs-cookies-protected-by-ssl-encryption/

======
moxie
This is an entirely theoretical attack, and is an extension of a known
(practical) attack that was published by Vaudenay back in 2002.

Vaudenay pointed out that using CBC-mode in the "authenticate-then-encrypt"
paradigm was dangerous, because CBC's padding would not be covered by the TLS
record's MAC. An attacker could modify the padding in transit, and since it
wasn't covered by the MAC, the server would respond differently to padding
errors and MAC errors. Through a few clever techniques that Vaudenay
demonstrated, this could (very practically) be used for full plaintext
recovery.

TLS implementations responded by removing TLS alerts that differentiated
between padding and MAC errors, as well as calculating the MAC on a message
that had already encountered a padding error anyway, in order to eliminate
timing attacks to differentiate between the two cases.

What the authors of this paper have done is to demonstrate that in hyper-
controlled network environments with incredibly low latency paths (a client
and server engaging in TLS requests on the same uncongested wired LAN with
zero interference, for instance), it is still possible to discern some slight
timing differences between the padding failure case and the MAC failure case.

This is an interesting result for academia and for those who are deeply
invested in the overall narrative of TLS. But ultimately, the conditions
necessary for this type attack are not generally realistic, and I don't
believe it should be characterized as a real risk.

~~~
qeorge
I'm completely overwhelmed by security topics, so please pardon this stupid
question. But could you expound on this part:

 _But ultimately, the conditions necessary for this type attack are not
generally realistic, and I don't believe it should be characterized as a real
risk._

Shouldn't it be possible to factor out the network jitters? I'm reminded of
this post by Nate Lawson about Keyczar.

[http://rdist.root.org/2009/05/28/timing-attack-in-google-
key...](http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-
library/)

Is this attack unrealistic because taking enough samples to factor out the
jitters would be very obvious to an administrator? Or is it exceedingly
unlikely that a public network will ever have low enough latency to perform
this sort of timing attack on this particular vector? Or am I misunderstanding
your point entirely?

I really appreciate your taking the time to explain this stuff to people like
me! Its fascinating.

~~~
BCM43
If I understand both correctly, the issue with network jitters is you need a
large number of samples for each packet from which you are trying to get
timing information. This causes the total samples to increase to less
obtainable numbers.

------
JoachimSchipper
Also see: <https://news.ycombinator.com/item?id=5163696>.

------
meaty
_It took the scientists as little 2^23 sessions to extract the entire contents
of a TLS session cookie_

That's half a million sessions. I think an attack is possibly unlikely.

~~~
MichaelGG
It's over 8M sessions, but some variations mentioned in the article require
less. I don't see why that's unlikely given system speeds and high bandwidth
connections.

------
aidenn0
IF it's a padding oracle, then rc4 should be immune, right?

~~~
lucian1900
Yes, but RC4 should still not be used.

~~~
xyzzy123
Since prioritising RC4 is the mitigation for the BEAST attack as well (IMHO a
rather impractical attack on SSL, but that's another story) it's going to be
the default on a lot of servers already.

You'll find that Google, Facebook and Microsoft servers all prefer RC4 during
SSL negotiation.

See: <https://www.ssllabs.com/>

    
    
      TLS_RSA_WITH_RC4_128_MD5 - www.microsoft.com
      TLS_RSA_WITH_RC4_128_SHA - www.facebook.com
      TLS_ECDHE_RSA_WITH_RC4_128_SHA - www.google.com
    

In most circumstances I would consider AES a "better" cipher than RC4, but
it's interesting there are now multiple attacks where block boundaries matter.

~~~
moxie
Most organizations were already prioritizing RC4 before that, simply because
it's fast (23 in order instructions per byte!).

