> 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 l
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 c
> 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
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 no
> 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
>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
> ... 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 precede
> 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
> 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
>Would still like to know what's motivating Google's insistence on SNI...
The TLS WG is probably the place to ask this.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
10 matches
Mail list logo
