TLS

Attacks and the burden of faulty implementations

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

Introduction

Hanno Böck, freelance journalist and hacker.

Writing for Golem.de and others.

Fuzzing Project, funded by Linux Foundation's Core Infrastructure Initiative.

Author of monthly Bulletproof TLS Newsletter.

Trying to fix (parts of) TLS.

We use TLS all the time

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), Bar Mitzvah (2015), SMACK/FREAK/SKIP-TLS (2015), Logjam (2015), MACE (2015), Invalid Curve attacks (2015), RSA-CRT (2015), SLOTH (2016), DROWN (2016), Nonce disrespect (2016), SWEET32 (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.

OpenSSH also had Timing Oracle.

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 and 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

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.

TLS / GCM Nonces

TLS gives no good guidance how to select a nonce. A counter is secure.

Some implementations get it wrong: Duplicate nonces (Radware, Cavium, ...), random nonces (IBM, A10, Sangfor, ...).

"Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS", Böck, Zauner, Devlin, Somorovsky, Jovanovic (2016)

Deprecation is hard

We deprecated SSLv2, SSLv3, RC4, SHA1 signatures, small Diffie Hellman groups.

It's painful.

DROWN

2011: RFC 6176, Prohibiting SSLv2.

2016: DROWN, SSLv2 weakness, 33% vulnerable.

Logjam: Chrome disables weak Diffie Hellman

We could've known

512 bit RSA was broken in 1999.

768 bit RSA broken in 2010.

Cisco RV042G was released 2012.

Problematic vendors

2010: Nokia/Microsoft Lumia 800 phone with a mail client that only supports SSLv3. (Successor TLS 1.0 was published in 1999.)

POODLE: Mail providers disabled SSLv3. Microsoft refuses to deliver a fix.

(similar case with AVM Fritz!Box)

This is happening again

At some point we want to deprecate TLS 1.0/1.1 due to Padding Oracles.

2016: A lot of current software (including Apple Mail) only supports TLS 1.0.

Sub-standard crypto

Why is it acceptable that products come with sub-standard TLS crypto?

TLS implementation bugs

Downgrades

SSL/TLS versions during handshake

ClientHello: "Dear server, the maximum version I support is TLSv1.2"

ServerHello: "I don't support that new TLSv1.2 stuff, 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 or send an error..."

Version intolerance (this is always a server bug)

It's an old issue

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 or send an error..."

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.

Version intolerance

Issue was known and documented since at least 2003.

By now most browser downgrades have been removed.

And with TLS 1.3 the whole thing will happen again.

Version intolerance

"It's taken about 15 years to get to the point where web browsers don't have to work around broken version negotiation in TLS and that's mostly because we only have three active versions of TLS. When we try to add a fourth (TLS 1.3) in the next year, we'll have to add back the workaround, no doubt." Adam Langley (2016)

Vendors

IBM: "I expect both releases towards the end of the year as 8.5.5.10 and 9.0.0.1 are already at the tail end of their release processes.

Citrix: "Our investigation indicates that this is not a security issue. We also have this issue on our radar and plan to address it in an upcoming Citrix NetScaler version."

Cisco: "when it comes to devices or releases that have passed the last day of support (not the end of life), we can't do anything about them."

Site operators

apple.com: no reply

paypal.com: "SSL issues are out of scope for PayPal Bug Bounty Program"

ebay.com: no reply

Not the only handshake issue

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

Ommitting checks

TLS implementations should check various things to assure correctness of connection, like:

• Padding (since TLSv1.0)
• MAC / authentication tag
• FinishedMessage

POODLE TLS

The POODLE attack relies on the undefined padding of SSLv3 - TLSv1.0 defines padding.

Some implementations didn't check padding.

Affects F5, A10, Fortinet, Cisco, IBM, Juniper

"The POODLE bites again", Adam Langley (2014)

More POODLES

Maybe you check only some bytes of the padding?

Cisco (Cavium), Citrix, GnuTLS

"There are more POODLEs in the forest", Yngve Petterssen (2015)

MAC / FinishedMessage

MACE: Completely ommit MAC check (no authentication).

F5, Cisco, Fortinet

Don't check FinishedMessage (protects handshake).

F5, Juniper

"The POODLE has friends" (Pettersen, 2015)

RSA-CRT

CRT-optimization of RSA: Split private key signature operation into two calculations.

Dangerous: If one calculation produces wrong result this leaks the private key.

Citrix, Hillstone Networks, ZyXEL, Radware (all Cavium chip), Alteon/Nortel, Viprinet, QNO, BEJY

"Factoring RSA Keys With TLS Perfect Forward Secrecy", Florian Weimer (2015)

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

Lack of thorough tests

We don't have a good TLS test suite.

Negative tests are important!

Optional slides

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 (HPKP, CT).

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

• Version intolerance and other compatibility issues will come back with TLS 1.3.
• Cross-protocol attacks can keep old weaknesses.

Conclusions

• TLS is becoming the default.
• Old attacks keep coming back.
• Implementation bugs introduce security risks for themselve and for the ecosystem.
• Avoid reimplementing TLS.
• Vendors ship sub-standard TLS stacks - this is not acceptable.
• We need better test tools.

Thanks for listening