Intent to Deprecate: SHA-1 certificates

[Ryan Sleevi]

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 (陈智昌)]

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.

[Mike West]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[yuhong...@hotmail.com]

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

[Ben Wilson]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/c73f30b1-2c3e-4e85-9a81-5a90026b4c5e%40chromium.org.

[Ryan Sleevi]

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]

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]

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]

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.

[Jeremy Rowley]

Sorry - to clarify 1% is a large number of users to affect without giving a sufficient transition period.  The number of certs still being used for SHA1 despite the CASC's and other groups' push for SHA2 indicates that a large number of sites consider the 1% of XP SP2 users to be significant enough to make an accelerated date drastic.

On Fri, Aug 22, 2014 at 2:00 PM, <rowl...@gmail.com> wrote:

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.

--

Jeremy Rowley
Rowley Law
(801) 633-8482
rowl...@gmail.com

Please Read the Warnings Below: This e-mail and any attachments are for use by the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, please contact me and delete the message without reading it or making a copy. 

[Ryan Sleevi]

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.

[Ryan Sleevi]

And in these cases, a forced expiration date balances the risks and allows SHA-1 to be used for 16 more months.

[rowl...@gmail.com]

Looking through the minutes, I don't see an announcement about moving the deadline forward to 2016. Giving a warning for certificates that expire in 2016 effectively shifts the transition by an entire year. It's reasonable to expect CAs to follow the discussion if they aren't present, but not if teh discussion never happened!

[rowl...@gmail.com]

On Friday, August 22, 2014 2:30:42 PM UTC-6, rowl...@gmail.com wrote:
> Looking through the minutes, I don't see an announcement about moving the deadline forward to 2016. Giving a warning for certificates that expire in 2016 effectively shifts the transition by an entire year. It's reasonable to expect CAs to follow the discussion if they aren't present, but not if teh discussion never happened!

Here's the only two references to 2016 in Feb 2014:
"The Microsoft policy has two dates. It says stop issuing SHA1 on 1 January 2016 and that on 1 January 2017 it will stop recognizing SHA1 certificates."

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

[wth...@gmail.com]

Jeremy is right - CAs were notified of this policy 3 days ago. Site operators - the people who are directly affected - for the most part still know nothing. Logistically, notifying site operators and getting them to replace 600,000 certificates (that’s Google’s number, we put it at a much higher count), is extremely difficult to achieve. Case in point, Heartbleed was discovered in April of this year. It received national media attention. You couldn’t look at any website without it being discussed. About 10 weeks later, there were still 300,000 websites impacted by Heartbleed. With the intense coverage of the topic, there was still much work to be done to get it fixed.

Punishing consumers of SSL certificates that haven’t made a change to their website doesn’t feel right. Ryan states that “Microsoft has left enough room for alteration that CAs are not taking this plan seriously, and thus not beginning to transition away.” Speaking for GoDaddy – the CA identified in Google’s own data as having the largest exposure to this change – this statement is far from the truth. Netcraft data shows that 34% of GoDaddy certs now use SHA-2, up from 1% at the time of Microsoft’s announcement, a growth rate exceeding 1000%. The timing of Microsoft’s transition plan is aggressive but achievable.

Ryan is presenting this as a fight between lazy CAs and security-conscious browsers. The reality is that this change directly impacts tens of thousands of businesses who will suddenly be showing their customers a 'degraded UI indicator' despite making no changes to their website. Pushing this change out in mid-November is especially troubling timing for commerce sites.

[Alex Gaynor]

It seems to me a lot of the concern from the "lazy CA" (your words! ;-) and "business" side is predicated on the assumption that a website that doesn't change anything shouldn't have its UI degraded. This seems like a fundamentally bad assumption, given that cryptography, TLS, and the like are areas of active research, there are a great many things about a given site's TLS configuration that could reasonably make a browser want to give it a degraded UI (for example: a lack of TLS!).

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

--

"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

GPG Key fingerprint: 125F 5C67 DFE9 4084

[Ryan Sleevi]

On Fri, Aug 22, 2014 at 1:55 PM, <wth...@gmail.com> wrote:

Jeremy is right - CAs were notified of this policy 3 days ago.

Luckily, this is factually incorrect. I've below provided excerpts of our past calls and conversations, which was clear and unambiguous enough that it was recorded as such in the minutes, which are not a 1:1 transcription, but still preserve the spirit.

In a discussion of SHA-1 deprecation:

https://cabforum.org/pipermail/public/2014-March/003024.html

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

https://cabforum.org/2014/02/19/2014-02-19-minutes-of-mountain-view-f2f/#SHA1-Sunsetting-Grandfathering-Strategy

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

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

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

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

[rowl...@gmail.com]

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]

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