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

瀏覽次數:426 次
跳到第一則未讀訊息

David Benjamin

未讀,
2016年10月21日 下午2:14:362016/10/21
收件者: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

未讀,
2016年10月21日 下午2:24:062016/10/21
收件者:David Benjamin、blink-dev、net-dev、security-dev
lgtm1

Rick Byers

未讀,
2016年10月21日 下午2:59:302016/10/21
收件者:Jochen Eisinger、David Benjamin、blink-dev、net-dev、security-dev
2 affected hosts in the top million is great.  LGTM2

Chris Harrelson

未讀,
2016年10月21日 下午3:52:382016/10/21
收件者: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

未讀,
2016年10月28日 上午2:03:582016/10/28
收件者: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

未讀,
2016年10月28日 上午2:23:002016/10/28
收件者: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

未讀,
2016年10月28日 上午2:57:042016/10/28
收件者: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

未讀,
2016年10月31日 上午6:23:442016/10/31
收件者: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

未讀,
2016年10月31日 上午10:32:182016/10/31
收件者: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.
回覆所有人
回覆作者
轉寄
0 則新訊息