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

[David Benjamin]

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 at 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 at 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 at 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 at lists.webkit.org
> >> https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210429/01d7f1f7/attachment.htm>