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

Wed Apr 18 22:23:52 UTC 2018

Google incurs a significant, ongoing cost to support clients that don't
send SNI. Such clients, at least in the HTTP space, are easy to miss in
casual testing (because browsers do send SNI), and require that we ensure
that a given name is covered by the default certificates on any IP address
that could be served for that name.

However, since not sending SNI generally works for Google services, we not
only have a legacy of clients that could send SNI but don't, but a stream
of new clients that ship without noticing the problem. In short, the
problem is not getting any better.

Rather than break existing clients, with TLS 1.3 we are trying a more
incremental approach: if a client is new enough to support TLS 1.3 then
either it should be sending SNI, or we'll give it a dummy certificate. If
the client didn't send SNI because it doesn't have a hostname to verify
against anyway, then the dummy certificate works just as well. If it does
have a hostname to verify against, then it should send that in SNI.

This only affects the choice of certificate, not the protocol version. To
the downgrade question, that is just, as Kurt suggested, the usual
temporary draft version mismatch and unrelated. The certificate behavior is
triggered by supported_versions in the ClientHello, which is why you're
still seeing it on draft mismatch.

That won't solve clients that aren't updating, but it might at least give
us a negative gradient. We expect this experience with SNI is shared with
other large TLS deployments and hope that the ecosystem effects will
therefore be generally valuable.

The above was done with HTTP in mind, but the code also triggers for SMTP
as you have observed. SMTP is complicated by the fact that it's not so
clear which hostname to verify against: ideally one would match the domain
part of the email address, but in practice we know that doesn't work very
well and that, in many cases, one will trust the MX lookup and verify the
MX name instead.

So, if doing certificate verification, we believe that the logic above
applies and that an MTA should be sending an SNI value equal to what name
they will be validating against. (Or, if you'll accept either, pick
one—probably the MX name.)

If the MTA is not validating certificates, then not sending SNI is fine and
the invalid2.invalid certificate works because it's not being validated
anyway.

Having said that, this was intended more for HTTP-based clients. Our Gmail
team are aware of this and may choose not to apply this behaviour to SMTP
clients in the future.

David and AGL

On Tue, Apr 17, 2018 at 10:29 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

>
> 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
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180418/a61fd969/attachment.html>