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
No comments:
Post a Comment