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. _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
