Re: [TLS] Further TLS 1.3 deployment updates
On Fri, Dec 14, 2018 at 10:11:38PM +0100, Martin Rex wrote:
> Nico Williams wrote:
> > On Wed, Dec 12, 2018 at 04:21:43PM -0600, David Benjamin wrote:
> >> 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
> >
> > 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.
>
> 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.
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
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Further TLS 1.3 deployment updates
Nico Williams wrote: > On Wed, Dec 12, 2018 at 04:21:43PM -0600, David Benjamin wrote: >> 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 > > 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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Further TLS 1.3 deployment updates
On Fri, Dec 14, 2018 at 10:50 AM Nico Williams wrote: > 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. > 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 a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Further TLS 1.3 deployment updates
On Wed, Dec 12, 2018 at 04:21:43PM -0600, David Benjamin wrote: > 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 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 -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Further TLS 1.3 deployment updates
On Thursday, 13 December 2018 18:04:12 CET David Benjamin wrote: > On Thu, Dec 13, 2018 at 10:54 AM Hubert Kario wrote: > > On Wednesday, 12 December 2018 23:21:43 CET David Benjamin wrote: > > > 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. > > > > there is now a server test script in tlsfuzzer for standard downgrade > > sentinel: > > > > https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-downgrade-p > > rotection.py > > > > 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. 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 signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Further TLS 1.3 deployment updates
On Thu, Dec 13, 2018 at 10:54 AM Hubert Kario wrote: > On Wednesday, 12 December 2018 23:21:43 CET David Benjamin wrote: > > 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. > > 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 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Further TLS 1.3 deployment updates
On Wednesday, 12 December 2018 23:21:43 CET David Benjamin wrote: > 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. 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 signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
