<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p><br>
</p>
<p>I recently encountered a <a
href="https://bugs.chromium.org/p/chromium/issues/detail?id=1484074"
hreflang="en" target="_blank"
title="1484074 - Compatibility issue with X25519Kyber768 and www.paypal.cn - chromium"
moz-do-not-send="true">compatibility issue with X25519Kyber768</a>:
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.</p>
<p>The Chromium team replied:</p>
<p><br>
</p>
<p>
<blockquote type="cite">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.<br>
<br>
I'm able to reproduce the problem. It looks like a bug in
<a class="moz-txt-link-abbreviated" href="http://www.paypal.cn's">www.paypal.cn's</a> 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.<br>
<br>
<a class="moz-txt-link-abbreviated" href="http://www.paypal.cn">www.paypal.cn</a> will need to fix their server to correctly handle
this case.</blockquote>
</p>
<p><br>
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?</p>
<p><br>
</p>
<p>Best regards,</p>
<p>Gentry<br>
</p>
</body>
</html>