Subject: [TLS] Further TLS 1.3 deployment updates

From: David Benjamin <[email-masked]>
Date: Wed, 12 Dec 2018 16:21:43 -0600

Hi folks,

We have one more update for you all on TLS 1.3 deployment issues. Over the
course of deploying TLS 1.3 to Google servers, we found that JDK 11
unfortunately implemented TLS 1.3 incorrectly. On resumption, it fails to
send the SNI extension. This means that the first connection from a JDK 11
client will work, but subsequent ones fail.
https://bugs.openjdk.java.net/browse/JDK-8211806

It appears this will be fixed in JDK 11.0.2, which is not yet released. In
the meantime, we have sadly had to detect JDK 11 clients and disable TLS
1.3 for them. This, in turn, raises a problem with the downgrade signal in
ServerHello.random. JDK 11 does implement that downgrade signal, so the
workaround cannot send it. However, the signal is not effective for other
clients unless all TLS 1.2 ServerHellos are marked.

To salvage this for now, we've introduced a second value, generated
randomly:
    0xed, 0xbf, 0xb4, 0xa8, 0xc2, 0x47, 0x10, 0xff

When Google servers detect JDK 11 and disable TLS 1.3 to work around this
issue, they will use that value in ServerHello.random instead of the
standard 0x44, 0x4f, 0x57, 0x4e, 0x47, 0x52, 0x44, 0x01. Future versions of
Chrome will treat the new value as an alias of the standard one. Other
clients may wish to do the same, but please properly test your TLS 1.3
implementation first.

As JDK 11 is quite recent, we hope this will be relatively short-lived and
that we can remove this workaround and non-standard signal in the future.
Users of JDK 11 should upgrade to 11.0.2 once released to avoid
interoperability issues. In the meantime, they should disable TLS 1.3 by
passing -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 to the java binary.

Finally, as an update to the non-compliant middleboxes we noted previously
<https://www.ietf.org/mail-archive/web/tls/current/msg27066.html>, PAN-OS
8.1.4, PAN-OS 8.0.14, and PAN-OS 7.1.21 appear to now be released. Users of
Cisco and Palo Alto Networks firewall devices should upgrade their
products. We plan to reintroduce enforcement of the downgrade signal
sometime in the next year.

David

---

From: Hubert Kario <[email-masked]>
Date: Thu, 13 Dec 2018 17:53:51 +0100

> clients may wish to do the same, but please properly test your TLS 1.3

there is now a server test script in tlsfuzzer for standard downgrade 
sentinel:
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-downgrade-protection.py

example of usage: https://github.com/tomato42/tlsfuzzer/pull/479/files

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Thu, 13 Dec 2018 11:04:12 -0600

> example of usage: https://github.com/tomato42/tlsfuzzer/pull/479/files

That's not the problematic direction here. If someone ships a TLS 1.3
*client* which enforces the downgrade sentinel, it is important that the
TLS 1.3 implementation not contain show-stopping bugs. The reason JDK 11's
problem impacts the downgrade sentinel is because JDK 11 lacks a working
client TLS 1.3 implementation, but it insists it has one by way of
enforcing the signal on the client.

David

---

From: Hubert Kario <[email-masked]>
Date: Thu, 13 Dec 2018 18:20:53 +0100

> enforcing the signal on the client.

I know, but if people start fiddling with downgrade signal, they should verify 
that it works correctly in general case — I was replying to the last sentence 
only.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Dec 2018 12:50:26 -0600

> https://bugs.openjdk.java.net/browse/JDK-8211806

I'm told that OpenSSL accidentally takes the SNI from the initial
connection on resumption if there's no SNI in the resumption.  This
seems like a very good workaround for the buggy JDK 11 TLS 1.3 client,
as it has no fingerprinting nor downgrade considerations.

If the server rejects resumption I guess the client would still fail,
but this is much better than failing at 100% of all resumptions and
better than adding fingerprinting and downgrades.

Nico
--

---

From: Adam Langley <[email-masked]>
Date: Fri, 14 Dec 2018 11:25:12 -0800

> better than adding fingerprinting and downgrades.

In order for TLS 1.3 deployment to be viable the failure rate needs to be
negligible. It's not feasible to construct things such that moving traffic
across session caching domains causes a wave of handshake failures.
Additionally, if we were to wait for these versions of Java to die out in
the ecosystem, we risk other buggy clients getting established in the mean
time. We are painfully aware that limiting our server-side deployment
allowed this bug to become established and, while we did it to ease
middlebox issues, it may have been a mistake.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: [email-masked] (Martin Rex)
Date: Fri, 14 Dec 2018 22:11:38 +0100 (CET)

> as it has no fingerprinting nor downgrade considerations.

Just that this workaround is a no-go for any layered approach
to SNI, where server-side processing of SNI is outside of the TLS stack.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Dec 2018 20:07:48 -0600

> to SNI, where server-side processing of SNI is outside of the TLS stack.

I mean, that's already a problem for TLS 1.{0,1,2}, so I don't believe
that getting the SNI from the resumption ticket would be a problem on
this account.

Nico
--