TLS 1.3 and Version Intolerance

How Enterprise vendors cause breakage on the Internet.

Hanno Böck


Hanno Böck, freelance journalist and hacker.

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


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.


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?

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)


IBM: "I expect both releases towards the end of the year as and 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 no reply "SSL issues are out of scope for PayPal Bug Bounty Program" no reply

Testing for version intolerance

SSLLabs, (both incomplete).

Safest way: Get Chrome Canary, enable TLS 1.3 support.


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

Thanks for listening