Nonce reuse issues in TLS

Hanno Böck

Who am I?

Hanno Böck

Freelance journalist (, Zeit Online, taz, LWN, Bulletproof TLS Newsletter)

Started Fuzzing Project November 2014

Since May 2015: Supported by Linux Foundation's Core Infrastructure Initiative

TLS encryption

Step 1: Asymmetric key exchange (RSA, DHE, ECDHE) to generate shared keys

Step 2: Symmetric encryption and authentication

Today we're interested in Step 2.

TLS ciphers





Vaudenay Padding Oracle (2002), Vaudenay/Moeller (2003/2004), BEAST (2011), Lucky Thirteen (2013), POODLE (2014), POODLE-TLS (2014), more POODLEs (2015), Lucky Microseconds (2015), Padding Oracle in OpenSSL / CVE-2016-2107

CBC/HMAC problems

CBC/HMAC in TLS used an implicit IV in TLS 1.0.

The padding content in SSLv3 was undefined.

All TLS versions use MAC-then-Pad-then-Encrypt.

There's a Encrypt-then-MAC extension, but it's rarely used.

TLS 1.2 predicts Lucky Thirteen

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. (TLS 1.2, RFC 5246)

Lucky thirteen is a big mess

Amazon tried to implement countermeasures that didn't work.

Some implementations (Go, TLS Lite) are known vulnerable and don't want to fix it.

OpenSSL introduced another (worse) padding oracle while fixing Lucky Thirteen.


After Lucky Thirteen many sites switched to RC4.

Fluhrer/Shamir/Mantin (2001), attack on TLS by AlFardan/Bernstein/Patterson (2013), Bar-Mitzva-Attack/Mantin (2015), Garman/va der Merwe/Paterson (2015), Vanhoef/Piessens (2015).

RFC 7465: "Prohibiting RC4 Cipher Suites"

What's left?

If CBC/HMAC and RC4 are bad there's only one cipher mode left: AES-GCM (Galois/Counter Mode).

(or Camellia-GCM or CCM, but nobody uses or implements those)

GCM is only available in TLS 1.2.

"This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken." (Adam Langley)

What is GCM?

GCM is an AEAD (Authenticated Encryption with Additional Data)

Rationale: If you give people an encryption mode and an authentication mechanism they will combine it in an insecure way. So give them a standard that combines both.

GCM is a combination of Counter Mode and a GHASH authentication tag.

GCM - opinions

"Do not use GCM. Consider using one of the other authenticated encryption modes, such as CWC, OCB, or CCM." (Niels Ferguson)

"We conclude that common implementations of GCM are potentially vulnerable to authentication key recovery via cache timing attacks." (Emilia Käsper, Peter Schwabe, 2009)

"AES-GCM so easily leads to timing side-channels that I'd like to put it into Room 101." (Adam Langley, 2013)

"The fragility of AES-GCM authentication algorithm" (Shay Gueron, Vlad Krasnov, 2013)

"GCM is extremely fragile" (Kenny Paterson, 2015)


Everybody uses GCM, but nobody likes it.

"There's also an annoying niggle with AES-GCM in TLS because the spec says that records have an eight byte, explicit nonce. Being an AEAD, the nonce is required to be unique for a given key. Since an eight-byte value is too small to pick at random with a sufficiently low collision probability, the only safe implementation is a counter. [...] Thankfully, all the major implementations use a counter and I did a scan of the Alexa, top 200K sites to check that none are using random values - and none are." (Adam Langley)


Number used once.

If you use the same Nonce twice (with the same key) it's no longer a nonce.

The Forbidden Attack

Described by Joux during NIST GCM standardization (2006).

Repeating nonce: Attacker can learn authentication key (with high probability).

Galois/Counter Mode becomes unauthenticated Counter Mode.

XORing encrypted data is possible, can be used for XSS.

Internet-wide scan

184 hosts with repeating nonces

72445 hosts with random looking nonces

Tracking them down

Rule of thumb: If you contact random people on the Internet about security issues they usually don't answer.

We were able to identify products from Radware (duplicate nonce), A10, IBM, Sangfor (random nonces).

There are vulnerable devices out there that we could not identify.

What's this?


OpenSSL 1.0.1j


		EVP_CipherInit_ex(dd,c,NULL,key,NULL,(which & SSL3_CC_WRITE));

e_aes.c (EVP_CIPHER_CTX_ctrl/aes_gcm_ctrl):

		if (c->encrypt &&
			RAND_bytes(gctx->iv + arg, gctx->ivlen - arg) <= 0)
			return 0;


TLS 1.2 tells implementors to use a nonce, but gives no guidance how to do that properly.

Some people get it wrong.


Draft for Chacha20/Poly1305 and TLS 1.3 uses fully implicit nonce based on record number.

Synthetic IV (Rogaway, 2007) - cipher modes that generate a secure nonce by themselve.

Further notes

Carry propagation bugs lately in OpenSSL (BN_mod_exp, Poly1305), NSS (mp_div, mp_exptmod), Nettle (ECC multiplications).

GCM and Poly1305 use a polynomial hashes, may be considered fragile.

Should we consider less fragile constructions for authentication functions?

Implementation bugs

Failure to properly decode signatures (Bleichenbacher signature forgery, BERserk)

Failure to check Padding (POODLE-TLS)

Failure to check MAC/Finished Message (MACE)

Failure to check length (last OpenSSL padding oracle)

We need better and more widespread testing of these issues

Thanks for listening

Paper will be published soon