Intent to Deprecate and Remove: TLS CBC-mode ECDSA cipher suites

426 vistas
Ir al primer mensaje no leído

David Benjamin

no leída,
21 oct. 2016 14:14:3621/10/16
para blink-dev,net-dev,security-dev

Primary eng (and PM) emails

davi...@chromium.org


Summary

Remove ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS cipher suites.


Motivation

TLS’s CBC-mode construction is flawed, making it fragile and very difficult to implement securely (for the current taxonomy, see BEAST, Lucky Thirteen, and POODLE). TLS 1.2 added new ciphers based on AEADs which avoid these problems.


Although CBC-mode ciphers are still widely used with RSA, they are virtually nonexistent with ECDSA. We thus intend to remove them now that it is practical to do so. Further, this effectively requires TLS 1.2 for ECDSA which, combined with our ECDSA/SHA-1 removal and the SHA-1 certificate deprecation, will fully remove our dependency on SHA-1 for ECDSA.


Compatibility Risk

Other browsers still support these ciphers, but metrics are good, so we believe the risk is low. Additionally, ECDSA in TLS is used by few organizations and usually with a more complex setup (some older clients only support RSA), so we expect ECDSA sites to be better maintained and more responsive in case of problems.


Alternative implementation suggestion for administrators

Enable TLS 1.2 with AEAD-based ciphers based on AES_128_GCM, AES_256_GCM, or CHACHA20_POLY1305.


Although we are only requiring this for ECDSA-based sites at this time, it is recommended for all administrators. AEAD-based ciphers not only improve security but also performance. AES-GCM has hardware support on recent CPUs and ChaCha20-Poly1305 admits fast software implementations. Meanwhile, CBC ciphers require slow complex mitigations and PRNG access on each outgoing record. AEAD-based ciphers are also a prerequisite for HTTP/2 and False Start optimizations.


Usage information from UseCounter

Over the past 28 days, ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_256_CBC_SHA were each used for 0.00% (rounded) of TLS connections made on Chrome stable. Probing a list of top million sites found only two hosts which would be affected, one of which only redirects back to HTTP. We will reach out to them.


OWP launch tracking bug

https://crbug.com/658341


Entry on the feature dashboard

https://www.chromestatus.com/feature/5740978103123968


Requesting approval to remove too?

Yes


Jochen Eisinger

no leída,
21 oct. 2016 14:24:0621/10/16
para David Benjamin,blink-dev,net-dev,security-dev
lgtm1

Rick Byers

no leída,
21 oct. 2016 14:59:3021/10/16
para Jochen Eisinger,David Benjamin,blink-dev,net-dev,security-dev
2 affected hosts in the top million is great.  LGTM2

Chris Harrelson

no leída,
21 oct. 2016 15:52:3821/10/16
para Rick Byers,Jochen Eisinger,David Benjamin,blink-dev,net-dev,security-dev
LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Jacob

no leída,
28 oct. 2016 02:03:5828/10/16
para net-dev,blin...@chromium.org,securi...@chromium.org
Is the intent to also remove support for the ECDSA CBC-mode ciphers based on SHA2 hashing/PRF? Eg also remove:

ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Or is this only focused on the SHA1-based ciphers?

David Benjamin

no leída,
28 oct. 2016 02:23:0028/10/16
para Jacob,net-dev,blin...@chromium.org,securi...@chromium.org
We've actually never supported those ciphers at all, so there's nothing to remove. While those ciphers do not exist in TLS 1.0 and TLS 1.1, they're still CBC-mode ciphers with all the weaknesses that entails. Use an AEAD-cipher. They're the only ciphers that are not known broken. (And indeed TLS 1.3 removes all but the AEADs.)

Aside: The difference between those ciphers is not the PRF hash. ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 both use a SHA-256 PRF at TLS 1.2. The only difference between them, at TLS 1.2, is the MAC. (Pre-1.2 ciphers get their PRF hashes switched to SHA-256 in 1.2.)

David


--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/247af955-049b-4941-b678-b5f4e9137571%40chromium.org.

David Benjamin

no leída,
28 oct. 2016 02:57:0428/10/16
para Jacob,net-dev,blin...@chromium.org,securi...@chromium.org
Correction: going by SSL Labs' historical ClientHellos, it looks like we did have them in Chrome 30 (also the first Chrome with TLS 1.2 per SSL Labs), but they were soon removed in Chrome 31.

Anyway, we haven't supported them for a while now. :-)

David

PhistucK

no leída,
31 oct. 2016 06:23:4431/10/16
para David Benjamin,Jacob,net-dev,blink-dev,security-dev
Chrome 28 did not. So only Chrome 29 and Chrome 30 had them.


PhistucK

On Fri, Oct 28, 2016 at 9:56 AM, David Benjamin <davi...@chromium.org> wrote:
Correction: going by SSL Labs' historical ClientHellos, it looks like we did have them in Chrome 30 (also the first Chrome with TLS 1.2 per SSL Labs), but they were soon removed in Chrome 31.

Anyway, we haven't supported them for a while now. :-)

David
On Fri, Oct 28, 2016 at 2:22 AM David Benjamin <davi...@chromium.org> wrote:
We've actually never supported those ciphers at all, so there's nothing to remove. While those ciphers do not exist in TLS 1.0 and TLS 1.1, they're still CBC-mode ciphers with all the weaknesses that entails. Use an AEAD-cipher. They're the only ciphers that are not known broken. (And indeed TLS 1.3 removes all but the AEADs.)

Aside: The difference between those ciphers is not the PRF hash. ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 both use a SHA-256 PRF at TLS 1.2. The only difference between them, at TLS 1.2, is the MAC. (Pre-1.2 ciphers get their PRF hashes switched to SHA-256 in 1.2.)

David
On Fri, Oct 28, 2016 at 2:03 AM Jacob <mcbar...@gmail.com> wrote:
Is the intent to also remove support for the ECDSA CBC-mode ciphers based on SHA2 hashing/PRF? Eg also remove:

ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Or is this only focused on the SHA1-based ciphers?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

David Benjamin

no leída,
31 oct. 2016 10:32:1831/10/16
para PhistucK,Jacob,net-dev,blink-dev,security-dev
Those ciphers require TLS 1.2 which that page says was disabled. I'm not sure what's up with that picture. Perhaps NSS didn't filter out ciphers which were inconsistent with the versions, I dunno.

Anyway, this isn't especially important. The CBC-mode construction in TLS itself is broken, so none of them should be used at this point. They are kept around purely for compatibility with legacy sites. Use an AEAD-based cipher.

On Mon, Oct 31, 2016 at 6:23 AM PhistucK <phis...@gmail.com> wrote:
Chrome 28 did not. So only Chrome 29 and Chrome 30 had them.


PhistucK

On Fri, Oct 28, 2016 at 9:56 AM, David Benjamin <davi...@chromium.org> wrote:
Correction: going by SSL Labs' historical ClientHellos, it looks like we did have them in Chrome 30 (also the first Chrome with TLS 1.2 per SSL Labs), but they were soon removed in Chrome 31.

Anyway, we haven't supported them for a while now. :-)

David
On Fri, Oct 28, 2016 at 2:22 AM David Benjamin <davi...@chromium.org> wrote:
We've actually never supported those ciphers at all, so there's nothing to remove. While those ciphers do not exist in TLS 1.0 and TLS 1.1, they're still CBC-mode ciphers with all the weaknesses that entails. Use an AEAD-cipher. They're the only ciphers that are not known broken. (And indeed TLS 1.3 removes all but the AEADs.)

Aside: The difference between those ciphers is not the PRF hash. ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 both use a SHA-256 PRF at TLS 1.2. The only difference between them, at TLS 1.2, is the MAC. (Pre-1.2 ciphers get their PRF hashes switched to SHA-256 in 1.2.)

David
On Fri, Oct 28, 2016 at 2:03 AM Jacob <mcbar...@gmail.com> wrote:
Is the intent to also remove support for the ECDSA CBC-mode ciphers based on SHA2 hashing/PRF? Eg also remove:

ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Or is this only focused on the SHA1-based ciphers?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.
Responder a todos
Responder al autor
Reenviar
0 mensajes nuevos