Request for position: Removing 3DES from TLS
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/JikQYHP... David
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
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
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
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-... 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
Thanks, David. I think we’re on the same page now.
On Apr 29, 2021, at 12:47 PM, David Benjamin <davidben@chromium.org> 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-... <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.
participants (3)
-
Alex Christensen
-
David Benjamin
-
Michael Catanzaro