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

[Viktor Dukhovni]

Applications that have hitherto used TLS <= 1.2 have often not needed to use SNI.  The extension, though useful for virtual-hosting on the Web, was optional.

TLS 1.3 has raised the status of SNI from optional to "mandatory to implement".
What this means that is that implementations must support it, but it stops of
mandating SNI outright.  Clients SHOULD send SNI, when applicable, and servers
MAY require SNI:

  https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2

  -  The "server_name" [RFC6066] and "certificate_authorities"
     extensions are used to guide certificate selection.  As servers
     MAY require the presence of the "server_name" extension, clients
     SHOULD send this extension, when applicable.

  [...]

  Additionally, all implementations MUST support use of the
  "server_name" extension with applications capable of using it.
  Servers MAY require clients to send a valid "server_name" extension.
  Servers requiring this extension SHOULD respond to a ClientHello
  lacking a "server_name" extension by terminating the connection with
  a "missing_extension" alert.

In the world of SMTP, with SMTP server names determined indirectly
and generally insecurely from MX records, it is not generally clear
what name one would use in SNI, and many SMTP clients don't send it
at all.  Some authenticate servers against the nexthop domain (the
envelope recipient domain), others might authenticate the MX host,
or just do unauthenticated opportunistic TLS.  This has worked
acceptably well with TLS <= 1.2

Along comes 1.3, and suddenly some server operators have become
particularly keen on enforcing all sorts of constraints that at
first blush look rather aggressive.  Specifically, the Google
SMTP servers serving millions of domains (including gmail.com),
now only do TLS 1.3 when SNI is presented, and when SNI is missing,
not only negotiate TLS 1.2, but use an unexpected self-signed cert
chain that validating senders will fail to authenticate, and others
may find perplexing in their logs.  (Thanks to Phil Pennock, Bcc'd
for reporting this on the exim-dev list).

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

  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)

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?

Comments?  [ Especially from David Benjamin, if he's in the loop
on the thinking that might have led to the new behaviour ]

-- 
	Viktor.