Hanno Böck
https://hboeck.de/
Hanno Böck
Freelance journalist (Golem.de, Zeit Online, taz, LWN, Bulletproof TLS Newsletter)
Started Fuzzing Project November 2014
Since May 2015: Supported by Linux Foundation's Core Infrastructure Initiative
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.
ECDHE-RSA-AES256-GCM-SHA384
DES-CBC3-MD5
RC4-SHA
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 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.
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)
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"
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)
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.
"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.
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.
184 hosts with repeating nonces
72445 hosts with random looking nonces
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.
0100000003001741 0100000003001741 f118cd0fa6ff5a15 f118cd0fa6ff5a16 f118cd0fa6ff5a74
t1_enc.c:
if (EVP_CIPHER_mode(c) == EVP_CIPH_GCM_MODE)
{
EVP_CipherInit_ex(dd,c,NULL,key,NULL,(which & SSL3_CC_WRITE));
EVP_CIPHER_CTX_ctrl(dd, EVP_CTRL_GCM_SET_IV_FIXED, k, iv);
}
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.
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?
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
Paper will be published soon