Intent to Deprecate: SHA-1 certificates

5844 views
Skip to first unread message

Ryan Sleevi

unread,
Aug 20, 2014, 12:52:48 AM8/20/14
to blink-dev, security-dev, net-dev

Primary eng (and PM) emails

rsl...@chromium.org


Summary

The use of SHA-1 within TLS certificates is no longer sufficiently secure. This is an intent to phase them out (in 2-3 years). In order to make such a phase-out execute smoothly, rather than be an Internet flag day, we will be degrading the experience when these certificates are used in the wild.


The following changes to Chromium's handling of SHA-1 are proposed:

- All SHA-1-using certificates that are valid AFTER 2017/1/1 are treated insecure, but without an interstitial. That is, they will receive a degraded UI indicator, but users will NOT be directed to click through an error page.

- Additionally, the mixed content blocker will be taught to treat these as mixed content, which WILL require a user action to interact with.

- All SHA-1-using certificates that are valid AFTER 2016/1/1 are treated as insecure, but without an interstitial. They will receive a degraded UI indicator, but will NOT be treated as mixed content.


Motivation

We need to execute the SHA-1 transition smoother than MD5.

MD5 was first shown weak in 1995 and was no longer recommended for new usages.

In 2004, it was near conclusively broken for most purposes, by showing it was not collision resistant.

In 2008, researchers were able to obtain a usable fraudulent certificate through MD5 manipulation from a CA.

Yet Chrome was not able to remove it until December 2011, due to it's widespread use on the Internet, and having to lead the way as one of the first browsers to do so (iOS mobile deprecated MD5 slightly earlier).


In doing so, Chrome users, particularly in enterprise scenarios, were surprised when a variety of so-called security products failed to work, often due to the security products insecure settings.


The lesson from this is that as long as it is supported, Certificate Authorities and software vendors will continue to use SHA-1. Discussions within the CA/Browser Forum have established that CAs do not view SHA-1 as a significant enough risk to begin active deprecation, in part, because any one CA that refuses to issue SHA-1 certificates is just giving customers to any other CA that will.


Despite the CA/Browser Forum's Baseline Requirements, published in 2011, recommending that SHA-1 only be used until the majority of browsers support SHA-256 (with Windows XP earlier than SP2 not supporting SHA-256 being the primary concern), CAs have still not transitioned.


Microsoft has been the first to announce hard dates - with CAs in their root program no longer being able to issue SHA-1 following 2016/1/1, and with Microsoft planning to disable SHA-1 in 2017/1/1. However, Microsoft has left enough room for alteration that CAs are not taking this plan seriously, and thus not beginning to transition away.


Without action, there is great risk that CAs will continue to issue SHA-1 certificates up until 2015/12/31, the maximum lifetime of which can be 39 months, meaning these certificates will be valid until 2019. However, before 2015/4/1, CA's may issue up to 60 months - meaning valid until 2021.


Using SHA-1 in 2020 is unacceptable. Using SHA-1 in 2015 is not desirable.


By degrading the UI, we wish to provide negative reinforcement that SHA-1 is no longer secure enough, and positive encouragement for CA's that adopt modern algorithms.


Compatibility Risk


Chromium will be the first browser to make this transition, and thus will bear the brunt of compatibility issues. However, this is precisely to avoid having significant portions of the Internet break in 2017 if CAs continue (and, based on evidence, are accelerating) the currently insecure practice.


CAs have been aware of this desire by the Chromium networking and security teams to deprecate since February 2014, and have had half a year to prepare their infrastructure and issuance pipelines. This followed Microsoft's announcement in November of 2013.


Alternative implementation suggestion for web developers

Site operators that are affected by this have several options:

  • Immediately transition to SHA-256. Users running Windows XP versions older than SP2 already are vulnerable to significant security risks, and should at least update to a modern version of XP (Microsoft Genuine checks are no longer required for XP security updates, so all users have this available).
  • Transition to a SHA-1 certificate that is not valid longer than 2015/12/31, recognizing that eventually it will be necessary to transition to SHA-256.
  • (less than ideal) Transition to a SHA-1 certificate that is not valid longer than 2016/12/31, recognizing that Chrome users will see a degraded UI.

Each of these "transition" options SHOULD, if using a respected CA, generally be a free option available to their users. Many CAs will offer users both SHA-1 and SHA-256 certificates (simultaneously), to allow the customer to transition and experiment with transitioning as necessary.


The largest risk is for users who are using certificates that have other undesirable security properties, such as unvalidated information or weaker keys (RSA keys less than 2048 bits). Because CAs MUST ensure that all new certificates conform to the Baseline Requirements, customers who purchased certificates before 2012 that were valid for extended period of times (e.g. up until 2022, as some CAs sold 10 year certs) will find they will need to be issued a new certificate, which may require additional and necessary security checks, and it will not be able to exceed the 60 month maximum validity.


Usage information from UseCounter

Based on the Certificate Transparency logs operated by Google, which records all certificates Google has seen or has had submitted to it (e.g. it includes certificates that have been revoked or discontinued, in addition to active certificates), this means the following:

SHA-1 and valid longer than 2016/1/1 - Approximately 14% of all certificates seen between 2012 and 2014 (previously, from 2012 - 2013, this was only 9.6% )

SHA-1 and valid longer than 2017/1/1 - Approximately 6.2% of all certificates seen between 2012 and 2014 (previously, from 2012 - 2013, this was only 4.13% )


Approximately 17 CAs (actual organizations, counting for acquisitions, is about 12) are responsible for 92% of the 2016 certs.

Approximately 11 CAs (closer to 7 actual organizations) are responsible for 92% of the 2017 certs.


Further details on who these CAs are is available at https://crbug.com/401365

Entry on chromestatus.com, crbug.com, or MDN

https://code.google.com/p/chromium/issues/detail?id=401365


Requesting approval to remove too?

No


Barring cryptographic advances, the plan will be to synchronize with Microsoft, and hopefully other user agents, in fully removing this in 2017. This deprecation is in alignment with those goals, with the hope that SHA-1 will be virtually unused in certificates by 2016, ensuring a smooth removal.

William Chan (陈智昌)

unread,
Aug 20, 2014, 6:45:57 PM8/20/14
to Ryan Sleevi, blink-dev, security-dev, net-dev
No one has responded, so I'm just chiming in to say that this sounds awesome to me. Carry on.


--
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/CACvaWvY69QubTnWTan62QkJjW%3D5gGbixHB9Cp8GGbq_RoMv1Og%40mail.gmail.com.

yuhong...@hotmail.com

unread,
Aug 20, 2014, 8:50:15 PM8/20/14
to blin...@chromium.org, securi...@chromium.org, net...@chromium.org, rsl...@chromium.org
"(Microsoft Genuine checks are no longer required for XP security updates, so all users have this available)."
It never was true as far as I know.

Mike West

unread,
Aug 21, 2014, 5:25:26 AM8/21/14
to William Chan (陈智昌), Ryan Sleevi, blink-dev, security-dev, net-dev
On Thu, Aug 21, 2014 at 12:45 AM, William Chan (陈智昌) <will...@chromium.org> wrote:
No one has responded, so I'm just chiming in to say that this sounds awesome to me. Carry on.

LGTM as well, for what it's worth.

In particular, the mixed content aspect of the deprecation is a nice way of ratcheting up protections for our users, and is certainly in-line with the "deprecated TLS protection" concept defined in the spec.

-mike

rowl...@gmail.com

unread,
Aug 21, 2014, 3:00:43 PM8/21/14
to securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
With rekeys, duplicates, early renewal programs, etc., I think most of the certificates valid in 2016 will be replaced well before then. Considering many CAs are working to move existing SHA1 customers to SHA2 before 2016, showing a UI degradation now will probably only serve to upset website owners rather than spur faster adoption. Most of these customers are on a set transition plan that will move them to SHA2 well before the deadline, despite having a certificate currently that extends past the end of 2015. At least consider a "window" in the validity period range where the transition will likely happen before 2016 despite a post-2016 validity period (such as March 2016). Putting the degradation on certs with a validity period past March 2016 will likely have the same effect in spurring a transition to SHA2 but let people keep their current transition plan in-tact.

Jeremy

On Tuesday,

bruce....@entrust.com

unread,
Aug 21, 2014, 4:28:09 PM8/21/14
to securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
Hi Ryan, some input.

There are 3 SHA-1 attacks that need to be considered: collision, second-preimage and preimage. SHA-1 is weak when considering a collision attack, but is not considered weak for either preimage attacks.

A collision attack can happen at the time of certificate issuance. The policy to stop issuing SHA-1 signed certificates as of January 1, 2016 mitigates the collision attack. At that time the maximum validity period will be 39 months, so all SHA-1 signed certificates will have expired by April 1, 2019.

Since collision will be mitigated, then the next attack we need to consider is second-preimage. It is unlikely that SHA-1 will be susceptible for a second-preimage attack before April 1, 2019. As such, I do not see any value in providing a degraded UI indicator.

Also, since Microsoft has stated that Windows will not support SHA-1 as of January 1, 2017; it is likely that most users will have switched to SHA-2 by then. Please note that Microsoft might change this date based on its evaluation of preimage. I would suggest that it would be of little value extending the date out past April 1, 2019 as most of the SHA-1 certificates will be expired by then.

Thanks, Bruce.

Ryan Sleevi

unread,
Aug 21, 2014, 5:09:17 PM8/21/14
to Bruce Morton, security-dev, blink-dev, net-dev, Ryan Sleevi
On Thu, Aug 21, 2014 at 1:28 PM, <bruce....@entrust.com> wrote:
Hi Ryan, some input.

There are 3 SHA-1 attacks that need to be considered: collision, second-preimage and preimage. SHA-1 is weak when considering a collision attack, but is not considered weak for either preimage attacks.

A collision attack can happen at the time of certificate issuance. The policy to stop issuing SHA-1 signed certificates as of January 1, 2016 mitigates the collision attack. At that time the maximum validity period will be 39 months, so all SHA-1 signed certificates will have expired by April 1, 2019. 

Since collision will be mitigated, then the next attack we need to consider is second-preimage. It is unlikely that SHA-1 will be susceptible for a second-preimage attack before April 1, 2019. As such, I do not see any value in providing a degraded UI indicator.

Also, since Microsoft has stated that Windows will not support SHA-1 as of January 1, 2017; it is likely that most users will have switched to SHA-2 by then.

Note that this deprecation is a direct complement to this. Microsoft's requirements for their root are no new issuances beyond January 1, 2016 - as you note, mitigating the collision.

However, after January 1, 2017 - no SHA-1 certificates will be accepted. The 2019 date is thus irrelevant for discussion.

The goal of this degraded UI is to help ensure an orderly transition away from SHA-1, by ensuring that users and site operators are aware of the number and nature of sites that will no longer work after 2017/1/1. If we allowed these certificates to be valid to 2019/4/1, then it's extremely possible (and, as shown by MD5, virtually guaranteed) that site operators and users will be completely unprepared for that 2017 date.

Internet flag days are bad for everyone involved, and we wish to avoid that.
We know that CAs are unable to effectively communicate with their users (site operators) - often due to no fault of the CA themselves, but that site operators tend to ignore emails and alerts. This is based on our experiences with deprecating RSA-1024 bit certificates, especially root certificates, in which hundreds of thousands of sites are negatively affected by and can trivially fix.

This UI policy has the effect of encouraging site operators and CAs to work towards a migration sooner (by 2016/1/1), rather than waiting until the last possible second (2017/1/1). For those that do choose to wait until the last possible second, they're at least consciously aware that they're doing so, and prepared for the 2017/1/1 shutdown date.
 
Please note that Microsoft might change this date based on its evaluation of preimage. I would suggest that it would be of little value extending the date out past April 1, 2019 as most of the SHA-1 certificates will be expired by then.

Thanks, Bruce.

Microsoft may, but I don't think we will. Microsoft's made it clear to CAs how unlikely this is, though a possibility, and what information may lead to this.

This deprecation helps both the Chromium team and other UAs, such as Microsoft and Mozilla, understand the greater scope and user impact. For example, as I mentioned in the notice, when MD5 was deprecated, though it was used on ~5% of the internet, it was significantly higher in enterprise "security" products. Unlike CAs, such vendors have virtually no incentive to take users security seriously, but their use absolutely puts Chromium users at risk (and the broader Internet), so it was a balanced tradeoff.

The net-effective of this deprecation policy is:
Site operators MUST *be prepared and aware* of the need to transition to SHA-256 by 2017/1/1
Site operators SHOULD *be prepared and aware* of the need to transition to SHA-256 by 2016/1/1. This is important, because in the event of a need to reissue a certificate (e.g. for another Heartbleed-like event, as hopefully unlikely as that may be), that is the ONLY type of the certificate they can legitimately acquire.

Our end goal with this is to ensure that no user's browsing experience is disrupted in 2016 or 2017, because the Internet will have transitioned away.

However, without these sorts of changes as proposed, all the evidence and metrics we're measuring suggest an orderly transition will not and is not happening as a whole, even if individual CAs are slowly transitioning.

Thanks for the feedback!

robin...@gmail.com

unread,
Aug 21, 2014, 9:48:22 PM8/21/14
to securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
My concern is what about the SHA-1 root certificate in OS trust store.
Google is using the root certificate come with operating system, is it also affect the SHA-1 root certificate?

Lucas Garron

unread,
Aug 21, 2014, 10:39:03 PM8/21/14
to rsl...@chromium.org, blink-dev, security-dev, net-dev
For those of us who are not involved with this, is there anywhere but bug reports where the policy/plans for certificate hashes are laid out, apart from this email?

In particular, It appears that this change would mean SHA-256 will remain the only valid hash algorithm for signatures. Is that correct?
(As far as I understand, the main known qualitative flaw of SHA-256 is that it is still subject to an extension attack. That's not directly applicable to certificate collisions, but still not desirable, I imagine.)

Are there current plans to support and/or encourage SHA-3 after it is "finalized"?

»Lucas Garron


On Tue, Aug 19, 2014 at 9:52 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Ryan Sleevi

unread,
Aug 22, 2014, 12:01:32 AM8/22/14
to robin...@gmail.com, security-dev, blink-dev, net-dev, Ryan Sleevi
As noted in the original posting, this applies to the entire chain of validated signatures.

The root certificate's signature is not validated - as it's merely a delivery mechanism for a subject name/public key pair.

So the SHA-1 certificates in the OS trust store are irrelevant, provided that the entire intermediate-and-leaf chain is of sufficient security, much in the same way that the use of MD5 in the root certificates is irrelevant.

Ryan Sleevi

unread,
Aug 22, 2014, 12:07:23 AM8/22/14
to Lucas Garron, Ryan Sleevi, blink-dev, security-dev, net-dev
On Thu, Aug 21, 2014 at 7:38 PM, Lucas Garron <crease...@gmail.com> wrote:
For those of us who are not involved with this, is there anywhere but bug reports where the policy/plans for certificate hashes are laid out, apart from this email?

security-dev / net-dev@ in general are the venues for exploring Chromium policies.

However, the more substantive meat of discussions happens typically in the CA/Browser Forum (public archive here - https://cabforum.org/pipermail/public/ ) and in the Mozilla dev.security.policy list ( https://lists.mozilla.org/listinfo/dev-security-policy ), in which much more outreach and evangelism with CAs happens.

That is, by the time it reaches security-dev@/net-dev@, it's often been discussed at length both with CAs and in the context of the public CA root program that Mozilla operates.
 
In particular, It appears that this change would mean SHA-256 will remain the only valid hash algorithm for signatures. Is that correct?

Effectively, yes.
 
(As far as I understand, the main known qualitative flaw of SHA-256 is that it is still subject to an extension attack. That's not directly applicable to certificate collisions, but still not desirable, I imagine.)

Are there current plans to support and/or encourage SHA-3 after it is "finalized"?

Similar to the earlier comments, this remains TBD, but can generally be assumed. What you'll see is a series of activities in other venues before it trickles down to Chrome. You'll see IETF publishing some form or draft describing how SHA-3 is used in the context of PKIX signatures. You'll see the CA/Browser Forum updating the Baseline Requirements (and related documents) to support SHA-3. You'll see the audit requirements derived from the CA/B Forum's documents updated to permit them. You'll see the root program requirements changed to accept them.

Somewhere in that time frame, you'll likely see implementation within Chromium to support it, although note that Chromium is currently dependent upon the OS capabilities for cert verification.

To the extent of "support and/or encourage SHA-3", the primary activity will be through Chromium engineers' involvement in the IETF, the CA/Browser Forum, and Mozilla's public root CA program, more than any explicit "Intent to Implement" on these lists.

Chris Bentzel

unread,
Aug 22, 2014, 6:52:22 AM8/22/14
to Ryan Sleevi, Lucas Garron, blink-dev, security-dev, net-dev
The plan overall sounds great, and I'm glad that it is trying to avoid
the flag day behavior.

I am a bit concerned about treating content retrieved over connections
using sha-1 signed certificates valid after 2017/1/1 as mixed-content
during the early stages of this phase-out - particularly for mixed
script which may effectively break a number of sites immediately.
Perhaps the first release or two could change the UI security
indicators and dump information to the devtools console about the
upcoming mixed-content change without actually enforcing it? This
would also let us gather information for how frequently this happens
weighted by usage (page views or some other metric).

bruce....@entrust.com

unread,
Aug 22, 2014, 9:04:26 AM8/22/14
to securi...@chromium.org, bruce....@entrust.com, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
On Thursday, August 21, 2014 5:09:13 PM UTC-4, Ryan Sleevi wrote:
> However, after January 1, 2017 - no SHA-1 certificates will be accepted. The 2019 date is thus irrelevant for discussion.
>
>
> The goal of this degraded UI is to help ensure an orderly transition away from SHA-1, by ensuring that users and site operators are aware of the number and nature of sites that will no longer work after 2017/1/1. If we allowed these certificates to be valid to 2019/4/1, then it's extremely possible (and, as shown by MD5, virtually guaranteed) that site operators and users will be completely unprepared for that 2017 date.

The issue with MD5 was that it was found to be weak to collision and some CAs did not stop signing certificates with MD5. On the other hand, MD5 still has strength against a second-preimage or preimage attack.

The way we can be different with SHA-1, is to stop issuing SHA-1 signed certificates. The CAs will stop signing with SHA-1 due to the Microsoft policy. For SSL, the preimage attacks will be mitigated as the old SHA-1 certificates expire. I do not believe that anyone is stating that there is a vulnerability to preimage in the next 5 years, which is the maximum lifetime of an SSL certificate issued today.

The browser does not need to provide warnings for SHA-1 certificates that were issued before January 1, 2016. For these certificates, the preimage attack will be mitigated by expiry.

Ryan Sleevi

unread,
Aug 22, 2014, 11:05:46 AM8/22/14
to Bruce Morton, net-dev, security-dev, blin...@chromium.org

Bruce,

These certificates will stop working after 2017. The browser absolutely can and should provide warnings.

As I am sure you are well aware, nothing in the CA/Browser Forum's requirements require that a CA place the issuance date in the notBefore. While this is expected by common sense, we regularly see CAs fudge this number - for both legitimate (easing interoperability with machines with slightly-off clocks) and illegitimate (to avoid additional checks imposed by browsers) means.

I think where your idea is flawed is that it assumes the UA can reasonably and reliably detect 'when' a certificate is issued. This is not and has never been the case - for certificates that conform to the Baseline Requirements or for certificates issued by internal CAs and security software.

As shown by MD5, the ONLY way to get software and CAs to transition away from issuing SHA-1 certs is to actually disable it. This notice phase serves as a way of informing users and site operators of coming changes - changes 2-3 years away, and changes not just being made by Chromium, but other UAs as well.

b...@digicert.com

unread,
Aug 22, 2014, 12:55:29 PM8/22/14
to securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
If the downgraded UI is the https with the red slash through it, doesn't that go too far in providing a warning? In other words, if I saw it, I would think that there was something more severely wrong with the website's SSL certificate or the encryption behind it, etc. So far, SHA1 has not been broken, at least publicly. My understanding is that we're just trying to accelerate migration away from SHA1. So I would think a less severe UI downgrade would be better than the red slash.
Thanks,
Ben Wilson

Ryan Sleevi

unread,
Aug 22, 2014, 1:11:42 PM8/22/14
to b...@digicert.com, net-dev, security-dev, blin...@chromium.org


On Aug 22, 2014 9:55 AM, <b...@digicert.com> wrote:
>
> If the downgraded UI is the https with the red slash through it, doesn't that go too far in providing a warning?  In other words, if I saw it, I would think that there was something more severely wrong with the website's SSL certificate or the encryption behind it, etc. 

That's not the case for most users, but it sounds like you're agreeing that its bad, just disagreeing on the UX.

Chromium has a UI for 'origins that attempt to be secure (HTTPS) but are not secure'. Its a red lock with strike through. This is a UX issue for Chromium.

> So far, SHA1 has not been broken, at least publicly.

There are graduations of broken. It's not binary.

What we do see is that SHA-1 is showing the same set of weaknesses at MD5, and multiple rounds of weakening that allow an attacker to create colliding blocks.

It's not YET as computationally easy as MD5, at least from the public research, but that's irrelevant with respect to whether we need to transition. This is especially true based on the fact that the Flame malware (2012), which also exploited MD5 collisions, used methods that were entirely unknown to the public as being weak.

>  My understanding is that we're just trying to accelerate migration away from SHA1.  So I would think a less severe UI downgrade would be better than the red slash.
> Thanks,
> Ben Wilson
>

Given how easy it is for sites and CAs to mitigate this issue with zero compatibility issues, I think this is unnecessary.

The fundamental question is whether we (Chromium) view SHA-1 as secure enough to be worthy of a secure indicator.

That answer from everyone involved on the Chromium side is no, although its clear for some CAs on this thread they think the answer should be 'yes'. This is not surprising, as its the cause of the impasse in the CA/Browser Forum.

We had hoped to see this practice stop in 2012, as the Baseline Requirements so strongly encouraged, so it's not that we have not made repeated attempts to work with CAs on timelines.

Chris Palmer

unread,
Aug 22, 2014, 1:25:33 PM8/22/14
to Ryan Sleevi, Lucas Garron, blink-dev, security-dev, net-dev
On Thu, Aug 21, 2014 at 9:07 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

>> For those of us who are not involved with this, is there anywhere but bug
>> reports where the policy/plans for certificate hashes are laid out, apart
>> from this email?
>
> security-dev / net-dev@ in general are the venues for exploring Chromium
> policies.

Additionally, keep an eye on these 2 "forever" bugs:

https://code.google.com/p/chromium/issues/detail?id=102949

https://code.google.com/p/chromium/issues/detail?id=119213

It's an on-going effort to enforce, at run-time, as much tightness in
cryptographic parameters as is possible. Also, to ratchet upward.

tshi...@trustwave.com

unread,
Aug 22, 2014, 1:31:30 PM8/22/14
to securi...@chromium.org, robin...@gmail.com, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
On Friday, August 22, 2014 12:01:29 AM UTC-4, Ryan Sleevi wrote:
> As noted in the original posting, this applies to the entire chain of validated signatures.

Can we clarify if the date checks apply only to the end-entity certificates? Or do they also apply to the intermediates? If the latter, that would require new SHA-1 intermediates to be issued with 2015-12-31 expiration dates in order to offer the option of a shorter-term SHA1-signed certificate to customers.

Ryan Sleevi

unread,
Aug 22, 2014, 1:39:27 PM8/22/14
to tshi...@trustwave.com, net-dev, security-dev, blin...@chromium.org, robin...@gmail.com

The evaluation is described in the linked bug.

Only the leaf certificates notAfter is considered (and independent of leaf signature algorithm), but if it matches the criteria, then all the validated signatures in the chain (i.e. excluding the root) are considered.

No new intermediates are required, unless you are issuing long-lived SHA-256 certs that chain to a SHA-1 intermediate.

Ben Wilson

unread,
Aug 22, 2014, 1:59:04 PM8/22/14
to securi...@chromium.org, b...@digicert.com, net...@chromium.org, blin...@chromium.org, rsl...@chromium.org

Is there a web page where someone can take a look at all of Chrome's address-bar security-related traffic signs (i.e. small image files)? 

Thanks,

Ben

ni...@cloudflare.com

unread,
Aug 22, 2014, 3:11:32 PM8/22/14
to securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
This timeline for deprecating SHA-1 is very aggressive and puts us
(CloudFlare) in a bind.

Currently we provide certificates to our customers signed by GlobalSign's
SHA-1 intermediate, with a 3 year expiration (i.e. all customer certificates
from this year are valid for part of 2017). We still use these SHA-1 certificates
because a large percentage of the web visitors of our customers are using
Windows XP SP2 which does not support SHA-256. It's not realistic to expect
everyone to be able to upgrade to SP3.

This change will force our customers to have to choose between having a
mixed content warning on Chrome or cutting off a large portion of their
visitor base.

Can we please delay this move until at least next year?

Matt Menke

unread,
Aug 22, 2014, 3:18:29 PM8/22/14
to ni...@cloudflare.com, security-dev, blin...@chromium.org, net-dev, Ryan Sleevi
Is there a reason to think the situation will be significantly different in 4 months?  Seems unlikely to me.  XP SP3 has been out for 6 years now.


--
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.

Ryan Sleevi

unread,
Aug 22, 2014, 3:19:01 PM8/22/14
to ni...@cloudflare.com, net-dev, security-dev, blin...@chromium.org

Nick,

We've been communicating this to CAs for some time. I'm sorry that GlobalSign hasn't been passing that on.

As mentioned, if you set your expiration for these CloudFlare hosted certs to be 2015/12/31, you will receive no warnings.

After 2016/1/1, no CA is allowed to issue SHA-1 certificates. As such, all sites SHOULD be prepared to switch (e.g. for emergency purposes such as Heartbleed or CA compromise).

That still gives you more than a year to test and help migrate.

I do take issue with the definition of 'a large percentage'. Evidence suggests this is a quite small percent (<= 1%), and large sites have already transitioned (Twitter) or are in the process of transitioning.

Nick Sullivan

unread,
Aug 22, 2014, 3:37:23 PM8/22/14
to rsl...@chromium.org, net-dev, security-dev, blin...@chromium.org
Hi Ryan,

Re-issuing every one of our client certificates is not a trivial task. Being forced to do so in the next few weeks without warning is not something we (or many other sites) were prepared for. I'm sure we are not the only ones who would appreciate a delay in this change.

Many of the sites that use our services have user bases in geographical locations where cutting off XP SP2 is just not a feasible option this year. For some sites, the percentage is much higher than 1%. Hopefully this situation will resolve itself within two years, but it will not be resolved in 6-12 weeks.

Nick

Ryan Sleevi

unread,
Aug 22, 2014, 3:49:00 PM8/22/14
to Nick Sullivan, Ryan Sleevi, net-dev, security-dev, blink-dev
Hi Nick,

CAs were told about these plans 6 months ago, in order to help their customers prepare and move off. We waited for this long precisely because CAs at the time indicated they took the matter seriously and knew this was coming.

As Matt mentioned, XP SP3 has been out for 6 years. What do you think will change in the next 4 months - or the next 4 years - that hasn't already happened?

Short of CAs stopping issuing SHA-1 certs (which the evidence is that there is no such rush occurring, despite widespread agreement even in 2009 on the risks of continuing the current path), I don't see what will change. CAs have continued to use XP SP2 as the justification for years now, but I think we're well beyond the point in which that explanation holds muster (e.g. we're well into the long-tail now).

I also find disconcerting your answer that you're not prepared for large-scale re-issuance. This was something that has already shown to be necessary this year (Heartbleed), and something that's inevitable with further cryptoanalytic advances in SHA-1 (e.g. the very thing we're trying to avoid en masse).

Knowledge of SHA-1 deprecation by Microsoft has been out for nearly a year. Can you share what, if any, steps CloudFlare has taken to support that?

To be clear, I'm not trying to be dismissive of your concerns. However, the ecosystem is precarious here, with CAs continually unwilling to take the first step unless all CAs do, and enough CAs refuse to do so, preventing any meaningful security improvements. It was necessary in 2011 for Chrome to take the first step in disabling MD5, despite years of undeniable evidence of its insecurity. I cannot help but feel we're at that point with SHA-1 as well, and the proposed plan balances the trade-offs to users (we don't want to require interstitials), to site operators (they can continue using SHA-1 through 2016 without any effect, and 2017 with degraded UI), and to CAs (who, despite having significant advance notice, have not meaningfully moved)

As a prime example, even discussions to simply require that CA's offer SHA-256 by default to all new customers, and require the customer to explicitly request SHA-1 (such as for situations like you describe) have been outright rejected, repeatedly, by CAs. I think we've made every good-faith effort to avoid surfacing UI, but if we continue the present course and continue to delay action, then we're only leaving our users more at risk, and making the situation even more and more guaranteed of mutually assured trouble for users.

rowl...@gmail.com

unread,
Aug 22, 2014, 4:00:10 PM8/22/14
to securi...@chromium.org, ni...@cloudflare.com, net...@chromium.org, blin...@chromium.org, rsl...@chromium.org
Can you provide a link to the communication with CAs, Ryan? I don't recall seeing anything that explained any of the proposed Chrome changes. As far as I knew, Chrome was planning on following the Microsoft deadline of 2017, not accelerating the date to 2016. I think the sheer volume of 2016 certificates suggests the number is quite large, not a small percent.

Ryan Sleevi

unread,
Aug 22, 2014, 4:05:23 PM8/22/14
to rowl...@gmail.com, Nick Sullivan, net-dev, securi...@chromium.org, blin...@chromium.org

Sure.

This was discussed for around an hour/hour and a half during the CA/Browser Forum's February 2014 meeting, hosted by Google in Mountain View.

The minutes are available at cabforum.org and were sent to the CA/B Forum's place.

Given that all CAs are expected to adhere to the Baseline Requirements, which are developed in the CA/B Forum, it is reasonably expected that CAs are following the discussion, even when they are not directly contributing.

rowl...@gmail.com

unread,
Aug 22, 2014, 5:55:21 PM8/22/14
to securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org

Those links don't show disclosure of a new 2016 deadline. In fact, they support the CA's understanding of Jan 1 2017 as the deprecation date:


"Chrome's plan continues to remain aggressive - disallowing certain algorithms/key sizes if their issuance date is after their sunset-grace period, outright rejecting them if their validity period exceeds the sunset-fail period, and eventually outright removing support entirely. As such, a CA that (continues) to issue such certs would not (ultimately) be causing outright risk to *current* versions of Chrome users"

[JR] The sunset-fail period is 2017, not 2016.

"Ryan: <snip> It goes back to attempting what we believe is a balanced approach for the user experience by telling the user that we don’t have full confidence in this site but allowing the user to proceed, but this may become more serious over time. So we’ll transition the user by not giving an EV indication. We’re also not going to require users to click through warnings."

[JR] Again, this is about 2017.


"Ryan: This pushes support to the browsers because when a site operator does not switch over to SHA2 people will say the browser doesn’t work. So, regardless of the sunset date, we’ll have to start taking away your security benefits soon, but it would be better to find a solution based on policy. If we cannot come to agreement on policy, like Brian said, then we are going to have different approaches, but we cannot have a situation where we’re going to allow CAs to run SHA1 certificates up the wire and pass the cost on to the browsers. The reality is that when a site breaks, it is not the site operator that suffers, it’s the users, and users don’t contact the site operator, they contact the browser or they go on social media and complain."

[JR] This is about certificates that expire after the 2017 deadline.

"Ryan: It is all fine that we as a CA/Browser Forum can agree on something, but we need to get the attention of site operators and users on this. If January 2016 is the date that CAs cease issuing SHA1 certificates, but site operators are installing 3-year certificates until then, we’re going to see problems when they have forgotten about it. If we cannot resolve this in the CA/Browser Forum, it will be something the browsers will start working on to get that messaging out."

[JR] It says right in this section that the date CAs are supposed to stop issuing is 2016. The deprecation date for use is 2017.

"Bob: Ryan has said that in Chrome they will implement a countdown meter that tells end users that in X days the website will stop working because the server has not migrated from SHA1.

[JR] Referencing certificates that expire in 2017.

rowl...@gmail.com

unread,
Aug 22, 2014, 5:58:45 PM8/22/14
to securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
Alex,

The point is not that there shouldn't be a degraded UI for the 2017 deadline. The concern is that Google has suddenly accelerated the deadline to 2016 immediately after customers and CAs developed transition plans based on the 2017 deadline previously discussed.

Jeremy

Ryan Sleevi

unread,
Aug 22, 2014, 6:20:29 PM8/22/14
to Jeremy Rowley, security-dev, blink-dev, net-dev, Ryan Sleevi
On Fri, Aug 22, 2014 at 2:55 PM, <rowl...@gmail.com> wrote:

Those links don't show disclosure of a new 2016 deadline.  In fact, they support the CA's understanding of Jan 1 2017 as the deprecation date:


"Chrome's plan continues to remain aggressive - disallowing certain algorithms/key sizes if their issuance date is after their sunset-grace period, outright rejecting them if their validity period exceeds the sunset-fail period, and eventually outright removing support entirely. As such, a CA that (continues) to issue such certs would not (ultimately) be causing outright risk to *current* versions of Chrome  users"

[JR] The sunset-fail period is 2017, not 2016.

Hi Jeremy,

I'm sorry that this was not clear to you. It was clear to Bob, and considering the duration we discussed in (during the F2F and later during our calls), it was hoped this was clear.

The original plan from February - one which we backed off of precisely based on CA feedback - was that any SHA-1 certificate with a validity after 2017 would be outright rejected. This is noted above.

As Bob's comment notes, it was also clear that the degraded UIwhich would not require direct user action, was something that would begin before then. As discussed during the F2F, this was proposed as 2016, the point in which CAs could no longer issue such certificates.

I do want to reiterate, none of this is with the goal to 'penalize' anybody. It's to make sure that users and site operators are aware that 2017 is a date that SHA-1 MUST be deprecated. As we have heard from other CAs, and even from organizations such as CloudFlare, that's a position that's not being accurately or honestly reflected in the certificates being issued today, and that represents a real danger to being able to effectively deprecate SHA-1.

As I noted in my original mail, we saw this same issue with MD5, preventing it from being disabled. This cannot be allowed to happen again - leaving users vulnerable for five years to real and practical attacks, with no mitigations (other than those adopted AFTER researchers demonstrated how trivial it was, for which we can and should reasonably infer it was in use by attackers BEFORE then)

If this were a proposal to interstitial users, which was the original plan, I can absolutely understand and appreciate the hesitation. However, this is about making sure that Chrome's security UI accurately reflects the views of the Chromium developer community, and the greater cryptographic community at large, as to what represents acceptable security/risk. In 2011, CAs also agreed of the risks posed, so it's surprising to hear them so downplayed now.

There are plenty of options for mitigations of this, but I think the core element is this, and was noted by Chris Palmer earlier: The age of having a secure UI remain static for five years is no longer tenable. It is expected that sites be able to respond to and adapting to security threats. This applies whether you're talking about TLS protocol level attacks like BEAST, cryptographic attacks like those involved in certificate issuance, or application-level attacks such as mixed content.

For the vast majority of our users, security is a one-or-two bit state, not the gradiations that CAs may see. In this model, we need to accurately reflect to the user whether or not we believe they're secure.

Using SHA-1 is not something we believe is secure. We won't require the user to take make a decision immediately - that's not for another two and a half years - but we also won't and cannot bestow a secure indicator just because we always did. This plan has directly taken feedback from CAs and already delayed it (by 6 months) and softened it (by not interstitialling). This represents a reasonable compromise between the interests at play.

At present, the plan is to roll this out roughly over 12 weeks - that's three full months for CAs and sites to prepare. If this was being rolled out tomorrow to stable users, I can understand the concern. But I think this represents a generous time for sites to be notified and prepare. If a site is not capable of changing its cert within 12 weeks, then I think we have a far more serious security problem - as Heartbleed as taught us.

rowl...@gmail.com

unread,
Aug 22, 2014, 6:32:22 PM8/22/14
to securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
I understand the UI degradation context before 2017, but the comments surrounding the degradation all indicated the UI degradation was going to happen only to certs valid past the 2017 deadline.

I was expecting a degradation now for certs still valid in 2017 but affecting certs valid in 2016, especially when the previous policy was that SHA-1 certs could be issued until 2016, seems like a sudden change.

Brian Smith

unread,
Aug 22, 2014, 11:23:47 PM8/22/14
to Ryan Sleevi, blink-dev, security-dev, net-dev
On Tue, Aug 19, 2014 at 9:52 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> The following changes to Chromium's handling of SHA-1 are proposed:

[snip]

I think this is a very cool proposal.

It seems like the proposal only deals with SHA-1 signatures used in
certificates' signatures, but it doesn't say anything about SHA-1 use
in the signatures of the TLS ServerKeyExchange message. It may be
useful to say what, if anything, you are planning to do change
regarding SHA-1- or SHA-1+MD5- signed ServerKeyExchange messages, and
on what timeline. Similarly, it would be interesting to here your
plans, if any, regarding changing the values delivered in the TLS
signature_algorithms extension to advertise that SHA-1 is no longer
supported. Note, in particular, that SHA-1(+MD5) signatures MUST be
used in TLS 1.1 and earlier, so potentially there could be
version-specific policies regarding this. And, also note that even TLS
1.2 (weakly) encourages SHA-1 to be used for signatures when the
server certificate's keypair is a DSA keypair.

More below.

> Site operators that are affected by this have several options:
>
> * Immediately transition to SHA-256. Users running Windows XP versions older
> than SP2 already are vulnerable to significant security risks, and should at
> least update to a modern version of XP (Microsoft Genuine checks are no
> longer required for XP security updates, so all users have this available).
>
> * Transition to a SHA-1 certificate that is not valid longer than 2015/12/31,
> recognizing that eventually it will be necessary to transition to SHA-256.
> (less than ideal)
>
> * Transition to a SHA-1 certificate that is not valid longer
> than 2016/12/31, recognizing that Chrome users will see a degraded UI.
>
> Each of these "transition" options SHOULD, if using a respected CA,
> generally be a free option available to their users. Many CAs will offer
> users both SHA-1 and SHA-256 certificates (simultaneously), to allow the
> customer to transition and experiment with transitioning as necessary.

It may be useful to suggest a specific instance of such an
experimental transition plan of using SHA-1 and SHA-256 certificates
simultaneously:

* Acquire both SHA-1 and SHA-256 certificate chains from the
certificate authority.

* Deploy TLS 1.2 with support for the dowgrade SCSV [1] configured to
prevent insecure fallback to versions prior to TLS 1.2 for browsers
that support TLS 1.2 and the downgrade SCSV. This way, you can rely on
the signature_algorithms TLS extension, which is not sent in versions
prior to TLS 1.2.

* Configure the server's TLS stack to work as follows: If the client
sent the signature_algorithms extension and it indicates support for
SHA-2-based signatures, then use the SHA-256-based certificate chain.
Otherwise, use some (currently-unspecified) heuristics based on the
information in the ClientHello message to determine whether to send a
SHA-2-based or SHA-1-based certificate chain. Preferably, default to
SHA-256 when the heuristics fail.

Pros:

1. More servers would start using SHA-256-based certificate chains
sooner with modern (TLS-1.2-capable) browsers, by immediately (as soon
as servers support the mechanism) eliminating the risk of
experimenting with SHA-256-based certificate chains.

2. This would encourage quicker deployment of
draft-bmoeller-tls-downgrade-scsv-02.

3. This may (should!) alleviate current concerns of CAs and others
that are already concerned about your proposal.

4. Encouraging server vendors to add support for this option ASAP
reduces the amount of last-minute resistance by website administrators
you will experience when their websites actually start being
negatively impacted.

Cons: This may encourage CAs to keep minting SHA-1 certificates and/or
it may encourage them to mint them with longer validity periods,
whereas they may making a sharper transition to SHA-256 if my
suggestion weren't an option.

Again, I think your proposal is great. I hope you find these
suggestions helpful.

Cheers,
Brian

[1] http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-02 on
the server

Ryan Sleevi

unread,
Aug 22, 2014, 11:43:06 PM8/22/14