Hello,
I recently encountered a compatibility issue with X25519Kyber768
<https://bugs.chromium.org/p/chromium/issues/detail?id=1484074>: I was
unable to access the site via X25519Kyber768-enabled Google Chrome on a
server with only TLS 1.2 enabled, but not TLS 1.3.
The Chromium team replied:
> Regarding TLS 1.2 vs TLS 1.3, a TLS ClientHello is generally good for
> all the parameters we support. So though we include TLS 1.3 with Kyber
> in there, we also include parameters for TLS 1.3 without Kyber and TLS
> 1.2. So if the server and network well behaving correctly, it's
> perfectly fine if the server only supports TLS 1.2.
>
> I'm able to reproduce the problem. It looks like a bug in
> www.paypal.cn's server. They didn't implement TLS 1.2 correctly.
> Specifically, they do not correctly handle when the ClientHello comes
> in in two reads. Before Kyber, this wasn't very common because
> ClientHellos usually fit in a packet. But Kyber makes ClientHellos
> larger, so it is possible to get only a partial ClientHello in the
> first read, and require a second read to try again. This is something
> that any TCP-based application needs to handle; you may not have
> gotten the whole message on a given read and need to keep on reading.
>
> www.paypal.cn will need to fix their server to correctly handle this case.
So the Chromium team isn't considering making a change, so I'm wondering
how compatible nginx is with this? Or what version is needed to make it
error free?
Best regards,
Gentry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20231009/ebbb353e/attachment.htm>
Hello!
On Mon, Oct 09, 2023 at 11:55:15PM +0800, Gentry Deng via nginx wrote:
> I recently encountered a compatibility issue with X25519Kyber768
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1484074>: I was
> unable to access the site via X25519Kyber768-enabled Google Chrome on a
> server with only TLS 1.2 enabled, but not TLS 1.3.
>
> The Chromium team replied:
>
>
> > Regarding TLS 1.2 vs TLS 1.3, a TLS ClientHello is generally good for
> > all the parameters we support. So though we include TLS 1.3 with Kyber
> > in there, we also include parameters for TLS 1.3 without Kyber and TLS
> > 1.2. So if the server and network well behaving correctly, it's
> > perfectly fine if the server only supports TLS 1.2.
> >
> > I'm able to reproduce the problem. It looks like a bug in
> > www.paypal.cn's server. They didn't implement TLS 1.2 correctly.
> > Specifically, they do not correctly handle when the ClientHello comes
> > in in two reads. Before Kyber, this wasn't very common because
> > ClientHellos usually fit in a packet. But Kyber makes ClientHellos
> > larger, so it is possible to get only a partial ClientHello in the
> > first read, and require a second read to try again. This is something
> > that any TCP-based application needs to handle; you may not have
> > gotten the whole message on a given read and need to keep on reading.
> >
> > www.paypal.cn will need to fix their server to correctly handle this case.
>
>
> So the Chromium team isn't considering making a change, so I'm wondering
> how compatible nginx is with this? Or what version is needed to make it
> error free?
There are no known issues in nginx with ClientHello split between
packets (with all supported SSL libraries). And I would be very
much surprised if there are any, as this is indeed a very basic
thing TCP-based applications used to handle.
Such issues are more likely to be seen in various packet-based
filtering solutions, and I would assume this is most likely the
case for the site in question.
--
Maxim Dounin
http://mdounin.ru/
On Mon, Oct 9, 2023 at 11:55 AM Gentry Deng via nginx <nginx at nginx.org> wrote:
>
> ...
> I'm able to reproduce the problem. It looks like a bug in www.paypal.cn's server. They didn't implement TLS 1.2 correctly. Specifically, they do not correctly handle when the ClientHello comes in in two reads. Before Kyber, this wasn't very common because ClientHellos usually fit in a packet. But Kyber makes ClientHellos larger, so it is possible to get only a partial ClientHello in the first read, and require a second read to try again. This is something that any TCP-based application needs to handle; you may not have gotten the whole message on a given read and need to keep on reading.
>
> www.paypal.cn will need to fix their server to correctly handle this case.
It sounds like this, assuming they are using a F5:
<https://my.f5.com/manage/s/article/K72042050>.
Broken middleware is always interesting. One of my favorites was
Ironport and its fixed sized buffer for a ClientHello that resulted in
buffer overflows and crashes when TLS 1.1 and TLS 1.2 increased the
size of a ClientHello due to additional cipher suites. See
<https://www.mail-archive.com/openssl-users at openssl.org/msg73489.html>.
Jeff