Primary eng (and PM) emails
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.
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.
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:
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.
Requesting approval to remove too?
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.
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.
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.
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"?
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.
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.
> 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.
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.
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)?
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.
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.
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.
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.
And in these cases, a forced expiration date balances the risks and allows SHA-1 to be used for 16 more months.