TLS

The burden of faulty and outdated TLS implementations

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

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 (2015), DROWN (2016)

Attacks have a history

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)
Joux: Forbidden attack on GCM (2004)Nonce-disrespecting Adversaries (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

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

Version intolerance (this is always a server bug)

Also...

Client tries to connect with highest version TLSv1.2 - Server wants SSLv3

Client tries to connect with highest version TLSv1.0 - Server will use TLSv1.0

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

By now most browser downgrades have been removed.

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

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

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)

Zero-length extension

Servers reject connection if last extension has zero length (WebSphere Application Server).

Implementations now try intelligent ordering of extensions to avoid this.

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

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

All thanks to american fuzzy lop.

Bugs in calculations

Hard or impossible to test remotely.

Even testing without source tricky.

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

What can we do?

Testing

SSL labs test

SSLyze

testssl.sh

scapy-ssl_tls

tlsfuzzer

TLS-Attacker

Getting better, but none of them is satisfying.

Lack of thorough tests

We don't have a good TLS test suite.

Negative tests are important!

Identifying devices

Internet-wide scans can identify vulnerabilities.

How do we find vendor / product?

Security by obscurity hurts!

Use X-Forwarded-By header.

Conclusions

  • 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

Questions?
https://hboeck.de/