Friday, October 24, 2014

SHA-1 Sunsetting, Google, and Your Next Steps.


What is happening, and what was happening?

The SSL Industry and the CA/B Forum have planned for the "sunsetting" (depreciation) of the SHA-1 signing algorithm for quite some time. However, their plan was mainly formed around Microsoft's desires to phase it out in 2017, alongside the end-of-life for Windows XP. This was widely understood to be the approved plan for CAs to follow, and the preparation for moving from SHA-1 to its successor, SHA-2, wouldn't be necessary for many months from now.
However, Google recently made an announcement, in stark contrast to Microsoft's plan, that they are implementing their own SHA-1 sunsetting timeline, which will begin on September 26th 2014.
This timeline has three distinct stages, which will result in degraded visual indicators in Google Chrome (padlock, green-bar) for SHA-1 signed certificates meeting specific criteria (this is discussed in the section "What certificates are affected?" below).
This means it is now necessary to educate and assist our partners and customers on how to make the transition away from SHA-1.

Why?

First, let's understand what SHA-1 does. Both SHA-1 and its successor, SHA-2, are specific types of signing algorithms. Signing algorithms are used as part of the identity validation role that SSL certificates perform. They are mathematical functions (referred to as a "hash") which, when performed, should calculate a persistent and unique value for each file. So, for instance, the Word doc this text is stored in has a unique SHA-1 hash value. If I change a single part of this file – add an extra period somewhere, change a letter, etc. – it will produce a different SHA-1 hash value.
When a certificate is downloaded from a server to the client's browser, a hash is taken of it. The type of hash taken (SHA-1, SHA-2, MD5, etc.) depends on how the certificate is signed. The hash calculated by the browser is compared to the hash value provided by the server, which has been verified by the Certificate Authority (CA) at the time of issuance. If they match, the identity of the certificate and server are verified.

When is this happening?

Google's policy involves three distinct steps, the first beginning on September 26th. On this date, only customers with SHA-1 signed certificates expiring in 2017 are affected. However, the amount of affected certificates will expand in November, and again in Q1 2015. The full details on what certificates are affected is in the below section, "The Nitty Gritty."

What certificates are affected?


Certificates are affected if they meet the any of the following criteria:

•          All certificates from the RapidSSL or QuickSSL family issued before September 15th, 2014                 and expiring after January 31st, 2016 (They are signed by a SHA-1 Intermediate).
•          If they are signed with SHA-1 and expire after January 1st, 2016.
•          They have an Intermediate Certificate Chain that are SHA-1 signed certificates.

To understand the exact certificates affected, please see the below section which gives explicit detail.

The Nitty Gritty1

On September 26th, 2014:

 SHA-1 signed certificates expiring on or after January 1st, 2017 will be treated as "secure, but with minor errors" and will receive the yellow triangle padlock.

On November 7th, 2014:

 SHA-1 signed certificates expiring on or after June 1st, 2016 to December 31st, 2016 are treated as above. Certificates expiring after January 1st, 2017 are treated as "neutral, lacking security." These certificates will receive a blank page icon, as seen with HTTP sessions.
  
In Q1 2015:

 SHA-1 signed certificates expiring on or after January 1st, 2016 to December 31st, 2016 will continue to be treated as "secure, but with minor errors."
SHA-1 signed certificates that expire on or after January 1st, 2017 are treated as "affirmatively insecure." This will be identified by the red "X".

How is the problem solved?

Affected certificates can be fixed by reissuing. (There are no situations where anything other than a reissue is needed.) Our vendors have sped up their implementation of SHA-2 compatible infrastructure due to Google's new policy.
Symantec has officially confirmed that their full product line will have a fully SHA-2 compatible chain "September 12, 2014, and generally available on September 15, 2014." 2 Comodo's full product line is already ready for the SHA-2 transition and by default are now being issued as SHA-2. Certum has announced they will make SHA-2 Certificates available "this year", specifically they are targeting October. This deployment date for Certum may be delayed, so we know they will not be ready for Phase 1 of Google's rollout, but perhaps by Phase 2.
The biggest market at risk is probably China3 or Russia, due to their more extensive use of Windows XP. For the same reason, Enterprise and Government use is also of more concern than Consumer use.

What does The icloudJunction need to do?

We need to identify affected customers and inform them via email that it is necessary to perform: a) reissue your certificate to SHA-2. Some customers may also need to perform: b) install SHA-2 intermediate certificates.
It will be necessary for you to perform a) if you have a SHA-1 certificate, if this is what you selected during the enrollment process. This can affect certificates from any of our providers, and is more likely to affect older certificates.
If you have a certificate from the RapidSSL or Quick SSL product families then your certificate was signed by a SHA-1 Intermediate. This means that it must be reissued so it can be signed by their SHA-2 Intermediate and you must install the new SHA-2 Intermediate to your server. So, everyone who has these products needs to perform a) and b), regardless of if they already have SHA-2 subscriber certificate.
Customers with SHA-1 Comodo certificates also need to reinstall their intermediates once they receive their reissued SHA-2 subscriber certificates (though this has not been confirmed in a live environment – the intermediates may not need to be changed in all cases).
A guide should describe exactly how to do this. Because of the non-critical error presented by remaining on SHA-1, I do not think individual phone calls need to be made to customers for this issue. Mailing materials should also be prepared for resellers to provide a more technical understanding of the technology so they can properly inform and assist their customers.
Customers have to meet a few criteria to be affected: their subscriber certificate must be SHA-1 and their expiration date must fall within with Google's timeline. Alternatively, if their certificate is from the QuickSSL or RapidSSL family, they will need to reinstall their intermediate certificates (regardless of other criteria).
Ideally, we can identify customers who are using SHA-1 in order to avoid mass emailing people solely based on the above date criteria. GeoCenter provides this information, but it is unclear if the same is available from Comodo's Portal. There would be a method of analyzing each live certificate to determine this information, though I am unsure on the feasibility of developing such a tool.

Taking proactive action

I propose our generation process UI be changed to select SHA-2 by default. This will reduce legwork in transitioning customers again in the future. Customers who specifically want/need a SHA-1 certificate can still choose one via the process and a pop-up confirmation box.
The case for people who "need" a SHA-1 certificate is quite small. As previously mentioned, Windows XP is the largest platform with SHA-2 incompatibilities. However, the incompatibility is only with server identification (encryption still works), therefore resulting in the same degraded/absent padlock as Chrome will be presenting if they choose SHA-1. So, unless the customer thinks their user base contains more XP users than Chrome users, they have no reason to prefer SHA-1. The exception to this is specific cases where there is incompatibility amongst specialty networking/enterprise hardware and software.

Sources:
1 The majority of this section comes from Google's official announcement:
http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html

2 Symantec's full statement: "Google has announced that it plans to phase out SHA-1 support via degraded visual indicators. The plan is for that to happen in the upcoming Chrome 39 release on September 26, 2014. Google's plan is still subject to change. To help partners respond to this change, Symantec has accelerated its plan to offer SHA-2 end-entity certs chaining to SHA-2 intermediates. We expect these to be available for testing (by API-integrated partners) in our pre-production environment on September 12, 2014, and generally available on September 15, 2014."
3 The [Alexa Top 50] have some China websites that I am sure 100% is SHA1 since there are still 2.75M Windows XP with SP2 users and 400K Windows 2003 with SP2 users in China. I really don't know how to deal it, currently, we issue SHA1 certs only. The big market share in China is Symantec, I would like to hear the idea from Symantec about this." Richard from WoSign (Chinese CA), on 9/8/14.
4 Confirmed by Comodo US Technical Support and Jason Boone
5 https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=SO19176&actp=search&viewlocale=en_US&searchid=1410276106825
6 https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility
7 Specifically, the hash function SHA-256
8 https://developer.android.com/about/dashboards/index.html?utm_source=ausdroid.net
9 https://developer.apple.com/support/appstore/
10 Source: Duke with Symantec Technical Support, 9/9

11 The SSLStore