Intent to Deprecate: SHA-1 certificates
Ryan Sleevi
Primary eng (and PM) emails
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.
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 (陈智昌)
--
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
Mike West
No one has responded, so I'm just chiming in to say that this sounds awesome to me. Carry on.
rowl...@gmail.com
Jeremy
On Tuesday,
bruce....@entrust.com
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
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.
robin...@gmail.com
Google is using the root certificate come with operating system, is it also affect the SHA-1 root certificate?
Lucas Garron
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
Ryan Sleevi
Ryan Sleevi
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"?
Chris Bentzel
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
> 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 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
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
>> 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.
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
> As noted in the original posting, this applies to the entire chain of validated signatures.
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.
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
(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
--
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
Ryan Sleevi
rowl...@gmail.com
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.
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
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
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.
rowl...@gmail.com
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
> The following changes to Chromium's handling of SHA-1 are proposed:
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:
>
> 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).
>
> (less than ideal)
>
>
> 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.
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
On Tue, Aug 19, 2014 at 9:52 PM, Ryan Sleevi <rsl...@chromium.org> wrote:[snip]
> The following changes to Chromium's handling of SHA-1 are proposed:
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.
David Benjamin
Yeah, luckily the number of (valid) DSA certificates is extremely low. If I recall the data from 2013 correctly, it was on the order of 'several hundred', although this could easily be confirmed by the CT logs.
Doug Beattie
Ryan,
We all agree with firm dates for deprecating SHA-1 and moving to SHA-2, but the logic and dates Google has specified give web site operators little time to react.
On Thursday, August 21, 2014 5:09:13 PM UTC-4, Ryan Sleevi wrote:
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.
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.
Ryan Sleevi
On Aug 25, 2014 7:03 AM, "Doug Beattie" <douglas...@gmail.com> wrote:
>
> Ryan,
>
> We all agree with firm dates for deprecating SHA-1 and moving to SHA-2, but the logic and dates Google has specified give web site operators little time to react.
>
Doug,
It seems extremely misleading to suggest 9 months is insufficient time.
Let's be clear: we both know that there are CAs that actively campaigned for 2017 as unrealistic, and instead have (and in some cases, continue to) argue for 2020 or later.
This is such a common occurrence that it continues to delay or prevent any meaningful improvements to online security.
Regarding proposals for examining notBefore as an issuance date - as you know, this fails to meaningfully address any of the security concerns. We have discussed in the CA/Browser Forum why it doesn't work, and it's been discussed above why it doesn't work - in particular, CAs are not required to be honest in them, and in the vast majority of cases, are not honest in them. Using information like this for security decisions fails to consider that reality.
While I appreciate your alternative proposal, for reasons that were explained six months ago, and reasons explained earlier on this thread, that timeline doesn't align with the goal, and just serves to kick this exact same conversation of "not enough time / not enough warning" down the road.
What I haven't seen is any dispute to the following:
- By 2016/1/1, CAs may no longer issue SHA-1 certificates. Sites which rely on these certificates (e.g. for XP SP2) WILL NOT be able to obtain any new certificates, WILL NOT be able to respond to security incidents, and WILL NOT be able to make any changes or correct any information.
- By 2017/1/1, these sites WILL NOT work.
If we did as you'd propose, the 2016 users will have zero warning, and the 2017 users will have less than a year, and we would be having this exact same conversation about not enough time and proposing delays. What's worse, it would have the exact effect we are trying to avoid, of having 2017 be a flag day.
To be clear, in 2017/1/1, these certificates will not work. It is not a degraded UI (as you proposed), but an indistinguishable from untrusted certificate. This is significant enough to merit advance communication - which this deprecation notice is.
I don't mean this as a hypothetical - we very much saw this play out for 5 years with MD5, as CAs continued to suggest SHA-1 wasn't needed, and mitigations like entropy in the serial was sufficient.
In this proposal, no penalties are being taken against the CA. No CA is being found in violation of our root or EV policies, and no CA is risking removal wholesale. This is merely a UI update, one which doesn't require user action, that reflects the security views and best practices, which, again, CAs agreed upon and recognized this view as far back as 2011.
This is fundamentally no different than Chrome using UI to communicate other insecure CA practices that, despite every effort, continue to be used well beyond when it is safe. For example, the insecure inclusion of unverifiable domain names (also called internal server names), which has caused significant risk to the CA's users - and the Internet at large - as ICANN delegates new TLDs. Indeed, many of these same discussions were had, and worse, the timelines continually attempted to be pushed back or altogether dismissed.
It is important that Chrome, for which security has been a foundational pillar of the design, accurately and honestly reflect the security status of the page. The exact details are generally left to our security and UX teams, which have seen this as a reasonable balance between requiring the user to take direct action (via a security interstitial) and the misleading and downright status quo - of doing nothing.
rowl...@gmail.com
- By 2016/1/1, CAs may no longer issue SHA-1 certificates. Sites which rely on these certificates (e.g. for XP SP2) WILL NOT be able to obtain any new certificates, WILL NOT be able to respond to security incidents, and WILL NOT be able to make any changes or correct any information.
- By 2017/1/1, these sites WILL NOT work.
If we did as you'd propose, the 2016 users will have zero warning, and the 2017 users will have less than a year, and we would be having this exact same conversation about not enough time and proposing delays. What's worse, it would have the exact effect we are trying to avoid, of having 2017 be a flag day.
To be clear, in 2017/1/1, these certificates will not work. It is not a degraded UI (as you proposed), but an indistinguishable from untrusted certificate. This is significant enough to merit advance communication - which this deprecation notice is.
This is fundamentally no different than Chrome using UI to communicate other insecure CA practices that, despite every effort, continue to be used well beyond when it is safe. For example, the insecure inclusion of unverifiable domain names (also called internal server names), which has caused significant risk to the CA's users - and the Internet at large - as ICANN delegates new TLDs. Indeed, many of these same discussions were had, and worse, the timelines continually attempted to be pushed back or altogether dismissed.
It is important that Chrome, for which security has been a foundational pillar of the design, accurately and honestly reflect the security status of the page. The exact details are generally left to our security and UX teams, which have seen this as a reasonable balance between requiring the user to take direct action (via a security interstitial) and the misleading and downright status quo - of doing nothing.
Doug Beattie
On Monday, August 25, 2014 10:38:55 AM UTC-4, Ryan Sleevi wrote:
On Aug 25, 2014 7:03 AM, "Doug Beattie" <douglas...@gmail.com> wrote:
>
> Ryan,
>
> We all agree with firm dates for deprecating SHA-1 and moving to SHA-2, but the logic and dates Google has specified give web site operators little time to react.
>Doug,
It seems extremely misleading to suggest 9 months is insufficient time.
Let's be clear: we both know that there are CAs that actively campaigned for 2017 as unrealistic, and instead have (and in some cases, continue to) argue for 2020 or later.
This is such a common occurrence that it continues to delay or prevent any meaningful improvements to online security.
Regarding proposals for examining notBefore as an issuance date - as you know, this fails to meaningfully address any of the security concerns. We have discussed in the CA/Browser Forum why it doesn't work, and it's been discussed above why it doesn't work - in particular, CAs are not required to be honest in them, and in the vast majority of cases, are not honest in them. Using information like this for security decisions fails to consider that reality.
While I appreciate your alternative proposal, for reasons that were explained six months ago, and reasons explained earlier on this thread, that timeline doesn't align with the goal, and just serves to kick this exact same conversation of "not enough time / not enough warning" down the road.
What I haven't seen is any dispute to the following:
- By 2016/1/1, CAs may no longer issue SHA-1 certificates. Sites which rely on these certificates (e.g. for XP SP2) WILL NOT be able to obtain any new certificates, WILL NOT be able to respond to security incidents, and WILL NOT be able to make any changes or correct any information.
- By 2017/1/1, these sites WILL NOT work.
If we did as you'd propose, the 2016 users will have zero warning, and the 2017 users will have less than a year, and we would be having this exact same conversation about not enough time and proposing delays. What's worse, it would have the exact effect we are trying to avoid, of having 2017 be a flag day.
To be clear, in 2017/1/1, these certificates will not work. It is not a degraded UI (as you proposed), but an indistinguishable from untrusted certificate. This is significant enough to merit advance communication - which this deprecation notice is.
I don't mean this as a hypothetical - we very much saw this play out for 5 years with MD5, as CAs continued to suggest SHA-1 wasn't needed, and mitigations like entropy in the serial was sufficient.
In this proposal, no penalties are being taken against the CA. No CA is being found in violation of our root or EV policies, and no CA is risking removal wholesale. This is merely a UI update, one which doesn't require user action, that reflects the security views and best practices, which, again, CAs agreed upon and recognized this view as far back as 2011.
This is fundamentally no different than Chrome using UI to communicate other insecure CA practices that, despite every effort, continue to be used well beyond when it is safe. For example, the insecure inclusion of unverifiable domain names (also called internal server names), which has caused significant risk to the CA's users - and the Internet at large - as ICANN delegates new TLDs. Indeed, many of these same discussions were had, and worse, the timelines continually attempted to be pushed back or altogether dismissed.
It is important that Chrome, for which security has been a foundational pillar of the design, accurately and honestly reflect the security status of the page. The exact details are generally left to our security and UX teams, which have seen this as a reasonable balance between requiring the user to take direct action (via a security interstitial) and the misleading and downright status quo - of doing nothing.
Ryan Sleevi
On Aug 25, 2014 8:42 AM, "Doug Beattie" <douglas...@gmail.com> wrote:
>
> Ryan,
>
> I'm not sure where the 9 month date is coming from, my read is that in 12 weeks users will be impacted with a new UI raising some concern about the trust or security of their connection.
CAs were told about this 6 months ago.
> They've been tortured enough recently. I don't see any milestones in 9 months. While mixed content pages have serious security issues, it's not obvious to me why commercial CA SHA-1 certificates fall into this category (and, by the way, Google issued SHA-1 certificates do not). ALL SHA-1 certificates should be treated the same regardless of when they expire. Creating a loop-hole for Google issued SSL seems sneaky - even though you are publically disclosing the rules.
>
I think its best to let the original message, which laid out precisely what the motivations are, show how this statement is neither productive nor accurate.
> More responses below.
>
> On Monday, August 25, 2014 10:38:55 AM UTC-4, Ryan Sleevi wrote:
>>
>>
>> On Aug 25, 2014 7:03 AM, "Doug Beattie" <douglas...@gmail.com> wrote:
>> >
>> > Ryan,
>> >
>> > We all agree with firm dates for deprecating SHA-1 and moving to SHA-2, but the logic and dates Google has specified give web site operators little time to react.
>> >
>>
>> Doug,
>>
>> It seems extremely misleading to suggest 9 months is insufficient time.
>>
>> Let's be clear: we both know that there are CAs that actively campaigned for 2017 as unrealistic, and instead have (and in some cases, continue to) argue for 2020 or later.
>
> Microsoft specified 1/1/2017 as a critical date and I believe we're all working towards that date - CAs, Web site operators, browsers and OS vendors. I'm not aware of anyone asking for 2020 or later and agree with you that 2017 is a solid date.
You can find both in the minutes and then the Forum archives proposals to effect of what you've suggest here - that is, if any cert is valid on 2015/12/31 with SHA-1, that it be allowed to 'live out' its maximally issued life (of 39 months, or 60 months if issued before 2015/4/1)
>
>> This is such a common occurrence that it continues to delay or prevent any meaningful improvements to online security.
>>
>> Regarding proposals for examining notBefore as an issuance date - as you know, this fails to meaningfully address any of the security concerns. We have discussed in the CA/Browser Forum why it doesn't work, and it's been discussed above why it doesn't work - in particular, CAs are not required to be honest in them, and in the vast majority of cases, are not honest in them. Using information like this for security decisions fails to consider that reality.
>>
>> While I appreciate your alternative proposal, for reasons that were explained six months ago, and reasons explained earlier on this thread, that timeline doesn't align with the goal, and just serves to kick this exact same conversation of "not enough time / not enough warning" down the road.
>
> We have been working to the 1/1/2017 date and I don't advocate kicking that down the road. But, your proposal just kicked the can "up the road" over 2 years. If this had been proposed last year then there would have been more time to align issuance updates with these new requirements, but with only 12 weeks until the untrusted UI goes into affect there is very little time for the industry to react.
This was proposed and discussed 6 months ago, in a meeting you were recorded as present in ( https://cabforum.org/2014/02/19/2014-02-19-minutes-of-mountain-view-f2f/ ) and noted as participating in. I think it is worth noting the participation recorded was opposition towards requirements that would have had CAs communicating this sunset to their users, by forcing their expiration date be meaningfully set, rather than require UAs to do so.
> Web site operators have established certain processes to obtain and install certificates which are difficult to change. Those that cannot change stand to loose customers and money. As a CA, we're ready to issue replacement certificates, but not all customers are prepared to swap over to SHA-2.
And, as you read from my original message (and Brian Smith's excellent followup), your customers are not being required to immediately swap to SHA-256.
>
>> What I haven't seen is any dispute to the following:
>> - By 2016/1/1, CAs may no longer issue SHA-1 certificates. Sites which rely on these certificates (e.g. for XP SP2) WILL NOT be able to obtain any new certificates, WILL NOT be able to respond to security incidents, and WILL NOT be able to make any changes or correct any information.
>
> If this is the MS set of requirements, I read "MAY" as optional (vs Shall or Must). There will be reasons to replace (issue) SHA-1 certificates during the last year of their support, but I expect most, or all, CAs will have removed SHA-1 ordering of new certificates before 2016.
The Microsoft language includes no such provision, nor has it.
http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
"CAs must stop issuing new SHA1 SSL and Code Signing end-entity certificates by 1 January 2016."
Note the must.
>
>> - By 2017/1/1, these sites WILL NOT work.
>
> This is the date we've all been working towards, agree. SSL certificates that are issued under publically trusted roots will not work. Having a set of UI changes leading up to this is also highly desirable, I just disagree with starting this over 2 years ahead of time with rather confusing UI experience about the trustworthiness of the site.
>
And the Mozilla Root Program shows that 2 years is often insufficient time for CAs to be relied upon communicate with their users. Mozilla has been attempting to remove 1024-bit certs for FIVE YEARS now. If you read through https://bugzilla.mozilla.org/show_bug.cgi?id=881553 and related, you will see that there is, for a variety of CAs, a long tail of consumers they cannot reach, and for who the CA's inability (or, in some cases, unwillingness) to communicate with leaves a large majority of Internet users at risk.
>> If we did as you'd propose, the 2016 users will have zero warning, and the 2017 users will have less than a year, and we would be having this exact same conversation about not enough time and proposing delays. What's worse, it would have the exact effect we are trying to avoid, of having 2017 be a flag day.
>
> Perhaps you misread my suggestions. I recommend that the "untrusted UI" updates could be applied one year after you're current plan and only react to those certificates that were issued on or after 1/1/2016 (assuming there are no new advanced in the preimage attacks). Then, in mid-2016 you implement your checks you had scheduled for 1/1/2016 (5 months delay). I don't think this is an unreasonable request.
I hope the above discussion will highlight how it is.
As you have again confused the dates, there will NOT be any new certificates issued with SHA-1 after 2016/1/1. These will be hard errors AND a violation of the respective root policies, which may lead to action to protect the user from such CAs as a whole. I want to make sure this is unambiguous here, though its been repeated several times.
As you well know, this would encourage and permit SHA-1 certificates, issued at 39 months validity, being issued up until 2016/12/31. That would leave such users 5 months to transition. The discussion we are having right now is that three months isn't enough to transition (during a period where this transition can functionally last over a year), but you're proposing a five month transition with absolutely no ability to extend.
I'm sure and hope you can see the risk your proposal would leave users at, and the harm it would cause.
wgo...@gmail.com
Sorry how are you reaching the conclusion that Google is treating its own SHA-1 certificates differently than those issued by public CAs?
Ryan, for what it's worth a bit ++1 to your proposal.
Walter
Ryan Sleevi
So it's not just CAs that are being targeted with this deprecation, which is why there is such a necessarily long lead-up.
Brian Smith
> On Fri, Aug 22, 2014 at 8:23 PM, Brian Smith <br...@briansmith.org> wrote:
>> 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.
>
> When we have something to say, we'll say it :)
>
> The biggest focus right now is on certificates.
Chrome on non-SP3 Windows XP would advertise that it supports SHA-2
signatures in the signature_algorithms extension, even though it
doesn't support SHA-2 signatures on certificates on non-SP3 Windows
XP. This is why I see all of these issues as being inter-related. In
particular, using the mechanism I described to support SHA-1
certificates for non-SHA-2-capable clients while giving SHA-2-capable
clients SHA-2 certificates doesn't work well when the
signature_algorithms extension overstates the client's capabilities.
> Yeah, luckily the number of (valid) DSA certificates is extremely low. If I
> recall the data from 2013 correctly, it was on the order of 'several
> hundred', although this could easily be confirmed by the CT logs.
> I tried to keep the suggested mitigations on the simpler side, in order to
> favour the long-tail of site operators who are not capable of deploying
> parallel certificates (RSA & ECDSA, SHA-1 and SHA-256, etc). This is because
> common off the shelf server software makes this fairly tricky. However, many
> CDNs already support this capability though, precisely to support ECDSA
> rollouts.
>
> For those wondering how to implement this, OpenSSL 1.0.2+ (as an example)
> exposes SSL_set_cert_cb precisely to support this - see the man pages (
> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=doc/ssl/SSL_CTX_set_cert_cb.pod;hb=3aac17a82fbaf2bc23ee62f24611e5883d3e7b97#l51
> )
be mitigated if Apache, nginx, IIS, and other (origin) web server
software made this easy to configure. I am not sure if it is practical
to update those products to add this capability within window in which
it would be useful, however. Perhaps too little, too late.
Cheers,
Brian
Peter Bowen
>
> It also leaves ISVs and interception devices 5 months to transition their
> users, which we know is often insufficient, and, as noted in the original
> thread, part of the motivation (based on experience with MD5 deprecation).
> That is, 18 months to deprecate SHA-1 if you're an owner of an anti-virus or
> traffic inspection device is, often, a MINIMUM. (6 months for the vendor to
> implement the changes and release them, then ~12 months for customers to
> upgrade and deploy).
>
> So it's not just CAs that are being targeted with this deprecation, which is
> why there is such a necessarily long lead-up.
issued by CAs that users add to the trust list? Today Chrome gives
these CAs some special handling (for example not checking pinning
rules).
Thanks,
Peter
Ryan Sleevi
Ryan Sleevi
On Fri, Aug 22, 2014 at 8:43 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Fri, Aug 22, 2014 at 8:23 PM, Brian Smith <br...@briansmith.org> wrote:
>> It seems like the proposal only deals with SHA-1 signatures used inUnderstood. My understanding is that, at least one point in time,
>> 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.
>
> When we have something to say, we'll say it :)
>
> The biggest focus right now is on certificates.
Chrome on non-SP3 Windows XP would advertise that it supports SHA-2
signatures in the signature_algorithms extension, even though it
doesn't support SHA-2 signatures on certificates on non-SP3 Windows
XP. This is why I see all of these issues as being inter-related. In
particular, using the mechanism I described to support SHA-1
certificates for non-SHA-2-capable clients while giving SHA-2-capable
clients SHA-2 certificates doesn't work well when the
signature_algorithms extension overstates the client's capabilities.
Brian Smith
to jump through hoops to keep supporting non-SHA-2-capable clients
while doing the right thing for SHA-2-capable clients, then it seems
like we would need to document a technique that doesn't make the
decision over which cert chain to use (soley) based on the contents of
the signature_algorithms extension.
I know that some people within the TLS WG are also aware of the need
to differentiate between the signature algorithms supported during
certificate chain verification vs. the signature algorithms supported
in signed TLS structures and presumably people are working on a
solution for that. This is a good indication that such a solution
should probably be backported to earlier versions of TLS.
I don't know how big the Chrome-on-XP-SP2 userbase is. It seems like
it is large enough that the Chrome team (list like, IIRC, the Firefox
team does for Firefox-on-XP-SP2) feels justified in continuing to
supporting them indefinitely. It seems like websites also will want to
support those users too, but it seems like how to do that is still an
unsolved problem.
Cheers,
Brian
Chris Palmer
> I don't know how big the Chrome-on-XP-SP2 userbase is. It seems like
> it is large enough that the Chrome team (list like, IIRC, the Firefox
> team does for Firefox-on-XP-SP2) feels justified in continuing to
> supporting them indefinitely. It seems like websites also will want to
> support those users too, but it seems like how to do that is still an
> unsolved problem.
be sure, but it looks like Twitter uses an EE cert signed with SHA-256
+ RSA.
Maybe Twitter is distinguishing SHA-256 capable vs. non-capable
clients, and serving different chains? Otherwise, a site as important
as Twitter seems to be OK with not working on old platforms.
And if that's true, maybe nobody else needs to care, either? Very few
sites can claim to be a bigger deal than Twitter...
yuhong...@hotmail.com
yuhong...@hotmail.com
On Monday, August 25, 2014 3:02:40 PM UTC-7, Ryan Sleevi wrote:
On Mon, Aug 25, 2014 at 12:03 PM, Brian Smith <br...@briansmith.org> wrote:
On Fri, Aug 22, 2014 at 8:43 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Fri, Aug 22, 2014 at 8:23 PM, Brian Smith <br...@briansmith.org> wrote:
>> It seems like the proposal only deals with SHA-1 signatures used inUnderstood. My understanding is that, at least one point in time,
>> 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.
>
> When we have something to say, we'll say it :)
>
> The biggest focus right now is on certificates.
Chrome on non-SP3 Windows XP would advertise that it supports SHA-2
signatures in the signature_algorithms extension, even though it
doesn't support SHA-2 signatures on certificates on non-SP3 Windows
XP. This is why I see all of these issues as being inter-related. In
particular, using the mechanism I described to support SHA-1
certificates for non-SHA-2-capable clients while giving SHA-2-capable
clients SHA-2 certificates doesn't work well when the
signature_algorithms extension overstates the client's capabilities.The error page today for XP SP2 users already directs them to install SP3.I also suspect we will "butterbar" these SP2 users, similar to how we have notified users who have failed to install recent/updated versions of Chrome or when they're running an older version of an OS that has known security issues.
Peter Bowen
Non-publicly trusted roots and certs they issue are not currently
subject to key size and requirements, correct? A non-publicly trusted
certificate with a 1024-bit RSA key with a SHA-256 signature will
continue to be accepted by Chrome, right? Is there a lower bound of
accepted key length?
Thanks,
Peter
Ryan Sleevi
Håvard Molland
How does this affect users of the content API? Will this change be implemented entirely below the content/net APIs using existing security states, such that all Chromium based browsers and applications automatically inherit the new UI behavior? Or will you implement this on top of the content API in your UI layer?
Thanks,
Håvard
On 20. aug. 2014 06:52, Ryan Sleevi wrote:
Primary eng (and PM) emails
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.
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.
-- --- Opera Software
Ryan Sleevi
On Aug 26, 2014 2:38 AM, "Håvard Molland" <haav...@opera.com> wrote:
>
> Although we do understand some of the problems this causes for the CAs, Opera fully backs Chromium on this issue. We plan to follow and implement the same behavior.
>
Glad to hear.
> How does this affect users of the content API? Will this change be implemented entirely below the content/net APIs using existing security states, such that all Chromium based browsers and applications automatically inherit the new UI behavior?
Yes.
> Or will you implement this on top of the content API in your UI layer?
//content embedders will still be able to control or alter this if needed, although like many other security features (like sandboxing), it's not recommended to disable.
benwil...@gmail.com
> Although we do understand some of the
> problems this causes for the CAs, Opera fully backs Chromium on
> this issue. We plan to follow and implement the same behavior.
> ---
> Opera Software
Haavard,
When you say that Opera will implement "the same behavior", what does that mean in terms of UX? Will users start seeing a big red X through "https"? Can you point us to the image that will appear as the mini-icon in Opera's address bar? I'm concerned that browsers use passive SSL indicators that are appropriate to the threat level. Just like the US DHS threat level indicators, the color red should be reserved for the most severe threats. Red means prohibited. Orange means high alert. Yellow means guarded. Etc.
http://en.wikipedia.org/wiki/File:Hsas-chart_with_header.svg
This is similar to what was adopted in the 20th century by international road sign standards and for traffic lights - http://en.wikipedia.org/wiki/Vienna_Convention_on_Road_Signs_and_Signals#Traffic_lights.
(Hopefully we won't have to hold an international treaty convention for these road signs.)
Thanks,
Ben
Håvard Molland
"The same behavior" here simply means to adopt the same security levels, not how it is shown to the users. So we will not start to show the red X. In this case we will most likely do what we for for most other SSL issues: We downgrade the UI to no security, which is the same security level as normal http. That is, the site will simply loose the security badge and the same icon that used for http will be shown.
Cheers,
Håvard
> Thanks,
> Ben
>
> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
--
---
Opera Software
rick_a...@symantec.com
We’ve all been working towards the deadlines presented in Microsoft’s SHA-1 deprecation policy, getting the word out to our customers. We thought we had consensus on that plan, but Google’s action will cause customers to scramble to preserve the security indicators they currently have. SHA-1 is not broken today; it’s not likely to be broken in six months. In fact, google.com is still using SHA-1 in both end-entity and intermediate certificates today. Granted, the end-entity cert is rather short-lived, but while Google has the ability to roll over their certificate every three months, most SSL customers cannot. And they shouldn’t be asked to do that on such short notice.
The deprecation of 1024-bit end-entity certs last year is a good example. The industry formed a consensus and a reasonable flag day, and we all worked towards that. Some certificates had end dates fixed to the day before the flag day, but many others had end dates after that. These cases were remedied, and there were no widespread issues – indeed, it was a non-event as far as browser users were concerned. Website owners worked with their certificate providers and there was near universal adoption of 2048 bit certificates on schedule. The lesson here is that browsers didn’t need to downgrade UI indications for existing certificates before the end date, and there was no major disruption to customers.
In short, we’ve shown that the industry can enable these kind of upgrades without warning indicators. For these reasons we feel that sticking to the original Microsoft deadline would be responsible and would not jeopardize Internet security.
Ryan Sleevi
Symantec agrees with other CAs that the industry needs to phase out the use of SHA-1 in certificates, and we, like all other CAs that have commented, have been offering SHA-2 certs to our customers for some time now. Our concern about Google’s proposal is in regards to the disruption we feel it will cause for thousands of web site operators.
We’ve all been working towards the deadlines presented in Microsoft’s SHA-1 deprecation policy, getting the word out to our customers. We thought we had consensus on that plan, but Google’s action will cause customers to scramble to preserve the security indicators they currently have. SHA-1 is not broken today; it’s not likely to be broken in six months. In fact, google.com is still using SHA-1 in both end-entity and intermediate certificates today. Granted, the end-entity cert is rather short-lived, but while Google has the ability to roll over their certificate every three months, most SSL customers cannot. And they shouldn’t be asked to do that on such short notice.
The deprecation of 1024-bit end-entity certs last year is a good example. The industry formed a consensus and a reasonable flag day, and we all worked towards that. Some certificates had end dates fixed to the day before the flag day, but many others had end dates after that. These cases were remedied, and there were no widespread issues – indeed, it was a non-event as far as browser users were concerned. Website owners worked with their certificate providers and there was near universal adoption of 2048 bit certificates on schedule. The lesson here is that browsers didn’t need to downgrade UI indications for existing certificates before the end date, and there was no major disruption to customers.
In short, we’ve shown that the industry can enable these kind of upgrades without warning indicators. For these reasons we feel that sticking to the original Microsoft deadline would be responsible and would not jeopardize Internet security.
Kirk Hall
steve...@gmail.com
Ryan,
I support your endorsement of the previously communicated Microsoft policy sent directly to all CAs informing us of the 2016 and 2017 deprecation milestones. In my own business, like many CAs, I am working on this task actively and I will achieve the two goals.
In the course of reviewing this discussion and the CABFPub posts,
I feel that the conversation is devolving toward a door slam and I want to
prevent that by sharing further perspective from my own experience. I need to amplify the concerns of my friends
who have already contributed great objections to the strategy. I want to point
out areas where I feel that the conversation is getting counter-productive and
subject to failure.
I’m going to bulletize as a favor to weary eyes.
- It is incorrect to conclude that because a certificate is issued for three years, it will live out those full three years regardless of compliance impacts.
- It is fully within CA policy, practice, customer relationship, and software functionality to replace certificates that are about to enter a non-compliance period with those that are compliant at no cost.
- Certificates being issued now out of compliance to the future milestones are issued by a CA knowing that they will be replaced.
- Rick documents the above as real world in his post about issuer and end entity deprecation of 1024-bit keys.
- Google did not present UX indicia to users a year or two in advance of the Mozilla issuer and end entity key size deprecation. Key size deprecation was a more critical matter, yet SHA-1 is planned to get two year advance indicia.
- As you state, in October 2010 Mozilla published
its intent to end 1024-bit keys in three months. The public (and far more extensive private,
in my case) discussion that followed pushed that date out several years by
Mozilla’s admittance to the impacts. Mozilla adapted to CA discussion with them, and continues to empathize with customer impact as Kathleen regularly demonstrates.
- You confronted Rick on the continued use of his 1024-bit
roots as dismissal of the value of his contribution to the discussion, yet in your own explanation of
trusted root store impact, you confirm that you have no intent to show indicia
for SHA-1 roots. You clearly demonstrate empathy for the difference between root management and issuer and end entity policy management.
- You may choose to dismantle my points as you did with Rick by citing our use of a 1024-bit root. I’ve publicly disclaimed that our root has a life larger than browsers and while we strongly caution against its continued use there are some situations where something is better than nothing. We secure infrastructure that is not as agile as the browser space.
- Twelve weeks has been labeled as generous, reasonable and manageable. Like my colleagues, we manage PKI for customers who issue tens of thousands of SSL server use case certificates. We all support methods to gain replacement certificates compliant to new policies for free. But the license cost of a certificate is a fraction of the TCO. In a bank with 35,000 certificates, a team of 40-50 certificate admins and 100-200 server admins manage that load over a calendar year. In twelve weeks, which in reality reduces to 8 when you factor in mobilizing such a project, the workload on this team is SIX times normal daily volume (12 months divided by 2 months).
- In late October, retailers stop all maintenance against e-commerce servers until mid-February. Installation of one SSL certificate on one server requires senior VP level override of policy. This means that IF we send out broadcast messages to our customers this week, they realistically have six weeks to respond. They’ll lose the front end of that just planning the activity.
- In your comments, you lament that if a site cannot replace its certificate in X amount of time, then that’s a sad landscape. The issues here are not about one guy at one dotcom that has to replace one cert. That’s a 1:1:1 ratio. The issue is a typical 1:2000 cert administrator ratio and a 1:400 server to server admin ratio. These numbers are real, both at our customers and across the Verizon brand.
- Certificates managed on revenue generating servers that handle PII are subject to internal and external audits and change control windows. Click, boom, done is not reality, even at the medium end of SMB.
- Tom’s plan is to stop trust of a SHA-1 certificate on 1/1/17 and you agree. Microsoft have no plans to dent the chrome of any SHA-1 certificates in 2015 as they have confidence that their end of trust is firm and adequate enough to cause 100% CA action or embarrassing failure and loss of customers.
- You are moving a known flag day in 2017 that is
manageable to a new flag day in 12 weeks during holiday server lockdown because
you lack confidence in CA ability to protect our customers from failed trust. CAs must act to protect their revenue. This is a for profit business, we are not going to fall on our faces and leave our spoils to our friends. Tom understands that his motivation is plenty.
- Your fear is generating a massive cost for our certificate buying customers, and we have no exploit in the wild like Heartbleed to use as justification. We will need to broadcast a message that politely describes your concerns and then urges our customers to launch full scale replacement projects. Ultimately, our enterprise customers will see through the veneer and define an unwarranted business cost and an inconsistent perception of risk.
- You downplay the red UX indicia as just a gentle nudge. SSL certificate customers want no dents on the products they buy from us, just like I can’t sell a bus with three wheels. Any mark other than perfect may as well be an untrusted mark. In certificate buyer perception, you are bringing 1/1/17 to this year.
- Based on current compatibility, SHA-2 is a support failure for my operational affiliates across the Verizon brand. Due to the variety of user agents in use, we are unable to move B2C and B2B Verizon web assets to SHA-2 without revenue loss, helpdesk traffic cost, and service abandonment. Our own company accurately represents the customer base we serve.
- Ryan, you’ve faced a lot of resistance that I’m sure you expected. At times, I see a closed and conclusive posture in your tone. For example, you’ve stated "I think its best to let the original message, which laid out precisely what the motivations are, show how this statement is neither productive nor accurate." You’ve stated parenthetically that CAs are unwilling to communicate with customers without basis in fact. You’ve changed venue on the CABF discussion where valid points were raised. In doing so, you deflated Kirk’s expectation that there was any point to his message, as he left it up to you to cross post if you saw a point to it. It appears Kirk had no point. You’ve criticized CAs based on root management policies when we all know that end entity and issuer transition is orders of magnitude easier than root transition. I’ve been through 5 root transitions since 1998, they begin at T-minus four years.
- Now let me balance that because I don’t want to spar. Ryan, you’ve also shown a lot of patience with expected conflict. I know you are open to the idea of looking at a calendar, looking at today’s date, looking in your outbox for a message to all CAs that states that this is your policy, looking at holiday freeze and realizing that if you don’t trust CAs to take action, now is not the time to try to catalyze action. If you read my position statements with empathy toward the SSL certificate owner, and you can detect the passion of all the contributors here to comply, I feel you can dismiss the fear that we are ignoring this compliance deadline.
- If you’re still afraid of us all failing, then 12 weeks just amplifies the impact on the market and the quantity of trusted connection failures. A rational strategy to communicate your disgust with our inability to act would be to set a date we all feel we can achieve provided that we can get the message out, get real action started in February after holiday freeze, and get closure within 2015. Closing this issue in 2015 is a 100% win and succeeds at the goals to which you subscribed in the CABF discussion you cite. Marking certificates that temporarily exceed the 2016-7 targets with demerits in 2015 will cause market panic at a time when few are prepared to act.
Ryan, I compel you to review the passion we all share for your plan and our plea to let us execute it effectively with fanatical customer endorsement of the idea brought about by milestones that work from the enterprise to the dotmom.
felix
- In late October, retailers stop all maintenance against e-commerce servers until mid-February. Installation of one SSL certificate on one server requires senior VP level override of policy. This means that IF we send out broadcast messages to our customers this week, they realistically have six weeks to respond. They’ll lose the front end of that just planning the activity.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
Ryan Sleevi
Ryan,
I support your endorsement of the previously communicated Microsoft policy sent directly to all CAs informing us of the 2016 and 2017 deprecation milestones. In my own business, like many CAs, I am working on this task actively and I will achieve the two goals.
In the course of reviewing this discussion and the CABFPub posts, I feel that the conversation is devolving toward a door slam and I want to prevent that by sharing further perspective from my own experience. I need to amplify the concerns of my friends who have already contributed great objections to the strategy. I want to point out areas where I feel that the conversation is getting counter-productive and subject to failure.
I’m going to bulletize as a favor to weary eyes.
- It is incorrect to conclude that because a certificate is issued for three years, it will live out those full three years regardless of compliance impacts.
- It is fully within CA policy, practice, customer relationship, and software functionality to replace certificates that are about to enter a non-compliance period with those that are compliant at no cost.
- Certificates being issued now out of compliance to the future milestones are issued by a CA knowing that they will be replaced.
- Rick documents the above as real world in his post about issuer and end entity deprecation of 1024-bit keys.
- Google did not present UX indicia to users a year or two in advance of the Mozilla issuer and end entity key size deprecation. Key size deprecation was a more critical matter, yet SHA-1 is planned to get two year advance indicia.
- As you state, in October 2010 Mozilla published its intent to end 1024-bit keys in three months. The public (and far more extensive private, in my case) discussion that followed pushed that date out several years by Mozilla’s admittance to the impacts. Mozilla adapted to CA discussion with them, and continues to empathize with customer impact as Kathleen regularly demonstrates.
- You confronted Rick on the continued use of his 1024-bit roots as dismissal of the value of his contribution to the discussion, yet in your own explanation of trusted root store impact, you confirm that you have no intent to show indicia for SHA-1 roots. You clearly demonstrate empathy for the difference between root management and issuer and end entity policy management.
- You may choose to dismantle my points as you did with Rick by citing our use of a 1024-bit root. I’ve publicly disclaimed that our root has a life larger than browsers and while we strongly caution against its continued use there are some situations where something is better than nothing. We secure infrastructure that is not as agile as the browser space.
- Twelve weeks has been labeled as generous, reasonable and manageable. Like my colleagues, we manage PKI for customers who issue tens of thousands of SSL server use case certificates. We all support methods to gain replacement certificates compliant to new policies for free. But the license cost of a certificate is a fraction of the TCO. In a bank with 35,000 certificates, a team of 40-50 certificate admins and 100-200 server admins manage that load over a calendar year. In twelve weeks, which in reality reduces to 8 when you factor in mobilizing such a project, the workload on this team is SIX times normal daily volume (12 months divided by 2 months).
- In late October, retailers stop all maintenance against e-commerce servers until mid-February. Installation of one SSL certificate on one server requires senior VP level override of policy. This means that IF we send out broadcast messages to our customers this week, they realistically have six weeks to respond. They’ll lose the front end of that just planning the activity.
- In your comments, you lament that if a site cannot replace its certificate in X amount of time, then that’s a sad landscape. The issues here are not about one guy at one dotcom that has to replace one cert. That’s a 1:1:1 ratio. The issue is a typical 1:2000 cert administrator ratio and a 1:400 server to server admin ratio. These numbers are real, both at our customers and across the Verizon brand.
- Certificates managed on revenue generating servers that handle PII are subject to internal and external audits and change control windows. Click, boom, done is not reality, even at the medium end of SMB.
- Tom’s plan is to stop trust of a SHA-1 certificate on 1/1/17 and you agree. Microsoft have no plans to dent the chrome of any SHA-1 certificates in 2015 as they have confidence that their end of trust is firm and adequate enough to cause 100% CA action or embarrassing failure and loss of customers.
- You are moving a known flag day in 2017 that is manageable to a new flag day in 12 weeks during holiday server lockdown because you lack confidence in CA ability to protect our customers from failed trust. CAs must act to protect their revenue. This is a for profit business, we are not going to fall on our faces and leave our spoils to our friends. Tom understands that his motivation is plenty.
- Your fear is generating a massive cost for our certificate buying customers, and we have no exploit in the wild like Heartbleed to use as justification. We will need to broadcast a message that politely describes your concerns and then urges our customers to launch full scale replacement projects. Ultimately, our enterprise customers will see through the veneer and define an unwarranted business cost and an inconsistent perception of risk.
- You downplay the red UX indicia as just a gentle nudge. SSL certificate customers want no dents on the products they buy from us, just like I can’t sell a bus with three wheels. Any mark other than perfect may as well be an untrusted mark. In certificate buyer perception, you are bringing 1/1/17 to this year.
- Based on current compatibility, SHA-2 is a support failure for my operational affiliates across the Verizon brand. Due to the variety of user agents in use, we are unable to move B2C and B2B Verizon web assets to SHA-2 without revenue loss, helpdesk traffic cost, and service abandonment. Our own company accurately represents the customer base we serve.
- Ryan, you’ve faced a lot of resistance that I’m sure you expected. At times, I see a closed and conclusive posture in your tone. For example, you’ve stated "I think its best to let the original message, which laid out precisely what the motivations are, show how this statement is neither productive nor accurate." You’ve stated parenthetically that CAs are unwilling to communicate with customers without basis in fact. You’ve changed venue on the CABF discussion where valid points were raised. In doing so, you deflated Kirk’s expectation that there was any point to his message, as he left it up to you to cross post if you saw a point to it. It appears Kirk had no point. You’ve criticized CAs based on root management policies when we all know that end entity and issuer transition is orders of magnitude easier than root transition. I’ve been through 5 root transitions since 1998, they begin at T-minus four years.
- Now let me balance that because I don’t want to spar. Ryan, you’ve also shown a lot of patience with expected conflict. I know you are open to the idea of looking at a calendar, looking at today’s date, looking in your outbox for a message to all CAs that states that this is your policy, looking at holiday freeze and realizing that if you don’t trust CAs to take action, now is not the time to try to catalyze action. If you read my position statements with empathy toward the SSL certificate owner, and you can detect the passion of all the contributors here to comply, I feel you can dismiss the fear that we are ignoring this compliance deadline.
- If you’re still afraid of us all failing, then 12 weeks just amplifies the impact on the market and the quantity of trusted connection failures. A rational strategy to communicate your disgust with our inability to act would be to set a date we all feel we can achieve provided that we can get the message out, get real action started in February after holiday freeze, and get closure within 2015. Closing this issue in 2015 is a 100% win and succeeds at the goals to which you subscribed in the CABF discussion you cite. Marking certificates that temporarily exceed the 2016-7 targets with demerits in 2015 will cause market panic at a time when few are prepared to act.
Ryan, I compel you to review the passion we all share for your plan and our plea to let us execute it effectively with fanatical customer endorsement of the idea brought about by milestones that work from the enterprise to the dotmom.
Steve
Your work has already taken further effect to the response Microsoft provoked. We are preparing communication in response to this thread to propose primary use of SHA256 and access to SHA-1 by exception only, along with an assurance that any application that cannot handle SHA256 is subject to significant security risks that can easily expose PII outside the tunnel regardless of algorithms and key sizes due to keylogger malware injection. Such systems should be excluded from access, and we'd welcome PCI audit support of that position along with the once and for all deprecation of server gated cryptography as the false sense of security that has perpetuated the $800 toilet seat.
Ryan, you have been very pro-active in stimulating discussion and communicating CT. You also review Kathleen's drafts at m.d.s.policy. Therefore, I don't need to post CA communications to show how your peers express policy because you're already doing great with CT. What the heck happened here?
steve...@gmail.com
https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates
Ryan Sleevi
steve...@gmail.com
Indeed it makes no statement about FF UX, and I've jumped on that clarification already as it brings weight here. Saying nothing = doing nothing is a safe leap of faith, but we can close out that point at m.d.s.policy.
Kirk Hall
Ryan, I asked a question yesterday, and am still interested in the answer. Why not push out the implementation of Google's new policy by six months – in other words, delay the negative UI effect on SHA-1 certs expiring after 2015 until six months from now?
You can see that most or all CAs think Google’s current 6-12 week deadline is way too short for many website owners to change out all their current (valid) SHA-1 certs, especially with the holiday season lock-down coming soon (the window for response is actually more like 4 weeks for some retail websites).
Google can accomplish 100% of its stated goals with a six month delay in enforcement (e.g., to March 1, 2015). This new date would still require all websites to replace all SHA-1 certs by the end of 2015 – Google’s stated goal – but in a more reasonable time frame.
Your prior postings have indicated Google has been working on this new policy for six months (February to August, when the new policy was announced). Why not give website owners and CAs an equal period of time – six months – to respond to the new policy if that new deadline will still achieve all of your goals? That could make your policy much more successful, and would be appreciated by everyone.
**So how about it, Ryan – will Google help everyone out and postpone its new policy for six months?**
Ryan Sleevi
Ryan, I asked a question yesterday, and am still interested in the answer. Why not push out the implementation of Google's new policy by six months – in other words, delay the negative UI effect on SHA-1 certs expiring after 2015 until six months from now?
You can see that most or all CAs think Google’s current 6-12 week deadline is way too short for many website owners to change out all their current (valid) SHA-1 certs, especially with the holiday season lock-down coming soon (the window for response is actually more like 4 weeks for some retail websites).
Google can accomplish 100% of its stated goals with a six month delay in enforcement (e.g., to March 1, 2015). This new date would still require all websites to replace all SHA-1 certs by the end of 2015 – Google’s stated goal – but in a more reasonable time frame.
Your prior postings have indicated Google has been working on this new policy for six months (February to August, when the new policy was announced). Why not give website owners and CAs an equal period of time – six months – to respond to the new policy if that new deadline will still achieve all of your goals? That could make your policy much more successful, and would be appreciated by everyone.
**So how about it, Ryan – will Google help everyone out and postpone its new policy for six months?**
kirk...@trendmicro.com
Ryan – you keep saying Google told all CAs about this policy six months ago. What are you referring to? The CA/Browser Forum meeting in February? You made no mention of this policy at that time. See again the meeting minutes below from February 19, 2014.
Can you point to some other place – email, or whatever – where Google told anyone about its new SHA-1 policy? I’m having a hard time understanding you – when and where did this happen?
The first time that ANY CA knew about your new policy was on August 19, when you posted it here: https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/2-R4XziFc7A/NDI8cOwMGRQJ Then you verbally informed CAs on the next call of the CA/Browser Forum on August 21. As you may recall, there was stunned silence in response to the deadlines you announced.
To be blunt, Google did not announce its policy six months ago – only nine days ago. Can’t you please create a reasonable deadline for everyone, when it will get Google to where it wants to be in early 2015? There’s no reason to be vindictive – you are punishing everyone for what you see as the failings of (some) CAs on past transition issues like MD5, 1024 bit certs, etc. Come on, Google is bigger than that…
Here (again) are the CA/Browser Forum Minutes from last February 19 – no new Google policy was announced:
Wednesday, 19 February 2014
Browser News
Mozilla (Brian Smith):
1. Working on changing to new cert verification library for FF30 which will be released in 16 weeks “Path bldg. for cert chains in a more sensible way”. Helps increase compatibility and will allow them to add new features in certs like CT.
2. Half way done in implementing “must staple” extension. Working to revise Phil Baker’s IETF draft and getting it published. Overall goal: make OCSP staple secure. This will help promote OCSP stapling as a good solution against key compromise. OCSP fetching discussion going on now. 7% of handshakes use OCSP stapling. Would like to increase to 100%.
3. The new path building logic will be an option in FF29. They will recommend that each CA test against their own certs
4. FF29 to remove most or all of 1024 bit roots. CA’s need to get back to Mozilla with any significant impact CAs that have legacy roots that have been cross signed would be affected. Mozilla will accept requests from CAs to build in intermediates into Mozilla if that will help prevent many web sites from breaking (contact Brian).
5. Timeline for FF29: April 29th (remove 1024 roots and new path building code optional). FF30: June 10th (new path building code enabled for all)
6. No decision made yet on SHA-1 deprecation. Awaiting feedback from CAs on MSFT proposal.
Google Chrome (Ryan Sleevi)
1. Transitioning away from NSS to OpenSSL stack except on Windows and Android. Win will continue with Crypto API Effect on moving to OpenSSL-parsing rules. No special UI for bridge certs but will support them.
2. Looking at programmatic enforcement of BRs
3. CT reqt to be discussed later
4. Chrome does not support internal server names from public roots (this has been true for some time now). Will not show lock.
Microsoft (Tom Albertson)
1. SHA-1 announcement published
2. First 1024 bit cert removal in March Windows update. Another one to be issued in June to remove more roots. One criteria used: how quickly CAs responded to Microsoft. By end of 2014-no more 1024 roots
3. Programmatically enforcing BRs in 2014. Tom contacting CAs directly. After 2014, rule out exceptions and “throw the switch”.
4. April 2015-No longer accepting non BR compliant certs.
5. Cert hygiene- checking things like no issuing from roots
SHA1 Sunsetting / Grandfathering Strategy
Ben: We should work on a path forward to make sure everyone is aware of the current plan to eliminate SHA-1. We might want to see if there is a way to allow exceptions for an initial grandfather period, along with the sunset period when everything gets turned off, because there are likely to be some that will object to a hard deadline.
Tom: Removal of roots may have some affect.
Richard: Four million users in China are relying on Windows XP, SP2, which cannot use SHA2.
Brian: If browsers enforced SHA2, then end users would stop approaching CAs asking for SHA1 certificates.
When large, popular websites start using SHA2, then everyone will want to upgrade their browsers.
Brian: With TLS 1.2, the client can send the server a list of algorithms it supports, and maybe we could get server vendors to start adding an ability to select SHA1 vs. SHA2 based on what the TLS 1.2 client sends, like what has been done for EC certificates vs. RSA certificates. This might work with markets with localized issues like China and Japan. Also, large ecommerce sites have economies of scale to create customized code to serve SHA1 to SHA1 clients and SHA2 to SHA2 clients, so maybe we should make them aware of this possibility. They would be willing to do more work than the general population of server administrators.
Robin: We cannot, however, partition the Internet into different zones - SHA1 vs. SHA2.
Dean: How does this work on the browser side?
Brian: In Firefox, the user gets a warning that says, “we cannot verify that this was issued by a trusted issuer.” Then we let users click through it – we basically treat it as an invalid signature.
Dean: What about Chrome?
Ryan: You will get an invalid certificate, based on whether it uses CryptoAPI. Whether it is over-rideable depends on whether it is an invalid server certificate, then no, but if it is an untrusted server certificate, then yes, it is over-rideable.
Dean: What about Internet Explorer?
Tom: You will not be able to have an https connection.
Ben: Regardless of whether all of the browsers implement SHA1 sunsetting, there will still be users who do not upgrade their browsers, so the issue is how do we gracefully transition, because regardless of the cutoff date, there will be a tail that follows after that date. We should be looking for statistics – who has moved, why haven’t people moved to SHA2, etc., and based on that we could see whether any grandfathering rule makes sense, because no CA wants to violate a rule.
Chris: As a general rule, we seem to have a double sunset. We take a date to our customers, and they start to implement it. Then our customers come back to us with news about their problems, or their customers’ problems. And then through an organic process we come up with a grandfather policy.
Wayne: I wonder if we should be setting deadlines at this point. Microsoft has a date and a time next year at which to re-evaluate the policy, and then we have our users and a security policy we’re trying to implement without breaking things, so that is when we should evaluate between breaking things and the sunset.
Brian: If we wait too long, then we’ll have some CAs who have the situation under control and those that don’t. Then, if things change, those CAs who have handled the transition responsibly will feel they are being treated unfairly. For instance, a CA issuing a certificate without OCSP could sell certificates more cheaply in violation of the rules. By June 2015, we need to be able to say that we have identified all of the potential issues.
Chris: We need to have a process for future migrations. So, if Microsoft says, “we need to move over to this specification, but until customers begin to feel the pain, we don’t know what all of the issues are. Then, when they complain, we give them a temporary, 1-year reprieve while a better solution is developed.
Brian: We should definitely consider shortening the lifetimes of SHA1 certificates—they shouldn’t be longer than a year. So, we need to put into the Baseline Requirements a maximum lifetime for a certificate with a SHA1 signature.
Bob: We’re trying to reduce our risk, because we want to reduce the number of certificates with SHA1 and the negative impact that will occur when it is known that SHA1 is insecure.
Richard: We should issue the user two certificates. That way, at the appropriate time, the user can just switch over from their SHA1 certificate to their SHA2 certificate.
Rick: I like that idea, and we’re also considering that approach. It’s easier for us and for the customer, so we’d prefer that strategy rather than shortening lifetime.
Bob: We need to have the customer experience pain with a SHA1 certificate, or it won’t work.
Brian: What is the problem with limiting SHA1 to one year?
Rick: We have a number of platforms for selling certificates, and let’s say a customer buys a three-year certificate, and we deliver a SHA2 certificate, and they tell us that a SHA2 certificate doesn’t work. It’s much easier just to say, here are your two certificates. There is no longer a need to refund because we’ve at least given them what they’ll need over that three-year period.
Brian: It still doesn’t make sense to be selling and giving customers something that you know will not work two years from now.
Rick: If Microsoft re-evaluates in June 2015, it could push the date out.
Tom: It is most likely that the date will stay right where it is.
Rick: It is possible, so that’s why.
Tom: It’s not really a date that we’re going to be looking at the fragility of SHA1. Because we know SHA1 is already fragile. We are looking at the actual exposure to customers. We are trying to figure out who gets harmed by using SHA1. Right now, we don’t see enough harm to justify pushing out the date. I recommend getting your customers started on SHA2 now, that way, it will reduce your refunds.
Rick: We are pushing SHA2.
Brian: What do you think about my idea that changing server software to recognize that the server supports SHA2 and then serving up one certificate or another based on that?
Tom: Anything we can do to promote SHA2 is a good thing, like TLS 1.2.
Ryan Sleevi: It’s tricky. It requires action by both people on the server side and client side. With Chrome, we’ve seen some issues. For instance with ECDSA certificates, on OSX 8 verification of certificates was broken but TLS worked, so you have to engage in snipping to try and figure out what is going on. Is the TLS handshake issue coming from a Safari configuration or from Chrome? And there are other issues with certificate verification and relying on the OS. 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.
Brian: I can understand the ECC issue because Chrome has to support Windows XP that doesn’t have ECC, but as far as I know, Chrome doesn’t run on any platform that doesn’t support SHA2. So, when you’re running on SP 2, what do you do with the supported signature algorithms field of the TLS handshake for TLS 1.2?
Ryan: Probably the wrong thing. 
Brian: Presumably, you could fix that, too.
Ryan: Yes, we can, and we hope to resolve that in TLS 1.3, although supporting TLS 1.2 has been messy enough.
Ben: Assuming the Microsoft date is not going to change, can we take that as a given and work around the variables that we can change and identify what is not going to change?
Kirk: As Chris noted, there are two sunsets--the stated one and the panic one. The one thing to think about is whether Microsoft is really going to just turn SHA1 off so it doesn’t work. The sunset is January 2017. We could say that we couldn’t sell any SHA1 cert after July1 of the previous year so people try to get into panic mode and then give them 30-day certificates.
Ryan: We have had discussions with cryptographers about this, “oh crap, panic mode” and probable collisions and without giving CAs false hope, there might be things that browsers could do to pre-identify potential collisions based on certain characteristics and that might provide a little bit more of a transition phase. We might be able to look at those in SHA1 and block those certificates.
Ben: Whatever we do should not allow customers or other CAs wiggle out by not having to do it. It should be above board and strict and programmatically enforced, and just start people toward that pain point without CAs having to be the police on it, because there would be chances of undercutting it.
Wayne: What I’ve heard here today has changed my opinion, instead of assuming that all CAs are smart enough not to issue SHA1 certificates that expire after January 1, 2017, we should have a policy that says starting January 1, 2015, you’re not allowed to issue a certificate with a SHA1 algorithm that expires after January 1, 2017. When I read Microsoft policy, that’s what I get, but that’s not really what it says. Maybe that is a way to move it forward.
Brian: That’s almost exactly what I recommended that Firefox do, except I said 2014. I don’t see why we should keep accepting certificates after there has been time for CAs to adjust, that have a validity period that ends after January 1, 2017. If CAs say they need 6 months, to implement some changes before they are ready to do that, then that type of policy is very reasonable, not just for CA/B Forum to put in the BRs, but for browsers to start enforcing that on January 1, 2015.
Doug: I prefer to not set a certain date because when you’re selling certificates, it is hard to set the price for an 18-month or 20-month certificate. I think that we set maximum validity periods on certain dates. For instance, say April 2014 is a 2-year max validity SHA1 certificate, but not an end date—it’s easier to program for a 2-year or a 1-year certificate.
Wayne: My interpretation the way I hear what you are saying is after January 1, 2015, with my system is that I will no longer be able to sell a SHA1 Certificate to a customer for more than 1 year. But at the same time, other CAs might have different systems, but they are stuck with that.
Brian: I understand what you’re saying.
Chris: There’s a pro and con to what you’re saying, we want to be careful, but we can actually communicate this to our customers all at the same time in terms of policy. We could just pick a hard date.
Brian: It makes a lot of sense for the software developers to look at the cryptographic concerns that have been raised and determine that based on these concerns, as far as securing our products goes, we stop accepting these certificates after this date, based on what we know, and create some kind of document for it. IETF is already working on that anyway, and then say, here is an open standard that we are going to implement. For CAs selling certificates to customers, then you have an open, public recommendation that you can point people to. Put the blame on the software companies.
Rick: I agree with Doug and I disagree with Wayne. We can tell customers that we can sell them a SHA1 certificate that goes beyond January 1, 2017, but on that date your Windows box will stop trusting it. We are already giving that warning to customers, so it is superfluous to tell customers also that before then the browsers will stop trusting it. There is already a built in sunset date. I’d like to have the flexibility to issue beyond that date with the understanding that I’ll communicate with my customers. It just makes it a lot easier to comply.
Ryan: It is possible that the certificate will work well beyond the sunset date if they are not on a system with Windows update.
Kirk: What about a requirement that you tell a customer if you sell them a SHA1 certificate with an expiration date beyond 2017 it probably will not work on a certain applications? That sounds like it would cover what Symantec is already doing and it should reduce the number of customer support calls if we give that notice.
Ben: What if with that motion we included some type of endorsement or recognition of Microsoft’s date? Then we’re self-regulating without having to enforce a requirement.
Ryan: We’ve seen examples in the Forum of exceptions, but here we have an opportunity to work with root programs and state what has been determined as best practice. This could be folded into audit requirements and if you can’t meet the requirement then you can work with the root program for additional time in which to comply.
Bob: CAs should not be selling three-year SHA1 certificates at this point. We shouldn’t leave a policy that allows CAs to pre-sell SHA1 certificates.
Dean: It’s not because we are trying to sell SHA1 certificates, it is that customers want to buy them. Customers want to buy three-year certificates; they do not want to buy one-year certificates.
Bob: The point is that you have to stop selling three-year SHA1 certificates.
Doug: Not necessarily. They can get a replacement certificate for free, only it’s a SHA2. At their leisure, they can upgrade to a SHA256.
Rick: Clearly, after January 1, 2017, we cannot sell a SHA1 certificate of any duration. Our current path is best. We sell them a three-year SHA2 certificate. If they come back and say they need a SHA1 certificate, we give them a three-year SHA1 certificate, and we tell them, at some point, you’ll probably need to switch back to the SHA2 certificate.
Ryan: I understand where Bob is coming from on a policy perspective, but wouldn’t it be better to provide a warning to customers.
Rick: That’s what we’re doing.
Dean: Even NIST didn’t have a SHA2 certificate.
Brian: If we cannot agree within the Forum, then individual root programs should announce what they intend to do. The advantage of doing it within the Forum is that there is consistency and everyone knows what to expect. As I understand the reason for the Baseline Requirements, they were to give CAs more consistency across browser root program policies.
Ben: We could follow the Symantec approach and then just revoke certificates at that date, and it isn’t that auditable, but at least it gives people a date to look at, or on the other hand, maybe people want SHA1 certificates beyond that date, and we just leave it up to the browsers to turn SHA1 support off on January 1, 2017, and then who would want one of those certificates.
Kirk: I see Rick’s point, why not allow people to use it past 2017.
Rick: That’s not my point.
Kirk: Well, I see the reasoning behind warning the user and giving them both a SHA1 and SHA2 certificate.
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.
Moudrick: We need a date for not issuing them and we need a date for not recognizing them.
Ryan: That’s why we need these dates—to balance these burdens.
Dean: 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.
Rick: That’s why I’m saying we need flexibility.
Chris: The two certificates solves the refund-revenue-recognition problem. There is no return policy because they have something they can move over to.
Ben: Why can’t we just adopt the Microsoft policy as the Baseline Requirements rule?
Chris: Don’t we have to go with that? I was hoping we could coordinate a unified voice. The meeting in 2015 is not going to result in any change.
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.
Chris: Rick, could you start putting a pain point out to customers starting January 2015?
Rick: I don’t know. On one of our retail platforms, the customer buys the certificate based on lifetime first and then they have to choose whether it is SHA1 or SHA2.
Chris: It would be great if we can all come to consensus on this together.
Doug: I agree with Rick, because it confuses the customer because they want to buy a three-year certificate and they fear anything but SHA1.
Ryan: We have known about concern with SHA1 since 2009.
Bob: So we should be experimenting now, not in 2016.
Ben: It sounds like most of us have some hybrid solution in place already.
Brian: One of the reasons we should work on this now is to reduce our support costs in 2017. Our goal isn’t to cause anyone pain or inconvenience now, but to ensure that in 2017 any inconvenience or pain is as close to zero as possible and to make this fair to every CA, because if it is coded in the browser, then there are no exceptions, and everyone can plan accordingly. Whatever way, some CAs are going to experience some pain in transitioning to whatever the migration plan is implemented.
Rick: We need to lead by example, and all CA/Browser Forum members should lead by example by installing SHA2 on our own websites.
Brian: I’m not saying we all move to SHA2, I’m saying we shouldn’t have certificates valid into 2017 with SHA1.
Ryan: There are market realities for why we’re all still using SHA1, but we need to find ways to ratchet up SHA2 so that other software vendors, site operators, and industry players see the move to SHA2.
Brian: Browser checks will be implemented regardless of what the Forum decides, but I think the purpose of this discussion is come up with a unified policy statement about this issue. I believe that if we adopt language similar to what Microsoft has said, then CAs will have something to point customers to as an industry-wide standard as background for explaining one way or another
Dean: I agree, but I don’t think we need to go beyond with additional requirements. We can’t have additional, different browser requirements.
Iñigo: Is this for just SSL?
Tom: No. All certificates.
Richard: In China, the big challenge is that online trade is in the billions of dollars and end users will have a problem.
Brian: But these big sites that do large amounts of business will be able to come up with solutions for their end users that are still on SHA1.
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.
Richard: But maybe government support in China will help.
Chris: If we can decide something here, then that will be of help with that.
Ben: For a ballot, is there anything more we need to say?
Dean: Let’s put the Microsoft language into a draft ballot and circulate it for discussion and comment.
Kirk: Let’s prepare a nice PDF white paper like what we have for the deprecation of internal server names for the Forum that explains what is going to happen. Microsoft has a list of devices that don’t support SHA2, which we can include in the white paper as appendix. The white paper would say, check the list now and if you’re device is on the list, switch that device out now because it won’t work with SHA2.
Ben: Good idea, because we have to remember to do outreach on this.
[End of discussion]
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
|
Ryan Sleevi
Ryan – you keep saying Google told all CAs about this policy six months ago. What are you referring to? The CA/Browser Forum meeting in February? You made no mention of this policy at that time. See again the meeting minutes below from February 19, 2014.
Kirk Hall
Ryan Sleevi
rick_a...@symantec.com
Ryan Sleevi
Adrienne Porter Felt
Jeffrey Yasskin
Ryan,
I support your endorsement of the previously communicated Microsoft policy sent directly to all CAs informing us of the 2016 and 2017 deprecation milestones. In my own business, like many CAs, I am working on this task actively and I will achieve the two goals.
In the course of reviewing this discussion and the CABFPub posts, I feel that the conversation is devolving toward a door slam and I want to prevent that by sharing further perspective from my own experience. I need to amplify the concerns of my friends who have already contributed great objections to the strategy. I want to point out areas where I feel that the conversation is getting counter-productive and subject to failure.
I’m going to bulletize as a favor to weary eyes.
- It is incorrect to conclude that because a certificate is issued for three years, it will live out those full three years regardless of compliance impacts.
- It is fully within CA policy, practice, customer relationship, and software functionality to replace certificates that are about to enter a non-compliance period with those that are compliant at no cost.
- Certificates being issued now out of compliance to the future milestones are issued by a CA knowing that they will be replaced.
Kirk Hall
Ryan Sleevi
kirk...@trendmicro.com
Thanks. But nothing in those snippets indicates that in August 2014 SHA-1 certificate users will be told by Google that they must switch out all their certs in 6-12 weeks or else their websites will receive untrusted UIs in Chrome – does it?
As I mentioned before, our company already restricted our offerings so no customer can get a SHA-1 certificate expiring after 2016, so we are already in compliance. Why are you effectively pushing back the SHA-1 deprecation deadline by two years on such short notice?
I think this is very unfortunate – Google seems angry at (some) CAs for past tardiness in transitions to stronger technologies (MD5, 1024 bit certs), but not all CAs are guilty and in any case this is a very punitive policy.
In fact, you are actually punishing website owners with perfectly valid SHA-1 certs who will be in full compliance with the SHA-1 deprecation policy by 2017 – they have done nothing wrong, but because of Google’s new August 2014 policy, they have to speed up compliance to this year, at a very inconvenient time for many.
Finally, in my opinion, you are effectively punishing Chrome users as well (or confusing them, at the very least) by showing them “untrusted” Chrome UIs this fall for certs that are, in fact, perfectly valid under a 2017 SHA-1 deprecation policy – all in the name of social engineering (pushing website owners and CAs to move faster). Is this really what you want to do to Chrome users with Chrome’s UI? It’s like “crying wolf” – telling your own customers there is a problem with a website when there actually isn’t (you are just trying to make the website move faster).
Please listen to the people posting on this site and other sites, Ryan, and reconsider your timelines. Do the right thing, and reset the deadline for March 1, 2015 or later. That will accomplish all your stated purposes, and avoid hurting a lot of people (and Chrome users) unnecessarily.
From: sle...@google.com [mailto:sle...@google.com]
On Behalf Of Ryan Sleevi
Sent: Thursday, August 28, 2014 4:19 PM
To: Kirk Hall (RD-US)
Cc: security-dev; Ryan Sleevi; blink-dev; steve...@gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates
In a discussion of SHA-1 deprecation:
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
Chris Palmer
<kirk...@trendmicro.com> wrote:
> As I mentioned before, our company already restricted our offerings so no customer can get a SHA-1 certificate expiring after 2016, so we are already in compliance.
> Why are you effectively pushing back the SHA-1 deprecation deadline by two years on such short notice?
for when SHA-1 will be not just deprecated but *outright disabled*.
So, we are surfacing the deprecation *now*, so that all CAs will do as
Trend Micro has done, and won't suddenly be caught off-guard when
SHA-1 is indeed turned off as scheduled.
kirk...@trendmicro.com
This policy is making compliant companies like Trend Micro contact all their customers now and make them replace all their SHA-1 certs (certs that all expire in 2014, 2015, and 2016) now -- when there is no need for that. Some customers have thousands of certs from many dozens of domains -- domestic and international. Why do we and our customers have to do this?
A six-month delay would still effectively eliminate all SHA-1 certs by the end of 2015 -- the same as Google's current deadline -- so you reach the same result. So why not give website owners and CAs some extra time to respond to this surprise policy? And get them past the holiday retail season website lockdown?
-----Original Message-----
From: Chris Palmer [mailto:pal...@google.com]
Sent: Thursday, August 28, 2014 4:39 PM
To: Kirk Hall (RD-US)
Cc: rsl...@chromium.org; security-dev; blink-dev; steve...@gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
Ryan Sleevi
kirk...@trendmicro.com
Why do you have to attack SHA-1 certs now that expire in 2016? If you just focus on certs expiring in 2017 or later, you will save thousands of website owners from needless switching of their current SHA-1 certs (when then will never be receiving SHA-1 replacement certs that expire in 2017).
This makes no sense -- can you explain why Google's SHA-1 early deprecation isn't limited to SHA-1 certs that expire in 2017 or later??? That would catch everything, and prevent issuance of new 2017 certs.
To: Kirk Hall (RD-US)
Cc: rsl...@chromium.org; security-dev; blink-dev; steve...@gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
kirk...@trendmicro.com
Why not just limit your deprecation to SHA-1 certs that expire on or after January 1, 2017 – those in use, and those issued in the future? That’s a much more logical way to accomplish this goal.
Ryan Sleevi
Also, Chris -- who doesn't Google just deprecate SHA-1 certificates that expire on or after January 1, 2017 (now, or in six months) -- I can guarantee once that happens those certs will disappear, which is your stated goal -- and no new certs expiring in 2017 or later will ever be issued.
Why do you have to attack SHA-1 certs now that expire in 2016? If you just focus on certs expiring in 2017 or later, you will save thousands of website owners from needless switching of their current SHA-1 certs (when then will never be receiving SHA-1 replacement certs that expire in 2017).
This makes no sense -- can you explain why Google's SHA-1 early deprecation isn't limited to SHA-1 certs that expire in 2017 or later??? That would catch everything, and prevent issuance of new 2017 certs.
rowl...@gmail.com
You keep insinuating it's the CAs resisting improvements, but I think that is missing the point everyone is trying to make. Look at what's happened over the past year:
1. All website owners had to transfer to 2048 bit certs to comply with the Mozilla and Microsoft policy. This is despite the fact there were known incompatibilities with many legacy devices, particularly payment terminals.
2. Heartbleed required everyone to revoke and replace their certificate. This was a result of a security vulnerability in OpenSSL, not an issue with CAs or browsers.
3. Internal names deprecation was accelerated for certain gTLDs. Any entity using a name was forced to upgrade their non-complaint device and use an FQDN.
4. Microsoft announced a policy that all certs must be SHA2 as of 2017. CAs communicated this policy and replaced SHA1 certificates expiring in 2017 with new SHA2 certs.
5. Google announced a brand new policy that SHA1 certs would receive a warning. Again, each of these customers will need to replace their certs in the next 12 weeks.
Although the reason behind each of these replacement certs is valid, a website partnering with a completely compliant CA will have replaced their certificates five times this year!
I don't think the CAs posting here are necessarily concerned about burdnes on the CA - improved security is important and bearing these costs is part of participating in the industry. What's concerning is the sporadic timing of these events and the ability of website owners to comply with the changes, especially two separate SHA2 transitions. Having to replace a certificate five times is difficult for enterprises with set roll-out periods to swallow. Not every company is Google, and most can't make this many changes to their infrastructure without causing issues. Seemingly sporadic and uncoordinated improvements makes TLS, something most people already don't understand, even more difficult to effectively deploy and maintain.
The CAB Forum was founded to consolidate these type of announcements and changes. If the browsers can coordinate (one of the purposes of having a Browser forum), the entire community would become more successful in implementing these changes.
Jeremy
kirk...@trendmicro.com
Ryan, I think you have misinterpreted both Microsoft’s and Mozilla’s policies.
Microsoft says “issue no new SHA-1 certs on or after 1/1/2016” – but SHA-1 certs issued before that date that expire by 12/31/2016 are ok – they don’t need to be switched out, now or later. Only SHA-1 certs expiring in 2017 are invalid.
Mozilla’s policy is more or less the same – SHA-1 certs will be treated as valid through 12/31/2016. CAs should refrain from issuing any new ones now (even those expiring in 2016), but may do so if the customer says it’s necessary for compatibility reasons. Only SHA-1 certs expiring in 2017 are invalid.
So 2016 SHA-1 certs are ok with both browsers – but 2017 certs are not.
I can assure you that any Trend Micro customer who has a SHA-1 cert expiring in Nov. or Dec. 2016 (there are no such customers today – we only issue one-year and two-year certs) will know from us well in advance what is coming. Maybe we will pull back our maximum validity date for new SHA-1 certs to earlier than Nov. 2016 – it’s something to think about.
I can also assure you that a Trend Micro customer with SHA-1 certs expiring in the first half of 2016 would much rather receive reminders and pestering notices from us over the next 18 months to change to SHA-256 (as they will) than to have to change hundreds of 2016 certs today and again in 2015 – no question about it.
From: sle...@google.com [mailto:sle...@google.com]
On Behalf Of Ryan Sleevi
Sent: Thursday, August 28, 2014 5:22 PM
To: Kirk Hall (RD-US)
Cc: Chris Palmer; rsl...@chromium.org; security-dev; blink-dev; steve...@gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates
On Thu, Aug 28, 2014 at 4:55 PM, kirk...@trendmicro.com <kirk...@trendmicro.com> wrote:
|
Ryan Sleevi
Ryan,
You keep insinuating it's the CAs resisting improvements, but I think that is missing the point everyone is trying to make. Look at what's happened over the past year:
1. All website owners had to transfer to 2048 bit certs to comply with the Mozilla and Microsoft policy. This is despite the fact there were known incompatibilities with many legacy devices, particularly payment terminals.
2. Heartbleed required everyone to revoke and replace their certificate. This was a result of a security vulnerability in OpenSSL, not an issue with CAs or browsers.
3. Internal names deprecation was accelerated for certain gTLDs. Any entity using a name was forced to upgrade their non-complaint device and use an FQDN.
4. Microsoft announced a policy that all certs must be SHA2 as of 2017. CAs communicated this policy and replaced SHA1 certificates expiring in 2017 with new SHA2 certs.
5. Google announced a brand new policy that SHA1 certs would receive a warning. Again, each of these customers will need to replace their certs in the next 12 weeks.
Although the reason behind each of these replacement certs is valid, a website partnering with a completely compliant CA will have replaced their certificates five times this year!
rowl...@gmail.com
All of our customers using a SHA1 cert are well aware of the need transition to SHA2. In fact, that's why we don't have certificates expiring in 2017 - they've already started making the change. The certs you identified as expiring in 2016 are using that time to transition. A warning isn't necessary - it's already in the works.
Each of them are on a path towards implementing. Accelerating this process to 12 weeks (a UI degradation is a deprecation) interferes with all of those deprecation plans and cycles. The pain isn't on the CA here (any of our customers can replace their SHA1 with a SHA2 for free). It's on the website owners scrambling to meet a new deadline.
Chris Palmer
On Aug 28, 2014 6:37 PM, <rowl...@gmail.com> wrote:
> You keep insinuating it's the CAs resisting improvements,
On the Mozilla list we've got Kathleen trying to cope with CAs who are trying to hide the particulars of their non-compliance with the BRs — requirements which CAs themselves helped draft. So that doesn't exactly look good, you have to admit.
> 1. All website owners had to transfer to 2048 bit certs to comply with the Mozilla and Microsoft policy. This is despite the fact there were known incompatibilities with many legacy devices, particularly payment terminals.
As we noted at the time, what POS machines (e.g.) are willing to/have to accept is irrelevant to the public web PKI.
> 2. Heartbleed required everyone to revoke and replace their certificate. This was a result of a security vulnerability in OpenSSL, not an issue with CAs or browsers.
Yes, that was very sad for everyone. Say, do CAs want to help us find and fix bugs in crypto libraries? It's a big job, so any engineering help you can offer is welcome.
> 3. Internal names deprecation was accelerated for certain gTLDs. Any entity using a name was forced to upgrade their non-complaint device and use an FQDN.
CAs could have avoided this problem by not issuing certificates for names, and IP addresses, that they could not possibly have verified.
> 4. Microsoft announced a policy that all certs must be SHA2 as of 2017. CAs communicated this policy and replaced SHA1 certificates expiring in 2017 with new SHA2 certs.
Maybe some CAs, but we know for sure some others were hoping SHA-1 deprecation would go away, or that we'd forget about it. If everyone had taken it as seriously as you, we wouldn't be having this anxiety right now.
> 5. Google announced a brand new policy that SHA1 certs would receive a warning. Again, each of these customers will need to replace their certs in the next 12 weeks.
Only if one ignores fairly clear statements from 6 months ago. Keep in mind that it's already 12 *years* after we've known from public literature that SHA-1 is significantly weaker than its designed guarantee. Who knows what the spooks have known, for how long.
> Although the reason behind each of these replacement certs is valid, a website partnering with a completely compliant CA will have replaced their certificates five times this year!
Software is a process, not a product. We browsers have to ship a new stable release every 6 – 8 weeks, because that's what it takes.
Chris Palmer
> Only if one ignores fairly clear statements from 6 months ago. Keep in mind that it's already 12 *years* after we've known from public literature that SHA-1 is significantly weaker than its designed guarantee.
Oops, 9 years now; 12 years in 2017. Sorry about that.
kirk...@trendmicro.com
Chris – a serious question. Is it true that google.com is still using SHA-1 in both end-entity and intermediate certificates today (as has been posted to this site)? If so, how can Google be so condemning of ordinary websites that are also using SHA-1 certs today, even though there has been discussion of SHA-1’s potential weakness, as you say, for several years?
So many of the postings on this topics have shown a strong antipathy toward CAs – toward ALL CAs, without making any distinctions. Google is painting everyone with the same brush. How can we turn this around, and create a more collaborative environment among browsers, browser users, CAs, website owners?
Google’s current policy will be creating a kind of chaos for many website owners in the next few weeks who have no idea why this is happening. It will be affecting websites that have already started transition plans to SHA-256 certs before 2017. Isn’t there a better way?
From: securi...@chromium.org [mailto:securi...@chromium.org]
Sent: Thursday, August 28, 2014 9:54 PM
To: Jeremy Rowley
Cc: blink-dev; security-dev; rsleevi; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates
> Only if one ignores fairly clear statements from 6 months ago. Keep in mind that it's already 12 *years* after we've known from public literature that SHA-1 is significantly weaker than its designed guarantee.
Oops, 9 years now; 12 years in 2017. Sorry about that.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
|
steve...@gmail.com
The unwillingness to account for logistics and seasonal issues of major businesses that fuel the economy SSL enables in a reasonable timeframe is now documented for CAs to show to our customer bases by including a link to this thread in our customer broadcasts. It has been clearly demonstrated that the CA population did not construe the February CABF meeting to imply that the planned action will occur. Each of us now has a base of response from other CAs such that none of us appear negligent in interpretation of the February message.
bruce....@entrust.com
Thanks, Bruce.
Adrienne Porter Felt
rowl...@gmail.com
>
> On the Mozilla list we've got Kathleen trying to cope with CAs who are trying to hide the particulars of their non-compliance with the BRs — requirements which CAs themselves helped draft. So that doesn't exactly look good, you have to admit.
>
> > 1. All website owners had to transfer to 2048 bit certs to comply with the Mozilla and Microsoft policy. This is despite the fact there were known incompatibilities with many legacy devices, particularly payment terminals.
>
> As we noted at the time, what POS machines (e.g.) are willing to/have to accept is irrelevant to the public web PKI.
>> 2. Heartbleed required everyone to revoke and replace their certificate. This was a result of a security vulnerability in OpenSSL, not an issue with CAs or browsers.
>
> Yes, that was very sad for everyone. Say, do CAs want to help us find and fix bugs in crypto libraries? It's a big job, so any engineering help you can offer is welcome.
> > 3. Internal names deprecation was accelerated for certain gTLDs. Any entity using a name was forced to upgrade their non-complaint device and use an FQDN.
>
> CAs could have avoided this problem by not issuing certificates for names, and IP addresses, that they could not possibly have verified.
> > 4. Microsoft announced a policy that all certs must be SHA2 as of 2017. CAs communicated this policy and replaced SHA1 certificates expiring in 2017 with new SHA2 certs.
>
> Maybe some CAs, but we know for sure some others were hoping SHA-1 deprecation would go away, or that we'd forget about it. If everyone had taken it as seriously as you, we wouldn't be having this anxiety right now.
> > 5. Google announced a brand new policy that SHA1 certs would receive a warning. Again, each of these customers will need to replace their certs in the next 12 weeks.
>
> Only if one ignores fairly clear statements from 6 months ago. Keep in mind that it's already 12 *years* after we've known from public literature that SHA-1 is significantly weaker than its designed guarantee. Who knows what the spooks have known, for how long.
> > Although the reason behind each of these replacement certs is valid, a website partnering with a completely compliant CA will have replaced their certificates five times this year!
>
> Software is a process, not a product. We browsers have to ship a new stable release every 6 – 8 weeks, because that's what it takes.
I guess I've said my two cents by now. Really, I'm just hoping we can find a way as an internet community to work together to make this easier on everyone. I imagine there will always be some resistance to change, but, for the most part, I think everyone here is just looking for ways to make this happen without causing a lot of confusion and panic. I appreciate your consideration on this and look forward to figuring something out that benefits everyone.
Brian Smith
<net...@chromium.org> wrote:
> On Mon, Aug 25, 2014 at 3:46 PM, Brian Smith <br...@briansmith.org> wrote:
>
>> I don't know how big the Chrome-on-XP-SP2 userbase is. It seems like
>> it is large enough that the Chrome team (list like, IIRC, the Firefox
>> team does for Firefox-on-XP-SP2) feels justified in continuing to
>> supporting them indefinitely. It seems like websites also will want to
>> support those users too, but it seems like how to do that is still an
>> unsolved problem.
>
> Well, what about Twitter? I don't have a sufficiently-old computer to
> be sure, but it looks like Twitter uses an EE cert signed with SHA-256
> + RSA.
>
> Maybe Twitter is distinguishing SHA-256 capable vs. non-capable
> clients, and serving different chains? Otherwise, a site as important
> as Twitter seems to be OK with not working on old platforms.
>
> And if that's true, maybe nobody else needs to care, either? Very few
> sites can claim to be a bigger deal than Twitter...
In the last week, I've talked to quite a few people that seem to think
that Chrome-on-XP-SP<3 marketshare is big enough to care about, even
if Twitter doesn't seem very concerned about it. Also note that I've
been told that https://api.twitter.com does use SHA-1 certificates at
least for some clients (I was told that this was done for Blackberry
clients, specifically. I don't know the details). Also see Nick's
email in this thread, of which I quote the relevant part here:
On Fri, Aug 22, 2014 at 12:36 PM, Nick Sullivan <ni...@cloudflare.com> wrote:
> 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.
Also, I am not concerned about websites that have already switched to
(or enabled) HTTPS. I am more concerned about websites that haven't
yet provided an HTTPS mode, like baidu.com (Alexa #5), amazon.com
(Alexa #8), and qq.com (Alexa #9), and websites that haven't switched
to HTTPS-by-default yet (e.g. Wikipkedia, which is Alexa #6). It seems
likely that these types of websites are less likely to be willing to
trade off their Chrome-on-SP<3 users to do SHA-2. I worry that they
may, instead, just avoid switching to HTTPS-by-default, which would be
a negative result.
Therefore, I think it is likely worthwhile to find some solution so
that a site can use SHA-1 certificates for Chrome-on-Windows-XP-SP<3.
I think there are three types of solutions:
1. Some kind of indicator of the lack of SHA-2 support could be added
to the TLS 1.2 handshake of Chrome on SP<3; either a proposed standard
mechanism (preferable) or a totally proprietary mechanism.
2. On XP<3, when certificate validation fails and the end-entity
certificate was signed with a SHA-2-based signature algorithm, Chrome
could fall back to the NSS-based certificate verification that is is
(was?) using on Linux-ish platforms, as the NSS-based verification
logic does support SHA-2. The presumption you would have to make here
is that nobody using SP<3 is using group policy to disable root CAs
that are trusted by NSS, and/or they just don't care too much about
managing root CAs. Some websites (websites using custom trust anchors)
still wouldn't work on SP<3, but most public websites would work
(evidence: pretty much all websites have been working with Firefox for
a long time, and Firefox used the NSS-based certificate verification
for a long time.)
3. Similar to #2, on XP<3 you could fall back to using the
mozilla::pkix verification logic in conjunction with the Windows
certificate store instead of the NSS certificate store.
I feel like #1 is something that doesn't require too much effort. I
think #3 and #2 are more complete solutions (since everything would
"just work"), but probably not worth the effort, risk, or delay they
would bring.
Again, I think asking websites to drop support for Chrome on Windows
XP SP<3 is not unreasonable, but nobody I've talked to seems to like
that idea, because there is a risk that it would cost them lost
revenue. Perhaps they could be reassured if they had some evidence
that Chrome on XP<3 marketshare is very low, but I think that might
not be the case.
Cheers,
Brian
Ryan Sleevi
Or
4) Chrome doesn't support XP<SP3, as an insecure and out of date system, and helps the user install the necessary security patches, such as through a user alert when they launch Chrome warning they are out of date and will be unable to access sites and securely browse the web.
Brian Smith
>> 1. Some kind of indicator of the lack of SHA-2 support could be added
>> to the TLS 1.2 handshake of Chrome on SP<3; either a proposed standard
>> mechanism (preferable) or a totally proprietary mechanism.
>
>
> 4) Chrome doesn't support XP<SP3, as an insecure and out of date system, and
> helps the user install the necessary security patches, such as through a
> user alert when they launch Chrome warning they are out of date and will be
> unable to access sites and securely browse the web.
Going back to your original email:
> - 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.
So websites that are unwilling to drop support for Chrome-on-SP<3
users can work around this issue by giving all Chrome users (or all
users) a SHA-1-based certificate with notAfter < 2016-01-01, waiting
to switch to SHA-2 only in late 2015, right? Hopefully by 2016
Chrome-on-SP2 usage will be low enough that no websites will care
about dropping support for that configuration. I was hoping to find a
solution that didn't encourage people to wait until 2016 to do SHA-2,
but I can understand why some people would prefer that, as it is
simplest for everybody involved.
Anyway, I don't mean to muck up your thread. Multiple people have
asked me for advice about this issue, so I thought it would be worth
recording the results of that brainstorming here where other people
can find it.
Cheers,
Brian
Ryan Sleevi
On Aug 29, 2014 10:53 AM, "Brian Smith" <br...@briansmith.org> wrote:
>
> On Fri, Aug 29, 2014 at 10:20 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
> >> 1. Some kind of indicator of the lack of SHA-2 support could be added
> >> to the TLS 1.2 handshake of Chrome on SP<3; either a proposed standard
> >> mechanism (preferable) or a totally proprietary mechanism.
> >
> > Or
> >
> > 4) Chrome doesn't support XP<SP3, as an insecure and out of date system, and
> > helps the user install the necessary security patches, such as through a
> > user alert when they launch Chrome warning they are out of date and will be
> > unable to access sites and securely browse the web.
>
> Like I said, I think that is fine.
>
> Going back to your original email:
>
> > - 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.
>
> So websites that are unwilling to drop support for Chrome-on-SP<3
> users can work around this issue by giving all Chrome users (or all
> users) a SHA-1-based certificate with notAfter < 2016-01-01, waiting
> to switch to SHA-2 only in late 2015, right?
Yes.
> Hopefully by 2016
> Chrome-on-SP2 usage will be low enough that no websites will care
> about dropping support for that configuration.
I think no website should care now, the percentage is so low, but as mentioned, this is also about Chrome no longer supporting this config.
At some point, we as an industry have to be able to deprecate things, and I'm not sure what more can be done for these users that hasn't already been said.
Put differently, if Chrome doesn't support users on XP<SP3, what's the issue?
> I was hoping to find a
> solution that didn't encourage people to wait until 2016 to do SHA-2,
> but I can understand why some people would prefer that, as it is
> simplest for everybody involved.
>
> Anyway, I don't mean to muck up your thread. Multiple people have
> asked me for advice about this issue, so I thought it would be worth
> recording the results of that brainstorming here where other people
> can find it.
>
That's the entire point of this thread - to find and understand the issues from the community.
Sure, the vast majority of this thread has been spent correcting misstatements and inaccuracies, or explaining that the issue is broader than one particular market (e.g. it includes ISVs, enterprises, schools, antivirus, etc) or one particular class of user (that 2016 cert holders are as affected as 2017 cert holders, even though things don't go away until 2017)
However, understanding real affects, seeing proposals for real timelines and what and how that time will be used differently than the past 6 months (CA/B Forum), 3 years (Baseline Requirements), or 9 years (known broken) is all helpful in factoring in the many tradeoffs and goals.
In particular, thanks for exploring real and meaningful solutions that help balance the full concerns, as well as providing real details for when and where those solutions don't work.
> Cheers,
> Brian
Brian Smith
>Brian Smith wrote:
>> Hopefully by 2016
>> Chrome-on-SP2 usage will be low enough that no websites will care
>> about dropping support for that configuration.
>
> I think no website should care now, the percentage is so low, but as
> mentioned, this is also about Chrome no longer supporting this config.
>
> At some point, we as an industry have to be able to deprecate things, and
> I'm not sure what more can be done for these users that hasn't already been
> said.
>
> Put differently, if Chrome doesn't support users on XP<SP3, what's the
> issue?
computers to be secure. But we prefer to be able to let customers give
us money much more than we prefer their computer to be secure." Also,
it seems websites have trouble differentiating XP<3 traffic from SP3
traffic, so they do not know, like you do, that the percentage is so
low that it isn't worth supporting.
(Incidentally, I have a hypothesis that AES-NI hardware is negatively
correlated with SP<3, and so the fact that Chrome's cipher suite list
is in a different order when AES-NI is present might be helpful for
people who are still interested in switching to SHA-2 with reduced
risk, though it isn't going to be perfect.)
Cheers,
Brian