Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is
used to highlight other deprecated and insecure practices, such as passive mixed content.
Chrome 40 (Branch point 7 November 2014; Stable after holiday season)
Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.
The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.
Chrome 41 (Branch point in Q1 2015)
Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.
The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.
Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.
Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer
Follow
14 Kommentare :
Looking at a large CA group (InCommon), their CA vendor (AddTrust via Comodo) is both root and cert signed SHA-1, and they issue 3-year certs. That means all certs issued after January 1st 2014 will be marked red in Q1 2015, since most were issued as 3-year certs.
Assuming the vendor can't get a fix in soon, we would have to go back and re-issue all certs with 1-year expirations to go from red-https to caution-https (making expirations be in late 2015 through 2016), then re-issue again once the CA gets their root re-signed and changes all intermediate and cert signing.
Please work with the CA vendors first on getting their act together before breaking large swaths of HTTPS connection reporting. This already represents about 50 issued certs for my team due to renewals we did this year.
The point of this action is to force the CAs to get their act together. Rekeying your cert to use SHA256 is easy enough with most CAs once they support it (for example, GoDaddy you can do it entirely self-service from their web-based management console).
There's a great site which checks both whether your SSL cert is SHA1 or SHA2 AND the whole chain: https://shaaaaaaaaaaaaa.com/
(not my site, and it's open source also)
SHA-1 will eventually get not safe sometime in the future but it is still safe today, so safe that, as far as I can see, all google certificates are SHA-1 signed. They expire every three months so they will not trigger the warning.
Showing the warning today for a certificate that is still safe today is bad. It means training the users to ignore security warnings.
My advice to end users will be to switch to firefox.
We are an MSP and are left in a bad situation as a result of this change be implemented to fast compared to the SSL cert expiration dates. As Justin stated all our certs are 3yrs and taking into consideration of us being a MSP, this will take about 1+ hour per server to upgrade the cert and we have 40+ servers that will not meet Chrome's ssl verification.
I do appreciate Google trying to improve security but I think the implementation needs to be reviewed a little closer and how this change effects users\clients\customers.
Will this change have any effect on Android devices using SSL for email?
Hi I only support phasing out SHA-1 certificates. However, how come when I go to www.google.com (using SSL/TLS) that I see a SHA-1 certificate chain? Not only is the root certificate SHA-1, but all the other certificates in the chain are SHA-1 as well. I know the new rules only go into effect in november and that it actually seems the certificate currently being presented by Google expires on November 25th. Still I would have expected Google to be at the "forefront" with SHA-256 now that you are forcing so many companies to change to this algorithm in a hurry.
How will this change affect browsing to sites which still use SHA1 after 2016/2017 on Android handheld mobile devices? Will these sites be treated the same as sites which use self signed certs?
Can we get some confirmation that the the end user will still have the ability to click through to the site despite the error/warning? This seems overtly aggresive already so I hope that the end user can still click through. I assume they can but I have to ask.
How will the EV certificates look and the green bar after the changes?
This is overly aggressive. While I think Google deserves credit for pushing the web towards higher security, this aggressive method of doing so will cause more headaches than it will prevent.
Essentially breaking HTTPS reporting, and/or reporting sites to users as insecure, when in all practical sense, they are not, seems completely out-of-touch.
Non-savvy users (which is a large part of Chrome's user base, I would expect) will not know how to interpret these errors and will be misled by them.
We could use more security and less misinformation. Try to approach this issue with both of these things in mind, not just one.
This may be old news at this point but, Incommon is my primary CA and we've been told that the functionality to support SHA-2 is coming next Monday 9/22. I'm not sure if if the rollout is phased but it sounds like they are at least addressing the sunset.
If it makes you feel any better we're hit pretty hard by this too. Lots of reissuing just to avoid "scary" Chrome messages. At least it will be mildly more secure?
As Justin pointed out this will cause us to have to reissue many SSL\UCC certs across multiple clients as we purchase 3 year certs as well
I do appreciate Google forcing security improvements but more time should be allowed so that clients\customers have time to become compliant rather than forcing us to re install certs that have been issued after 1/1/2014.
Please consider allowing the warning stage to be extended through 2017 as this noticed was released 9/5/2014.
I just cant see how this can be an issue with most major companies, that have a dedicated IT Administrator. Small businesses, especially the ones who hired an IT company to deploy the infrastructure, but not retained for maintaining it. The same apply to "do-it-yourself" businesses, they just don't have the ability to follow on all the changes happening in IT and InfoSec.
SHA-1 cryptographic hash algorithm is weaker, but newer algorithms are not supported by olders OS's.
Our website has a opening rate of "24.66%" from Windows XP, most of them do not have SP3 installed. On XP with SP2 and lower you cannot view SHA2. It doesn't matter what Browser version you have, you cannot see the website since there was no SHA2 functionality within Windows XP.
Please consider this because I cannot afford to lose customers .. just because they don't know how to upgrade their systems.
At first you said that all websites should be on SSL - especially the ones that have a build shop and collects personal data. Now we cannot change back.
Kommentar veröffentlichen