<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Might be helpful to point at <a
href="https://trac.nginx.org/nginx/ticket/1654#comment:2">https://trac.nginx.org/nginx/ticket/1654#comment:2</a>
and other issues which have spurned the request to rebuild
downstream.</p>
<p>Which, given that NGINX built against 1.1.0 downstream and
OpenSSL downstream in Ubuntu with 1.1.1 is set such that TLS 1.3
is "on by default" and therefore is just 'available' and enabled
but not able to be controlled/disabled by NGINX directly, it DOES
work with TLS1.3 connections and ciphers. We just can't
manipulate things.</p>
<p>The developer concern downstream is this rebuild won't introduce
any other TLS 1.3 behaviors not already present as a result of
OpenSSL being "TLS1.3 Enabled By Default" which is the current
situation.</p>
<p><br>
</p>
<p>Thomas</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/18/19 4:09 PM, PGNet Dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6ac3b9ed-79d4-7dba-5007-d52edf95373b@gmail.com">On
7/18/19 1:01 PM, Thomas Ward wrote:
<br>
<blockquote type="cite">There's a few considerations here. We
need to make certain that such a rebuild to allow NGINX to
control TLS 1.3 protocol or ciphers isn't going to introduce any
additional TLS1.3 behaviors or feature functionality that
otherwise would not be controlled by OpenSSL under </blockquote>
<br>
Offhand, have you already demonstrated to your satisfaction that
TLSv1.3 served-up in Nginx is, in fact, using the TLSv1.3
ciphers? Regardless of any 'additional' "behaviors or feature or
functionality"?
<br>
<br>
Atm, in some simple testing I'm seeing that it doesn't -- and
looking for any evidence, anectdotal or otherwise, that it does so
I can narrow down if it's 'me' ...
<br>
<br>
</blockquote>
</body>
</html>