This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately. This Intent is to trim the signature algorithms we advertise for the online signature in the TLS protocol itself.
Primary eng (and PM) emails
Summary
In most modes, TLS 1.2 uses a signature in the ServerKeyExchange message to prove ownership of the private key. There is an extension, signature_algorithms, to negotiate which signature algorithms are acceptable. We intend to remove ECDSA with SHA-1 and ECDSA with SHA-512, leaving SHA-256 and SHA-384 for ECDSA.
Motivation
SHA-1 signatures should not be used. While SHA-1 signatures in certificates are on the way out, SHA-1 is still accepted in the online signature. ECDSA with SHA-1 is virtually nonexistent in the ecosystem, so we intend to remove it. Between RSA/SHA-1 and TLS 1.0/1.1 (both sadly far too widespread to remove at this time), this change will not remove the dependency on SHA-1 for the online signature. But by ratcheting where we can, we hope to help avoid the ecosystem regressing.
Removing SHA-512 signatures with ECDSA is less obvious. However, we only support P-256 and P-384 for ECDSA curves, neither of which admit hashes that large. Hashes larger than SHA-256 (respectively, SHA-384) signed with P-256 (respectively, P-384) get truncated to size, so the larger hash is not useful. Moreover, TLS 1.3 will prohibit ECDSA curve/hash mismatches, so this change aligns our TLS 1.2 and 1.3 advertisements.
Compatibility Risk
Algorithms are negotiated, so server software should automatically select a more suitably-sized hash. 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.
Measurements also suggest this is a very low-risk change. See metrics below.
As always, we will monitor the error rate as this change progresses and react to any unforeseen issues.
Alternative implementation suggestion for server administrators
Sign a more suitably-sized hash. Server software should do this automatically and, unlike cipher suites, this is rarely configured (sometimes not even configurable), so no action should be necessary.
We are aware of a bug in OpenSSL, fixed in 2014, which causes some server configurations to only sign SHA-1. There have been several OpenSSL security advisories since then, so administrators are recommended to update regardless. LibreSSL imported the fix in their most recent releases in September 2016. These releases also carry fixes for a recent OpenSSL security advisory, so administrators are recommended to update regardless.
Usage information from UseCounter
ECDSA with SHA-1 usage currently rounds to 0.00% of TLS 1.2 connections. Further, a crawl of top million hosts in Alexa found 54 of 58 SHA-1-signing ECDSA hosts will sign another algorithm when SHA-1 is not advertised so the impact is expected to be lower than measured. We’ll reach out to the remaining 4.
ECDSA with SHA-512 is harder to evaluate. OpenSSL and derivatives are common and preferentially sign the largest hash available, regardless of curve size. However, they all can sign SHA-256 and SHA-384. The same crawl found zero which would break. SSL Labs reports Safari on macOS and iOS do not advertise ECDSA with SHA-512, so any affected sites would also fail to load in those clients.
OWP launch tracking bug
Entry on the feature dashboard
https://www.chromestatus.com/feature/5725838074970112
Requesting approval to remove too?
Yes
> This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately.
> This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately.
While it doesn't impact what certificates the client accepts, will it impact the certificates the server is willing to serve? E.g. https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI implies that IIS was once failing connections that had SHA-512 in the certificate chain if the client didn't advertise support for that in signature_algorithms.
--
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.
--
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.
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/CAOMQ%2Bw9rJ515nhZr_SjkfZjJ5bU6BZjcpvOra--NKVKjhWv%3DnQ%40mail.gmail.com.
Non-owner's LGTM. I agree with your assessment of the risk of dropping these signatures from those we advertise, and aligning with TLS 1.3 requirements now seems like a good-enough justification to proceed.-mikeOn Fri, Oct 14, 2016 at 12:41 AM, Chris Harrelson <chri...@chromium.org> wrote:
LGTM1
On Thu, Oct 13, 2016 at 3:18 PM, David Benjamin <davi...@chromium.org> wrote:
On Thu, Oct 13, 2016 at 5:13 PM Eric Lawrence <bay...@gmail.com> wrote:> This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately.
While it doesn't impact what certificates the client accepts, will it impact the certificates the server is willing to serve? E.g. https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI implies that IIS was once failing connections that had SHA-512 in the certificate chain if the client didn't advertise support for that in signature_algorithms.IIS will attempt to match the sent certificates against signature_algorithms, yeah. Most other server software I know of doesn't. OpenSSL only does it starting 1.0.2 and, even then, only if you explicitly enable it.I'd also found no ECDSA/SHA-1 or ECDSA/SHA-512 certificates in CT logs. Plus changes made now won't hit the stable channel until 2017, so I believe after the date when SHA-1 certificates are planned to be distrusted anyway.David
--
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+...@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.
Non-expert LGTM2.
On Fri, Oct 14, 2016 at 11:12 AM Mike West <mk...@chromium.org> wrote:
Non-owner's LGTM. I agree with your assessment of the risk of dropping these signatures from those we advertise, and aligning with TLS 1.3 requirements now seems like a good-enough justification to proceed.-mikeOn Fri, Oct 14, 2016 at 12:41 AM, Chris Harrelson <chri...@chromium.org> wrote:
LGTM1
On Thu, Oct 13, 2016 at 3:18 PM, David Benjamin <davi...@chromium.org> wrote:
On Thu, Oct 13, 2016 at 5:13 PM Eric Lawrence <bay...@gmail.com> wrote:> This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately.
While it doesn't impact what certificates the client accepts, will it impact the certificates the server is willing to serve? E.g. https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI implies that IIS was once failing connections that had SHA-512 in the certificate chain if the client didn't advertise support for that in signature_algorithms.IIS will attempt to match the sent certificates against signature_algorithms, yeah. Most other server software I know of doesn't. OpenSSL only does it starting 1.0.2 and, even then, only if you explicitly enable it.I'd also found no ECDSA/SHA-1 or ECDSA/SHA-512 certificates in CT logs. Plus changes made now won't hit the stable channel until 2017, so I believe after the date when SHA-1 certificates are planned to be distrusted anyway.David
--
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.
--
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.
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/CAOMQ%2Bw9rJ515nhZr_SjkfZjJ5bU6BZjcpvOra--NKVKjhWv%3DnQ%40mail.gmail.com.
What is solution over ECDSA with SHA-512 signature algorithms?
In our environment, we generated the certificate SHA-512 ECDSA Algorithm. It is supported for latest Google Chrome Version i.e 76.0.3809Whenever we change the SSL certificate URL does not work in latest google chrome version. Kindly provide the solution for this issue.
Our application URL is working in all IE and Google Chrome versions with old certificate i.e Signature Algorithm is "sha256RSA".And we have made changes in new certificate as for Signature Algorithm is "sha512ECDSA". When binding such certificate to application site, URL does not open in new Google chrome version <63.00 version.
Sorry for typo mistake, as per my scenario its worked in lower version of google chrome (below ver 63) and URL not able to open in latest google chrome version (above ver 63). What should I do?