TLS

The most important cryptographic protocol on the Internet

Hanno Böck
https://hboeck.de/

Who am I?

Hanno Böck

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

We use TLS all the time

TLS matters

SSL versus TLS

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

Recent Attacks

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)

Attacks have a history

Example: Padding Oracle

"Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...", Vaudenay (Eurocrypt 2002)

Background CBC/HMAC

TLS: Encryption and Authentication

TLS usually used AES in CBC mode plus HMAC for authenticity

MAC-then-Pad-then-Encrypt

([Plaintext][MAC][Padding])Encrypt

TLS Padding

0x00

0x01, 0x01

0x02, 0x02, 0x02

0x03, 0x03, 0x03, 0x03

TLS 1.0 / 1.1 Error alerts

CBC Decryption

CBC Padding Oracle

First Solution

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?

Timing

Calculating a MAC takes more time than just checking a Padding.

"Password Interception in a SSL/TLS Channel", Canvel, Hiltgen, Vaudenay, Vuagnoux (Crypto 2003)

Let's fix timing (sort of)

"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.

There's also SSH

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)

XML also has oracles

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).

Lucky Thirteen is a bloody mess

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).

The Cryptographic Doom Principle

"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)

RC4

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

Authenticated Encryption

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).

Always use Authenticated Encryption

Authenticated encryption would've avoided:

• All symmetric padding oracles
• Recent iMessage attack (CVE-2016-1788)
• Recent Owncloud encryption module vulnerability

Why aren't people following that advice?

ECB, CBC, CFB, OFB, CTR

Applied Cryptography is certainly one of the most influential cryptography books.

But it's from 1996. We have moved on.

ECB, CBC, OFB, CTR

Authenticated Encryption

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 Nonce reuse

GCM needs a nonce value.

If one uses the same nonce and key twice everything falls appart.

Vulnerable implementations exist, details soon.

TLS implementation bugs

Downgrades

SSL/TLS versions during handshake

Client: "Dear server, I support versions between SSLv3 and TLSv1.2"

Server: "Okay, let's use TLSv1.0"

But sometimes...

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)

What browsers did

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".

Black Hat 2014

Antoine Delignat-Lavaud presents Virtual Host Confusion attack.

POODLE (2014)

Padding Oracle On Downgraded Legacy Encryption

Another Padding Oracle that only works against SSLv3.

Good for the attacker: We can downgrade users.

Solution

SCSV (RFC 7507): Server signals browser that it is not broken.

Protocol dance and SCSV

1. We have a version negotiation mechanism
2. Servers have broken TLS implementations.
3. Browsers implement workaround.
4. Workaround introduces security issue.
5. Workaround for security issue introduced by workaround gets standardized.

Not the only one

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).

And then...

There are other TLS implementations that fail with handshakes bigger than 512 bytes (Cisco Ironport).

Math

Cryptography is based on mathematics.

What if our math functions produce wrong results?

CVE-2014-3570

Bug in BN_sqr() function of OpenSSL.

Produces wrong results in some cases.

Differential fuzz-testing

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

Other implementation issues

• Parser errors during RSA verification (Bleichenbacher signature forgery, BERserk)
• Implementations don't check correct padding (POODLE-TLS).
• Implementations miss some bytes of padding (more Poodles in the Forest)
• Implementations don't check MAC or FinishedMessage (MACE)

Almost every imaginable TLS implementation flaw can be found in the wild.

Deprecation is hard

We deprecated SSLv2, SSLv3, RC4, SHA1 signatures.

It's painful.

Problematic vendors

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.

This is happening again

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.

TLS by default

Encrypt the Web

Large players (Google, Mozilla, Let's Encrypt) push for HTTPS by default.

This is a good thing.

But there is pushback.

HTTPS myths

"I don't need HTTPS, there's nothing secret on my web page."

Remember: TLS is Encryption and Authentication.

Login only

"I encrypt the login, that's enough."

Wrong: Your form can be attacked (SSL Stripping).

Performance

"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.

Certificate Authorities

"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.

HTTP Public Key Pinning (HPKP)

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".

Certificate Transparency

Publicly verifiable append-only logs.

Idea: Have full transparency over certificate issuances.

It works (several misbehaving CAs found, incuding larger incident with Symantec).

Real problem: Third Party Content

Many web pages use content outside of their control (which is a security risk by itself).

Major issue: Advertisement.

TLS Future

TLS 1.3 is coming

TLS 1.3 will deprecate a lot of problematic stuff:

• RSA handshake (no forward secrecy, Bleichenbacher attacks)
• Unauthenticated encryption modes, CBC/HMAC, MAC-then-Encrypt
• Old RSA mode (PKCS #1 1.5)
• Weak hashes (MD5, SHA1)

Problems remain

• Will we see new version intolerance issues with TLS 1.3?
• Cross-protocol attacks can keep old weaknesses.

Conclusions

• TLS is becoming the default.
• There's been a lot more research recently.
• Old attacks keep coming back.
• Better testing needed for implementation flaws.

Thanks for listening