> On Apr 17, 2018, at 8:03 PM, Viktor Dukhovni <viktor1dane@???> wrote:
>
>> This came up because, today, Google's servers are responding to TLS1.3
>> connections which don't send SNI with a self-signed certificate which
>> has DN:
>>
>> OU=No SNI provided; please fix your client., CN=invalid2.invalid
>>
>> So Google are telling sending systems that they're broken and need to be
>> fixed. I saw that string in my MTA logs and went investigating.
>
> Which Google servers are these? Are they MX hosts for some domains???
> If so, I need to tell Google urgently to cease and desist, this is
> wrong.
On the other hand, for opportunistic TLS, who cares if they return some
self-signed certificate, so long as the handshake completes with that
certificate, we're good.
The real problem will be if applications that previously sent no SNI
with TLS 1.2 in OpenSSL 1.1.0 are run-time linked with the OpenSSL
1.1.1 libraries (same SONAME) and no start doing TLS 1.3, and find
that they now fail to authenticate Google. This sort of enforcement
will backfire and have the effect of turning off TLS 1.3, not getting
users to rewrite applications to send SNI.
If they have a default certificate chain that works with TLS 1.2
withholding it with TLS 1.3 seems rather rude... I'll chat with
David Benjamin, perhaps he'll have good reasons for this that I'm
missing, but off hand it seems counter-productive.
--
Viktor.
