Search...

Researchers Attack TLS, DTLS Protocol Vulnerability

Researchers Attack TLS, DTLS Protocol Vulnerability

Two researchers have uncovered a new vulnerability in the Transport Layer Security (TLS) and Datagram TLS (DTLS) protocols that allow attackers to recover plaintext from a TLS/DTLS connection when CBC-mode encryption is used.

The attack would allow hackers to circumvent the protection the protocols are supposed to provide. This is not the first time researchers have poked holes in TLS; in 2011, researchers introduced BEAST, a tool that attacked TLS and the SSL (secure sockets layer) protocols. In this case, the Kenny Paterson - a professor at Royal Holloway, University of London – and PhD student Nadhem AlFardan tested their attack against OpenSSL and GnuTLS and discovered that either a full or partial plaintext recovery attack was possible.

"The attacks arise from a flaw in the TLS specification rather than as a bug in specific implementations," the researchers stated in a web post. "We have carried out experiments to demonstrate the feasibility of the attacks against the OpenSSL and GnuTLS implementations of TLS, and we have studied the source code of other implementations to determine whether they are likely to be vulnerable. There are effective countermeasures against our attacks and we have worked with a number of TLS and DTLS software developers to prepare patches and security advisories."

Describing their attack as similar to an advanced form of Oracle padding, the researchers noted that for TLS, the attacks are multi-session attacks that require the target plaintext to be repeatedly sent in the same position in the plaintext stream in multiple TLS sessions.

"The attacks involve detecting small differences in the time at which TLS error messages appear on the network in response to attacker-generated ciphertexts," according to the researchers. "Because of network jitter and other effects, the times observed by the attacker are noisy, and multiple samples of each time are needed to make the attacks reliable. In their simplest form, our attacks can reliably recover a complete block of TLS-encrypted plaintext using about 223 TLS sessions, assuming the attacker is located on the same LAN as the machine being attacked and HMAC-SHA1 is used as TLS's MAC algorithm."

"This can be reduced to 219 TLS sessions if the plaintext is known to be base64 encoded. This can be further reduced to 213 sessions per byte if a byte of plaintext in one of the last two positions in a block is already known. The attack complexities are different for different MAC algorithms," the researchers noted.

The researchers published a number of mitigations, such as switching to AEAD ciphersuites such as AES-GCM or modifying TLS' CBC-mode decryption procedure to remove the timing side channel. OpenSSL, NSS, GnuTLS, yaSSL, PolarSSL, Opera, and BouncyCastle are all preparing patches to address the issue, and the researchers have notified Apple, Microsoft and other vendors of their findings as well.

“Unlike other recent attacks, such as BEAST, Lucky 13 requires a server-side fix," said Ryan Hurst, CTO at certificate authority GlobalSign. "This means that complete and effective protection against this attack will require all Web servers to be updated or patched.”

“Should you be worried? It depends. If you are using TLS (and not its little brother DTLS) I would say your best bet is to walk calmly to the nearest exit, and use this as an excuse to ensure you are following industry Best Practices when deploying SSL – if you’re not, this attack is the least of your worries," said Hurst.

According to the researchers, the attacks can only be carried out by a determined attacker who is located close to the machine being attacked and who can generate sufficient sessions for the attacks.

"In this sense, the attacks do not pose a significant danger to ordinary users of TLS in their current form," the researchers noted. "However, it is a truism that attacks only get better with time, and we cannot anticipate what improvements to our attacks, or entirely new attacks, may yet to be discovered."

Source: SecurityWeek

© 2011-2024 All rights reserved