Freelance journalist (Golem.de, Zeit Online, taz, LWN)
Find and fix security vulnerabilities and bugs in free software (Fuzzing Project, supported by Linux Foundation's Core Infrastructure Initiative)
Monthly Bulletproof TLS Newsletter
1994: SSL v2
1995: SSL v3
1999: TLS v1.0
2006: TLS v1.1
2008: TLS v1.2
Soon: TLS v1.3
SSL is just the old name of TLS
BEAST (2011), CRIME (2012), BREACH (2013), Lucky Thirteen (2013), RC4 attacks on TLS (2013), goto fail (2014), Heartbleed (2014), CCS Injection (2014), Triple Handshake (2014), BERserk (2014), POODLE (2014), SMACK/FREAK/SKIP-TLS (2015), Logjam (2015), MACE (2015), Invalid Curve attacks (2015), RSA-CRT (2015), Bar Mitzvah (2016), DROWN (2016)
|Rivest: DSA weakness (1992)||Playstation 3 broken (2010), Mining Ps and Qs (2012)|
|Dobbertin: MD5 weak (1996), Wang: MD5 collission, SHA1 weak (2004/2005)||MD5 CA attack (2008), Flame (2012), SLOTH (2016)|
|Lenstra: RSA-CRT weakness (1996)||RSA-CRT attack (2015)|
|Bleichenbacher: Million Message attack (1998)||DROWN (2016)|
|Biehl: Fault attacks on ECC (2000)||Invalid curve attacks (2015)|
|Fluhrer/McGrew: RC4 biases (2000)||RC4 TLS attacks (2013-2016), Bar Mitzvah (2016)|
|Vaudenay: Padding Oracle (2002)||Lucky Thirteen (2013)|
|Bard: Implicit IV vuln (2004)||BEAST (2011)|
|Bleichenbacher: Signature forgery (2004)||BERserk (2014)|
"Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...", Vaudenay (Eurocrypt 2002)
TLS: Encryption and Authentication
TLS usually used AES in CBC mode plus HMAC for authenticity
0x02, 0x02, 0x02
0x03, 0x03, 0x03, 0x03
Always send the same error message.
decryption_failed error MUST NOT be sent (TLS 1.2).
This was in 2002. Surely everyone has fixed this, right?
Calculating a MAC takes more time than just checking a Padding.
"Password Interception in a SSL/TLS Channel", Canvel, Hiltgen, Vaudenay, Vuagnoux (Crypto 2003)
"In order to defend against this attack, implementations MUST ensure that record processing time is essentially the same whether or not the padding is correct. [...] 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, 2008)
TLS 1.2 says you should fix timing and proposes a method. Then it tells you that it doesn't really fix timing.
SSH used MAC-and-Encrypt instead of MAC-and-Encrypt.
"Plaintext Recovery Attacks Against SSH", Albrecht, Paterson, Watson (IEEE Symposium on Security and Privacy 2009)
Very similar attack using encoding errors.
"How to Break XML Encryption", Jager, Somorovsky (CCS 2011)
You remember that small, non-exploitable timing sidechannel?
Today we call it Lucky Thirteen (AlFardan, Paterson, 2013).
Countermeasures to Lucky Thirteen are complicated.
Amazon's s2n library implemented countermeasures that don't work (Lucky Microseconds, 2016)
Some implementations are vulnerable and don't want to fix it (Go, TLS Lite).
OpenSSL introduced a more severe padding oracle while fixing Lucky Thirteen (found by Juraj Somorovsky with TLS-Attacker).
"If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom." Moxie Marlinspike (2011)
2000: Biases in RC4 by Fluhrer, McGrew
2013: Attack on RC in TLS by AlFardan, Bernstein, Paterson, Poettering, Schuldt
2015: Improved attack on IMAP and BasicAuth by Garman, Paterson, van der Merwe
2015: Bar Mitzvah attack by Mantin
2015: RC4 NOMORE by Vanhoef, Piessens
2015: RFC 7465, Prohibiting RC4 Cipher Suites
The real solution is Authenticated Encryption.
Rationale: Combining encryption and authentication is error prone, so let's have standardized cipher modes that combine both.
For TLS: AES-GCM (soon ChaCha20-Poly1305).
Authenticated encryption would've avoided:
Applied Cryptography is certainly one of the most influential cryptography books.
But it's from 1996. We have moved on.
GCM and Poly1305 aren't the end of the debate.
Especially with GCM there are a lot of concerns about fragility.
Future: CAESAR-competition, Synthetic IVs
GCM needs a nonce value.
If one uses the same nonce and key twice everything falls appart.
Vulnerable implementations exist, details soon.
Client: "Dear server, I support versions between SSLv3 and TLSv1.2"
Server: "Okay, let's use TLSv1.0"
Client: "Dear server, I support versions between SSLv3 and TLSv1.2"
Server thinks: "I never heard of TLSv1.2... Maybe I better say nothing at all..."
Version intolerance (this is always a server bug)
Browser tries to connect with SSLv3 to TLSv1.2.
No answer? Browser retries with SSLv3 to TLsv1.1.
Retries all supported versions.
Behavior has been called "Protocol Dance".
Antoine Delignat-Lavaud presents Virtual Host Confusion attack.
Padding Oracle On Downgraded Legacy Encryption
Another Padding Oracle that only works against SSLv3.
Good for the attacker: We can downgrade users.
SCSV (RFC 7507): Server signals browser that it is not broken.
Some F5 load balancers fail with handshakes between 256 and 512 bytes.
Solution: If your handshake is bigger than 256 bytes pad it to be bigger than 512 bytes.
TLS Padding Extension (RFC 7685).
There are other TLS implementations that fail with handshakes bigger than 512 bytes (Cisco Ironport).
Cryptography is based on mathematics.
What if our math functions produce wrong results?
Bug in BN_sqr() function of OpenSSL.
Produces wrong results in some cases.
CVE-2015-3193: bug in BN_mod_exp() / OpenSSL
CVE-2016-1938: bug in mp_div()/mp_exptmod() / NSS
CVE-2015-8803/CVE-2015-8804: Bugs in elliptic curve multiplications / Nettle
Recently: Several bugs in Poly1305 / OpenSSL
Usually carry propagation bugs
We deprecated SSLv2, SSLv3, RC4, SHA1 signatures.
In 2010 Nokia/Microsoft produced highend phones with a mail client that only supports SSLv3.
POODLE: Mail providers disabled SSLv3. Microsoft refuses to deliver a fix.
Something similiar happened with AVM Fritz!Box.
At some point we want to deprecate CBC/HMAC and all those Padding Oracles (everything before TLS 1.2).
Right now Apple Mail only supports TLS 1.0.
Large players (Google, Mozilla, Let's Encrypt) push for HTTPS by default.
This is a good thing.
But there is pushback.
"I don't need HTTPS, there's nothing secret on my web page."
Remember: TLS is Encryption and Authentication.
"I encrypt the login, that's enough."
Wrong: Your form can be attacked (SSL Stripping).
"TLS is too slow and will cause too much load on my servers."
People tend to vastly overestimate the computational costs of crypto. In most scenarios it's irrelevant and hardly measuarble.
"The Certificate Authorities are corrupt and can be attacked, therefore TLS is pointless."
Problems are real (Diginotar, Comodo, CNNIC, Symantec).
But situation is improving: Baseline Requirements and new technologies.
Web page can indicate that browser should pin certificate (and backup certificates).
Adds trust on first use to certificates.
Warning: Has the potential to "shoot yourself into the foot".
Publicly verifiable append-only logs.
Idea: Have full transparency over certificate issuances.
It works (several misbehaving CAs found, incuding larger incident with Symantec).
Many web pages use content outside of their control (which is a security risk by itself).
Major issue: Advertisement.
TLS 1.3 will deprecate a lot of problematic stuff: