Remove support for the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite.

Motivation

TLS_RSA_WITH_3DES_EDE_CBC_SHA is a remnant of the SSL 2.0 and SSL 3.0 era. 3DES in TLS is vulnerable to the Sweet32 [https://sweet32.info/] attack. Being a CBC cipher suite, it is also vulnerable to the Lucky Thirteen [https://en.wikipedia.org/wiki/Lucky_Thirteen_attack] attack. The first replacement AES cipher suites were defined for TLS in RFC3268, published around 19 years ago, and we’ve had several iterations since. [RFC5288, RFC5289, RFC8446] The cipher suite is slow and CPU-intensive. On mobile, this translates to wasted battery. 3DES is, itself, expensive, and we have more efficient constructions than CBC. The mitigations needed to avoid the Lucky Thirteen attack add a further penalty. In total, on a fast desktop workstation, we can only process 32MB/s with 3DES, while AES-128-GCM with hardware acceleration hits 5.6GB/s. With all hardware and vector operations disabled, that workstation still hits 159M/s with AES-128-GCM and 480MB/s with ChaCha20-Poly1305. Finally, many implementations of 3DES leak cache and timing side channels. This includes ours and OpenSSL’s, used in many servers. While it is possible to avoid this with a “constant-time” implementation, as we do for modern ciphers, this would even further increase 3DES’s CPU penalty. BearSSL reports a 3x hit for a constant-time implementation. [https://www.bearssl.org/constanttime.html#des]

Status in Chromium

Internals>Network>SSL


In development (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

  • Worth prototyping
  • No signal
  • No signal
  • No signals

Owner

Search tags

3des, tls, ssl, des,

Last updated on 2021-05-06