"Lucky Thirteen" attack snarfs cookies protected by SSL encryption

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.

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