Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 19, 2018, at 4:24 PM, Salz, Rich wrote: > > Viktor found my comment offensive, which was not my intent. I was trying to > be light-hearted in commenting on how Viktor dismissed all the issues David > raised. > > If, in doing so, I went beyond our code of conduct and offended, I am truly > truly sorry. Thanks. Much appreciated... Yes, there are other potential obstacles when enabling TLS 1.3 in applications not specifically designed for it. Some substantial, others less so. Without going into a length analysis, I think that most of the issues are minor, but authentication failure when an unexpected certificate appears with 1.3 that one would not see with 1.2 seems like a substantially more major hurdle, and one that sure seems avoidable. I hope it will be looked at more closely and in the not too distant future deployed less broadly (if at all). -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
Viktor found my comment offensive, which was not my intent. I was trying to be light-hearted in commenting on how Viktor dismissed all the issues David raised. If, in doing so, I went beyond our code of conduct and offended, I am truly truly sorry. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
Sorry if I offended you. On 4/19/18, 3:23 PM, "Viktor Dukhovni" wrote: > On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote: > > I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or something like that. You'll need to retract that. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote: > > David has pointed out valid use-cases. I think most use-cases will "just > work." We should document the known sharp edges. I am pointing valid use-cases that David has not taken into account, and conformance ratchets have cost/benefit trade-offs, and are fair game for discussion. Ad hominem responses are entirely inappropriate, and an apology is due. David has done lots of good work, but we're all human, and the SNI ratchet is problematic for at least SMTP. I can legitimately be argued to be a poor tradeoff. Even in HTTP where the client ought to send SNI, if it does not, but would accept the default certificate (with e.g. TLS 1.2), the rationale for deliberately unusable certificates with TLS 1.3 does not look compelling, especially given the privacy leaks with SNI. -- -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote: > > I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or > something like that. You'll need to retract that. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 19, 2018, at 3:15 PM, Kurt Roeckx wrote: > > I think there might be some disagreement on how to go forward with > having proper TLS in SMTP. I think Google might want to go with > how it works for https, and so have certificates issued by a CA > for hostname you try to connect to. I think you would like to use > DANE instead. But I don't see DNSSEC or DANE getting wide adoption. NO. That's simply not the case, in fact I've contributed significantly to MTA-STS, and the use-case that fails here is NOT the DANE one (where SNI is already specified), but rather legacy WebPKI auth for SMTP. Please don't jump to conclusions or impute motives. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
On Thu, Apr 19, 2018 at 09:15:19PM +0200, Kurt Roeckx wrote: > > It would also be nice that if the client sends an SNI and you have > a certificate for it that it wouldn't select an anonymous cipher. > But then postfix is probably the only one that does anonymous > ciphers, and if it's not sending SNI this will not change much. An alternative is that if you think the certificate should be trusted by the peer you don't select an anonymous cipher. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
On Thu, Apr 19, 2018 at 02:02:53PM -0400, Viktor Dukhovni wrote: > > > > On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni > > wrote: > > > > There is no "the name that is being verified". The Postfix SMTP client > > accepts multiple (configurable as a set) names for the peer endpoint. This > > may be the next-hop domain or the MX hostname, or a sub-domain wildcard, or > > some fixed hardcoded-name, or a mixture of these... > > Furthermore, with SMTP servers we can't be sure whether the peer even > tolerates SNI, it may decide that it has no certificate exactly matching the > client's guess, and hang up, even though the client would be happy with the > default certificate. > > I'm reluctant to start sending SNI in configurations that work fine without > SNI, and could well break when it is introduced. So if you're at all in > touch with the Gmail folks, please work with them to undo the ratchet in > question, at least SMTP MUST NOT suddenly stop yielding the expected default > certificate for lack of SNI. I think there might be some disagreement on how to go forward with having proper TLS in SMTP. I think Google might want to go with how it works for https, and so have certificates issued by a CA for hostname you try to connect to. I think you would like to use DANE instead. But I don't see DNSSEC or DANE getting wide adoption. I currently see 4 type of connections for my outgoing mail in my postfix log: - Verified TLS connection: self-signed DANE - Verified TLS connection: DANE but with a valid certificate - Untrusted TLS connection: People who have a valid certificate for the hostname I connect to - Anonymous TLS: Using an anoymous cipher, yet having a valid certificate This is of course a very limited amount, only for what I send, but I think TLS for SMTP is already in a much better state now. I think in the end we should just enforce proper certificates. It would be nice that all those that do have a proper certificate are actually marked as "Verified", there really is no reason to say they are Untrusted. It would also be nice that if the client sends an SNI and you have a certificate for it that it wouldn't select an anonymous cipher. But then postfix is probably the only one that does anonymous ciphers, and if it's not sending SNI this will not change much. But I don't agree to Google's use of SNI, saying that if it supports TLS 1.3 that it must be modern software that should send an SNI. The library (OpenSSL) will support it, but that doesn't mean that application will set it, or that upgrading OpenSSL will suddenly make the appliation set it. I also don't see a relation between not sending SNI and not checking the certificate, you can perfectly write code that does not send an SNI but does proplery validate the certificate. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or something like that. David has pointed out valid use-cases. I think most use-cases will "just work." We should document the known sharp edges. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 19, 2018, at 1:31 PM, David Benjamin wrote: > > Consider a caller using a PKCS#1-only ENGINE-backed private key. PKCS#1 does > not work in TLS 1.3, only PSS. That's a local matter, and easy to resolve locally. > Consider a caller which calls SSL_renegotiate. Ditto. And sufficiently uncommon to not worry about. > A client which expects the session to be available immediately after the > handshake will also break. Sessions are not always offered by the server, clients already have to deal with this. > Or someone who listens to the message callback. Not worth worrying about. > Or someone who only installed CBC-mode ciphers in initialization. Not a problem, OpenSSL 1.1.1 has separate cipher controls for TLS 1.3 > Or just someone who calls SSL_version and checks that it is TLS1_2_VERSION. They can set the max version. ... The above are local edge cases. The SNI interoperability trap is random damage imposed by apparently capricious remote servers. I plead you reconsider this *particular* additional hoop for TLS 1.3 clients to jump through, just do whatever you did with TLS 1.2. If TLS 1.2 failed with SNI, fine do the same with TLS 1.3, if not then return the same chain. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni > wrote: > > There is no "the name that is being verified". The Postfix SMTP client > accepts multiple (configurable as a set) names for the peer endpoint. This > may be the next-hop domain or the MX hostname, or a sub-domain wildcard, or > some fixed hardcoded-name, or a mixture of these... Furthermore, with SMTP servers we can't be sure whether the peer even tolerates SNI, it may decide that it has no certificate exactly matching the client's guess, and hang up, even though the client would be happy with the default certificate. I'm reluctant to start sending SNI in configurations that work fine without SNI, and could well break when it is introduced. So if you're at all in touch with the Gmail folks, please work with them to undo the ratchet in question, at least SMTP MUST NOT suddenly stop yielding the expected default certificate for lack of SNI. And just recompiling against OpenSSL 1.1.1 headers should not suddenly change behaviour. On the server side there needs to be some recognition of application context, with HTTP servers requiring SNI (where appropriate), but SMTP and other similar applications not doing so. I'd like to use TLS 1.3 in SMTP, even by default on a recompile or run-time relink with no code changes to explicitly enable TLS 1.3. But if servers are going to put up unnecessary roadblocks, TLS 1.3 is not going to get much traction. Please reconsider this particular ratchet (for at least SMTP). It *is* counter-productive. Not sure what OpenSSL should do at this point... :-( -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 19, 2018, at 1:31 PM, David Benjamin wrote: > > Consequently, opportunistic SMTP clients (or those using mandatory TLS, but > without > DANE where the SNI value is still a guessing game we did not play) won't get > TLS 1.3, until they start to make up some sort of SNI name. > > I'm not sure I follow this. Why is the SNI value a guessing game? The client > that does not verify the certificate does not care what certificate it gets. > (This is why we still send something, rather than close the connection.) The > client that does verify a certificate, whether or not failures are fatal, > does not need to guess: use the name that is being verified. There is no "the name that is being verified". The Postfix SMTP client accepts multiple (configurable as a set) names for the peer endpoint. This may be the next-hop domain or the MX hostname, or a sub-domain wildcard, or some fixed hardcoded-name, or a mixture of these... -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
On 19/04/18 18:31, David Benjamin wrote: > I might suggest conditioning it on the compile-time version of OpenSSL > headers. This is a common transition strategy for systems working > through ABI constraints. (In some systems, this is implemented as some > target SDK version.) This is exactly what Richard proposed in this PR: https://github.com/openssl/openssl/pull/5945 Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 18, 2018, at 6:23 PM, David Benjamin wrote: > > 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. So it sure seems like we can't introduce a transparent transition to TLS 1.3 without taking care to disable TLS 1.3 when SNI is not provided. Since OpenSSL won't know whether it is doing SMTP or HTTP, or whatever, it means that OpenSSL will need to disable TLS 1.3 in the absence of SNI across the board. Consequently, opportunistic SMTP clients (or those using mandatory TLS, but without DANE where the SNI value is still a guessing game we did not play) won't get TLS 1.3, until they start to make up some sort of SNI name. It seems to me that all the incentive that clients need to send SNI is not getting the right certificate if they don't, but deliberately withholding the default certificate and sending self-signed invalid is hugely counter-productive. IMHO, such strategies just delay TLS 1.3 deployment. If there's a sensible default cert, please don't punish the client and fail to send it. This sort of thing does not lead to the desired outcome, it just forces work-arounds (such as not doing TLS 1.3). -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
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 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 > posttl
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 18, 2018, at 1:14 PM, Kurt Roeckx wrote: > > I'm not sure you actually get downgraded? I get TLS 1.2 in all > cases. I think they still speak a different draft version. If it's > boringssl, I think they do 22 and 23 in the last release and 26 > (like we) in their current master version. Perhaps that's right, even with SNI I get TLS 1.2, but with the right certificate, whereas without SNI I get the wrong certificate. It is not clear what will happen when they actually support TLS 1.3. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
On Wed, Apr 18, 2018 at 11:05:05AM -0400, Viktor Dukhovni wrote: > > What I can blame them for is being counter-productively pedantic. Forget the > RFC language, does what they're doing make sense and improve security or is > it just a pointless downgrade justified by RFC text lawyering? I'm not sure you actually get downgraded? I get TLS 1.2 in all cases. I think they still speak a different draft version. If it's boringssl, I think they do 22 and 23 in the last release and 26 (like we) in their current master version. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 18, 2018, at 10:43 AM, Andy Polyakov wrote: > > It can either be a probe just to see if it's reasonable to demand it, or > establish a precedent that they can refer to saying "it was always like > that, *your* application is broken, not ours." Also note that formally > speaking you can't blame them for demanding it. But you can blame them > for demanding it wrong. I mean they shouldn't try to communicate through > OU of self-signed certificate, but by terminating connection with > missing_extension alert, should they? What I can blame them for is being counter-productively pedantic. Forget the RFC language, does what they're doing make sense and improve security or is it just a pointless downgrade justified by RFC text lawyering? -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
>That's what Rich suggested, and it makes sense, but what does not make any > sense to me is what Google is doing. Snatching defeat from the jaws of > victory by needlessly forcing clients to downgrade to TLS 1.2. Is there a > justification for this? It's Google's internet, we just use it. If you have the #1 browser and the #1 website you can force all sorts of things to happen. Take this up on the TLSWG mailing list. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> ... what does not make any sense to me is what Google is doing. Snatching > defeat from the jaws of victory by needlessly forcing clients to downgrade to > TLS 1.2. Is there a justification for this? It can either be a probe just to see if it's reasonable to demand it, or establish a precedent that they can refer to saying "it was always like that, *your* application is broken, not ours." Also note that formally speaking you can't blame them for demanding it. But you can blame them for demanding it wrong. I mean they shouldn't try to communicate through OU of self-signed certificate, but by terminating connection with missing_extension alert, should they? ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> On Apr 18, 2018, at 10:12 AM, Andy Polyakov wrote: > > 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? That's what Rich suggested, and it makes sense, but what does not make any sense to me is what Google is doing. Snatching defeat from the jaws of victory by needlessly forcing clients to downgrade to TLS 1.2. Is there a justification for this? -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> 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? ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
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@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project