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.
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.
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.
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.
The TLS RFC (5246) specifically states that this exists:
This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.
So I guess you're right, they're just showing that a known theoretical attack is not quite as theoretical as thought.
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.
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.
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.
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.