On Sat, May 29, 2021 at 10:37:18PM -0400, Daniel Jakots wrote: > Hi, > > $ nc -zvc openbsd.org 443 # works as expected > Connection to openbsd.org (129.128.5.194) 443 port [tcp/https] succeeded! > TLS handshake negotiated TLSv1.3/AEAD-AES256-GCM-SHA384 with host openbsd.org > [...] > > $ nc -zvc openbsd.org. 443 # fails > Connection to openbsd.org. (129.128.5.194) 443 port [tcp/https] succeeded! > nc: tls handshake failed (handshake failed: error:1404B42E:SSL > routines:ST_CONNECT:tlsv1 alert protocol version)
$ nc -cvz -e openbsd.org openbsd.org. 443 # works Unless -e is given, nc uses 'destination' in its server name indication (SNI) extension. By its specification, (RFC 6066, section 3) the SNI does not contain the trailing dot. The server will treat the name with a trailing dot illegal and send an illegal_parameter alert. For some reason this alert is sent with a record version of TLS1_VERSION instead of TLS1_2_VERSION as required by the TLSv1.3 spec (that may be a bug), so while processing the illegal parameter alert, the client's record layer throws a protocol version error. > And FWIW I get a different error when the destination runs nginx: > > $ nc -zvc px.chown.me. 443 > Connection to px.chown.me. (198.48.202.221) 443 port [tcp/https] succeeded! > nc: tls handshake failed (handshake failed: error:1404B417:SSL > routines:ST_CONNECT:sslv3 alert illegal parameter) This has less to do with the fact that it's nginx and more with the fact that you configured it to use TLSv1.2, so the illegal_parameter alert is received without error. > I checked with -Tnoname to be sure, and it didn't change anything. This disables a check whether the server's certificate matches the server name sent in the SNI extension which comes later in the handshake. > Is that normal? I think so.
