Re: nc(1) fails the tls handshake when destination ends with a full stop

On 2021-05-30, Theo Buehler <tb@theobuehler.org> wrote:
> 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.

Should something (libtls perhaps; ftp(1) is affected too) strip the dot?
curl does handle this.