Padding oracle attacks have been known for over a decade. They involve an attacker capturing an encrypted record while in transit, altering certain parts of it, submitting it to the server and monitoring how long it takes for the server to fail the decryption attempt. By adapting his modifications and analyzing the time differences between many decryption attempts, the attacker can eventually recover the original plaintext byte by byte.
The TLS designers attempted to block such attacks in version 1.2 of the TLS specification, by reducing the timing variations to a level they thought would be too low to be exploitable. However, the Lucky Thirteen research from AlFardan and Paterson shows that this assumption was incorrect and that successful padding oracle attacks are still possible.
"The new AlFardan and Paterson result shows that it is indeed possible to distinguish the tiny timing differential caused by invalid padding, at least from a relatively close distance -- e.g., over a LAN," Matthew Green, a cryptographer and research professor at Johns Hopkins University in Baltimore, Maryland, said Monday in a blog post. "This is partly due to advances in computing hardware: most new computers now ship with an easily accessible CPU cycle counter. But it's also thanks to some clever statistical techniques that use many samples to smooth out and overcome the jitter and noise of a network connection."
In addition to being in close proximity to the targeted server, a successful Lucky Thirteen attack would also require a very high number -- millions -- of attempts in order to gather enough data to perform relevant statistical analysis of the timing differences and overcome network noise that might interfere with the process.
The secret plaintext targeted for decryption needs to have a fixed position in the HTTPS stream. This condition is met by authentication (session) cookies -- small strings of random text stored by websites in browsers to remember logged-in users. An authentication cookie can give the attacker access to the user's account on its corresponding website, making it a valuable piece of information worth stealing.
However, the biggest hurdle to be overcome by potential attackers is the fact that TLS kills the session after each failed decryption attempt, so the session needs to be renegotiated with the server. "TLS handshakes aren't fast, and this attack can take tens of thousands (or millions!) of connections per [recovered] byte," Green said. "So in practice the TLS attack would probably take days. In other words: don't panic."