TLS 1.3 and Version Intolerance
How Enterprise vendors cause breakage on the Internet.
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.
TLS 1.3
TLS 1.3 deprecations
TLS 1.3 deprecates a lot of dangerous constructions.
- CBC/HMAC, all non-AEADs
- RC4
- MD5, SHA-1
- RSA key exchange without forward secrecy
- RSA PKCS #1 1.5
TLS 1.3 news
TLS 1.3 also introduces new dangerous constructions, because we want to have interesting attacks in the future.
- 0-RTT
Version number
TLS 1.3 introduces a new version number: 3.4 (you know, because ...)
Some debates whether to call it TLS 1.3, 2.0 or 4.0. But the version number on the wire will still be 3.4.
We also have a Record Version number that has no meaning at all.
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 SSLv3 to TLSv1.2.
No answer? Browser retries with SSLv3 to TLsv1.1.
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
- We have a version negotiation mechanism
- Servers have broken TLS implementations.
- Browsers implement workaround.
- Workaround introduces security issue.
- 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?
TLS 1.3
"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
Testing for version intolerance
SSLLabs, testssl.sh (both incomplete).
Safest way: Get Chrome Canary, enable TLS 1.3 support.
Alternative
One could deprecate the Version Negotiation and use a TLS 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 extension identifiers that get sent ocassionally to make sure implementations don't mess things up too badly.