Part 5
Misc stuff that didn't fit elsewhere

Functions with limitations

MatrixSSL

The pstm_exptmod function not only produced wrong results, it also didn't accept zero as the base input.

Instead it crashed.

Modular exponentiation of zero never happens in real-world cryptographic applications.

Therefore no problem?

Attackers don't have to play by the rules.

RSA decryption:

What if...

... a client sends zero as the encrypted pre-master secred in a TLS handshake?

It crashes with a double free error.

A change in Nettle

Nettle is the cryptographic library underlying GnuTLS.

Nettle Git

GMP

Function: void mpz_powm_sec (...)
Set rop to (base raised to exp) modulo mod.

It is required that exp > 0 and that mod is odd.

Requires odd modulus

Modulus is usually either a prime (Diffie Hellman, ECC) or the product of two primes (RSA).

So an even modulus never happens.

At least if everyone plays by the rules.

Nettle only used these for private key operations.

It would've been possible to create a faulty private key that'd crash applications using Nettle.

Impact is limited, but this is still undesirable.

mbedtls

Modular exponentiation is documented to reject even inputs.

Doesn't crash, returns an error. May be worth looking at in more detail.

Conclusion

• Restricting mathematical functions to certain inputs can be risky and requires very careful evaluation of the consequences.
• It should probably be avoided.
• I'm not aware of any detailed research on this./li>

The key matching problem

Given a public and a private key how do you check if they belong together?

Why does this matter?

Sometimes people upload their private keys to the public Internet.

Let's talk about RSA keys

Keys are just large numbers

Public and Private Keys (RSA)

• Public key: N, e
• Private key: N, e, d, p, q, d_P, d_Q, q_inv

Frankenkey

With such a fake key we could convince a certificate authority to revoke someone else's certificate.

Nobody would fall for such a stupid trick, right?

I found dozends of guides how to check whether a certificate matches a private key.

The vast majority were wrong. Many came from seemingly trustable sources (Universities, Certificate Authorities).

Don't trust the Internet

Optional part if there's time

Additional TLS failures

Handshake size

With new extensions and ciphers the TLS handshake grew.

F5 load balancers couldn't handle handshakes larger than 256 bytes.

"If you use F5/BIG-IP devices to terminate SSL connections, please update the firmware on the things! We're trying to run an Internet here and old versions of these devices are a real problem for deploying new TLS features." (Adam Langley, 2013)

F5 handshake problem

It turned out 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).

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

ClientHello: "Dear server, the maximum version I support is 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

Known at least since 2003.

What browsers did

Browser tries to connect with TLSv1.2.

No answer? Browser retries with TLsv1.1, TLSv1.0, SSLv3.

Retries all supported versions.

Behavior has been called "Protocol Dance".

The SNI bug

Sometimes bad internet connections caused downgrade from TLSv1.0 to SSLv3 (1.1/1.2 wasn't implemented yet).

SSLv3 does not support SNI - therefore wrong certificate.

My server was behaving fine - but Mozilla refused to fix it, because they wanted to retain compatibility with broken servers.

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.

But what about TLS 1.3?

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

TLS 1.3 new version negotiation

Old version field gets deprecated.

List of versions in an extension.

Caveat: Instead of two version numbers from which one is useless we'd then have three version numbers from which two are useless.

GREASE

GREASE (Generate Random Extensions And Sustain Extensibility), proposal by David Benjamin (Google).

Reserve garbage values for version numbers (and ciphers, extensions, ...) that get sent ocassionally to make sure implementations don't mess things up too badly.

GREASE paradigm

Design new protocols in a way that they can get deployed despite a broken ecosystem.

Create protocols that are hard to mess up.

TLS 1.3 deployment problem

The high-order bit is that *negotiating* TLS 1.3 seems to cause increased failures with a variety of middleboxes (it’s generally safe to offer TLS 1.3 to servers which don’t support it). The measured incremental error rates vary quite a bit, ranging from minimal (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome)." (Eric Rescorla on TLS mailing list)

Details yet unclear

Wrapping up

Part 1 was called "Bleichenbacher's first Zombie".

You may have wondered about Bleichenbacher's second Zombie.

Bleichenbacher RSA signature forgery vulnerability from 2004.

Variation BERserk re-discovered in 2014 in NSS.

Are there more vulnerable implementations out there?

I haven't checked.

Remember:
Every imaginable TLS implementation flaw can be found in the wild

Want to find cool attacks against TLS implementations and publish a paper?

Step 1

Find something in TLS that can go wrong. (Recycling old attacks is fine and works very well.)

Step 2

Find vulnerable implementations, for example with Internet-wide scans.

Step 3

This is your Homework.

Send me a link when you're done.