[openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

[Andy Polyakov]

> When I link posttls-finger with the OpenSSL 1.1.1 library, I see:

Just in case for reference, one can reproduce all this with 1.1.1
s_client. Below case is -starttls smtp -noservername. "Fun" part is that
OU for the self-signed certificate reads "No SNI provided; please fix
your client." Another "fun" part is that they don't seem to be concerned
with SNI value, it can be literally whatever.

>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25 
>     CommonName invalid2.invalid
>   posttls-finger: certificate verification failed for
>     gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     self-signed certificate
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     subject_CN=invalid2.invalid, issuer_CN=invalid2.invalid
>   posttls-finger: Untrusted TLS connection established to
>     gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

Below case is -starttls smtp -tls1_2 [with of without servername].

> The same command with OpenSSL 1.1.0 yields (no CAfile/CApath
> so authentication fails where it would typically succeed):
> 
>   posttls-finger: certificate verification failed for
>     gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     untrusted issuer /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     subject_CN=gmail-smtp-in.l.google.com,
>     issuer_CN=Google Internet Authority G3,
>   posttls-finger: Untrusted TLS connection established to
>     gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
> 
> This is a substantial behaviour change from TLS 1.2, and a rather
> poor decision on Google's part IMHO, though I'm eager to learn why
> this might have been a good idea.
> 
> In the mean-time, Richard's objection to automatic TLS 1.3 use
> after shared-library upgrade is starting to look more compelling?

Question is what would be users' expectation. If we arrange it so that
application compiled with 1.1.0 simply won't negotiate 1.3, then would
it be reasonable of them to expect that it will start working if they
simply recompile application? I.e. without changing application code!
But in such case it wouldn't actually help for example this case, but
only make things more confusing. I mean you end up with "all I wanted
1.3 and now it doesn't work at all". I'd say that it would be more
appropriate to make user ask "I want 1.3 but don't get it, why? it keeps
working with 1.2 though." With this in mind, wouldn't it be more
appropriate to simply not offer 1.3 capability if application didn't
provide input for SNI?