Last Updated: 2015-11-30 19:35:12 UTC
by Johannes Ullrich (Version: 1)
SHA1 (Secure Hashing Algorithm 1) has been in use for about 20 years. More recently, some weaknesses have been identified in SHA1, and in general, faster computing hardware makes it more and more likely that collisions will be found. As a result, SHA2 starts to replace SHA1 and you should see this impacting your users next year. Various software will stop trusting SHA1 signatures, and users may receive warnings about invalid signatures or certificates as a result.
First a very quick primer on digital signatures. The signature verifies who created the document (the signer) and that the document wasn't altered after the fact. In order to do so, a hash of the document is created. Then, the author uses a private key to encrypt the hash. Anybody else may now use the signers public key to decrypt the hash, and verify that the hash is correct. If I can create a second document with the same hash, then I could just copy the signature from the first document and claim the second document is valid. This is the type of collision that a secure hash function is trying to make very difficult. Collisions are always possible with the hash being shorter then the original document. But for a good hash function, it is very very hard to create a second document that matches the first one. SHA2, which is going to replace SHA1, is actually a set of different hash functions (SHA-224 through SHA-512).
The most likely area where you will see issues are SSL certificates. SSL certificates are digitally signed by the certificate authority. Until recently, SHA1 was the default hashing algorithm and there are many certificates still out there that are signed using a SHA1 hash. In addition, some intermediate certificates used by certificate authorities to sign server certificates are still based on SHA1 (and more of a problem as these certificates tend to have a long live time). There are a couple legacy operating systems where you will have issues implementing SHA2, in particular Windows XP SP2 and earlier.
To create SHA2 compliant certificate requests with openssl, you need to add the "-sha256" option. For example:
openssl req -out mydomain.csr -key mydomain.key -new -sha256 . Some old versions of openssl may not support this option.
A good overview of operating systems supporting or not supporting SHA256 can be found here: https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility
Here is a quick table to summarize when SHA1 based certificates are no longer going to work:
|Server Authentication (e.g. https)||1/1/2017|
|Code Signing||1/1/2016||This is your first deadline. But it will not affect web browsers. However, make sure software you distribute is signed using SHA2.|
|Timestamping Certificates||1/1/2017||SHA1 certificates may not be issued after 1/1/2016|
|S/MIME Certificates||N/A||recommended to no longer issue SHA1 certificates|
|OSCP/CRL Signing Certificates||N/A||SHA2 recommended, but no policy enforced|
|OCSP Responses||1/1/2017||if certificate is SHA2, then OCSP signature has to be SHA2 after 1/1/2016|
|CRL Signatures||N/A||no specific policy enforced|
|Code Signature File Hashes||N/A||no specific policy enforces|
|Timestamp Signatures Hashes||1/1/2017||(some 1/1/2016)|
|Mozilla||TLS Server Certificates||not be valid after 1/1/2017
not issues after 1/1/2016
|existing certificates will be fine unless they expire after 1/1/2017|
|Google Chrome||TLS Server Certificates||"secure, but with minor errors" if valid until 12/31/2016
"affirmatively insecure" if valid beyond 1/1/2017
I was not able to find any announcement from Apple regarding OS X or iOS and how it will deal with SHA1 in the future.
If you are concerned about a web server and if it still uses a SHA1 based certificate, then please check ssllabs.com, or http://sha1affected.com.
And what about SHA3? It got ratified recently, and should start showing up in standard libraries soon. But at this point, there is no timetable to phase out SHA2.