Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-29 Thread Alex Christensen via webkit-dev 
Thanks, David.  I think we’re on the same page now.

> On Apr 29, 2021, at 12:47 PM, David Benjamin  wrote:
> 
> Ah yes, that is confusing. Not quite. What's going on here is that we've 
> moved 3DES (and SHA-1 server signatures) under a fallback connection, so our 
> first connection won't advertise them, but on error the second one will. This 
> means that, for compatibility and security purposes, we do support 3DES. But 
> when you look at the ClientHellos, it'll look like we don't.
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ
>  
> 
Ah, yes.  Now I see that when connecting to https://3des.badssl.com/ Chrome 
will send a retry client hello with TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

> (By the way, it looks like, on my machine, Safari on Big Sur also supports 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.)
You are correct.  I overlooked that one, which upon closer inspection was right 
next to the other ones the whole time.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-29 Thread David Benjamin via webkit-dev 
Ah yes, that is confusing. Not quite. What's going on here is that we've
moved 3DES (and SHA-1 server signatures) under a fallback connection, so
our first connection won't advertise them, but on error the second one
will. This means that, for compatibility and security purposes, we *do* support
3DES. But when you look at the ClientHellos, it'll look like we don't.
https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ

We do for more accurate measurement. In TLS, the client offers lists of
parameters, and then the server selects from that list based on its
negotiation criteria. That means if you simply measure the selected
parameters, you don't account for servers that supported other parameters
but preferentially picked this one, for some reason. This is also why
client tests like SSL Labs are very fast (they just read out the
ClientHello), while the corresponding server tests are very slow (they need
to probe server behavior in response to many ClientHellos and make guesses
about the negotiation criteria).

*Usually* the more straightforward measurement is good enough. It is an
upper bound[*], and everyone agrees TLS 1.1 is better than TLS 1.0, etc.
That AES is better than 3DES is also pretty well-established. However, from
looking at server behavior in the wild, we noticed there were a lot of
servers that had strange preference orders for 3DES and SHA-1 server
signatures. Servers that prefer 3DES but also support AES, while strange
and misconfigured, would *not* be broken by this removal. So, when
prevalent, it is useful to put them under fallback to get a more accurate
measurement.

This also means that, as you all evaluate 3DES for something similar, be
aware that a naive strategy may overcount the impact. So if your current
numbers are low enough, excellent. If they're too high, it is possible that
the true numbers are lower and the change is safer than it looks.

(By the way, it looks like, on my machine, Safari on Big Sur also supports
TLS_RSA_WITH_3DES_EDE_CBC_SHA.)

David

[*] Well, mostly. There's nothing stopping the server from implementing
some ridiculous selection logic like "if 3DES is present in the
ClientHello, pick AES-GCM, else, fail the connection". But that would be
ridiculous. :-)

On Wed, Apr 28, 2021 at 7:14 PM Alex Christensen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> They are aware of this thread now, but I can’t comment on any future
> plans.  I do have a few quick questions, though.
>
> A quick glance at the client hellos sent by browsers shows this:
> Safari on Big Sur sends TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) and
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) in its supported cipher suites
> section of the client hello.
> Firefox 88 sends TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
> Chrome 90 sends no cipher suites with 3DES.
>
> This might be why Chrome measures 0.00% use of
> TLS_RSA_WITH_3DES_EDE_CBC_SHA - because it doesn’t advertise that it
> supports it.  It seems to me that you’ve already removed support for 3DES
> in Chrome.  What was the measured use of 3DES cipher suites in the release
> before you removed support?  We have measured slightly above 0.00% use in a
> browser that does send 3DES cipher suites in its client hellos.
>
> If you haven’t already removed support, how would one use it?  I’ll admit
> I haven’t gone through all the possibilities of renegotiation that TLS has.
>
> > On Apr 28, 2021, at 8:21 AM, Alex Christensen via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
> >
> > Your measurement of 0.00% use in Chrome is exciting.
> >
> > Making this change would almost certainly not be a change in WebKit but
> I’ve reached out to the people who manage our crypto code.
> >
> >> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
> >>
> >>
> >> Looks like this change is clearly safe.
> >>
> >> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK,
> they're controlled by the operating system's TLS backend and crypto policy.
> 3DES has been disabled for a while now on modern systems, and users have
> not reported any compat issues, which is not surprising given your finding
> of 0.00%.
> >>
> >> Michael
> >>
> >>
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-28 Thread Alex Christensen via webkit-dev 
They are aware of this thread now, but I can’t comment on any future plans.  I 
do have a few quick questions, though. 

A quick glance at the client hellos sent by browsers shows this:
Safari on Big Sur sends TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) and 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) in its supported cipher suites 
section of the client hello.
Firefox 88 sends TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Chrome 90 sends no cipher suites with 3DES.

This might be why Chrome measures 0.00% use of TLS_RSA_WITH_3DES_EDE_CBC_SHA - 
because it doesn’t advertise that it supports it.  It seems to me that you’ve 
already removed support for 3DES in Chrome.  What was the measured use of 3DES 
cipher suites in the release before you removed support?  We have measured 
slightly above 0.00% use in a browser that does send 3DES cipher suites in its 
client hellos.

If you haven’t already removed support, how would one use it?  I’ll admit I 
haven’t gone through all the possibilities of renegotiation that TLS has.

> On Apr 28, 2021, at 8:21 AM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Your measurement of 0.00% use in Chrome is exciting.
> 
> Making this change would almost certainly not be a change in WebKit but I’ve 
> reached out to the people who manage our crypto code.
> 
>> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev 
>>  wrote:
>> 
>> 
>> Looks like this change is clearly safe.
>> 
>> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
>> they're controlled by the operating system's TLS backend and crypto policy. 
>> 3DES has been disabled for a while now on modern systems, and users have not 
>> reported any compat issues, which is not surprising given your finding of 
>> 0.00%.
>> 
>> Michael
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-28 Thread Alex Christensen via webkit-dev 
Your measurement of 0.00% use in Chrome is exciting.

Making this change would almost certainly not be a change in WebKit but I’ve 
reached out to the people who manage our crypto code.

> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> 
> Looks like this change is clearly safe.
> 
> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
> they're controlled by the operating system's TLS backend and crypto policy. 
> 3DES has been disabled for a while now on modern systems, and users have not 
> reported any compat issues, which is not surprising given your finding of 
> 0.00%.
> 
> Michael
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-28 Thread Michael Catanzaro via webkit-dev 



Looks like this change is clearly safe.

I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
they're controlled by the operating system's TLS backend and crypto 
policy. 3DES has been disabled for a while now on modern systems, and 
users have not reported any compat issues, which is not surprising 
given your finding of 0.00%.


Michael


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Removing 3DES from TLS

2021-04-28 Thread David Benjamin via webkit-dev 
Hello WebKit friends,

We're looking at dropping 3DES cipher suites from TLS. For us, this is
just TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Looks like Safari additionally supports TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
and TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, which would also fall under that
category.

After TLS 1.0 and 1.1 were removed, our metrics report a whole 0.00% of TLS
connections using TLS_RSA_WITH_3DES_EDE_CBC_SHA. (And, of course, no sites
use the other two in Chrome, since we don't support them in the first
place.)

For additionally background and motivation, see the blink-dev posting here.
https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/JikQYHPuBQAJ

David
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev