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

[Kurt Roeckx]

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)

[Viktor Dukhovni]

> 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)

[Andy Polyakov]

> ... 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)

[Viktor Dukhovni]

> 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)

[Andy Polyakov]

> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Salz, Rich]

>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