These customers have opted to go through the necessary growing pains and education now, which nearly all companies will encounter sometime this year. If you haven’t heard, it’s time to ditch SHA-1 and get on the SHA-2 train. The longer you wait, the less time you'll have to do it without panicking.
Over the coming years, particualrly this one and next, many digital-certificate-consuming devices and applications will begin to display warnings/errors or operationally fail if a digital certificate containing the SHA-1 (or earlier) hash is presented. Why the change? Because the SHA-1 hash has been shown to suffer cryptographic weaknesses to the point where many experts think its days of useful protection are numbered.
Of course, SHA-1 is the most common hash today, and many applications and devices don’t yet accept or understand SHA-2-related hashes or certificates. There's the rub.
Intro to SHA
SHA-1 was designed by the NSA and published as a federal standard in 1995. Hashes are used for digitally signing content for integrity validation and are a part of any digital certificate. Without cryptographically sound hashing algorithms, digital authentication and integrity would be very hard to do, if not impossible.
In 2002, SHA-2 became the new recommended hashing standard. SHA-2 is often called the SHA-2 family of hashes because it contains many different-size hashes, including 224-, 256-, 384-, and 512-bit digests. When someone says they are using the SHA-2 hash, you don’t know which bit length they are using, but the most popular one is 256 bits (by a large margin). Although SHA-2 is constantly attacked and minor weaknesses are noted, in crypto-speak, it's considered "strong." Without question, It's way better than SHA-1, which experts believe will be fallible in the near term.
SHA-1 deprecation handling
No surprise that many software vendors, especially those with browsers (which consume most of the digital certificates we use today), are actively moving to SHA-2. Expect most Internet browsers to display warning messages or errors soon. Here's a decent summary of the major browser vendors' position statements.
Each vendor will handle matters differently, but devices will move slower than software products, simply because software is easier to upgrade. Of course, in many cases, the software with which you access the hardware device will dictate the SHA migration. For example, the LogRhythm event log appliance requires Google’s Chrome browser for access and management -- and Chrome is moving to SHA-2.
Starting this year, Google’s Chrome browser will simply show a warning indicator for SHA-1 certificates with validity dates past Jan. 1, 2016. For certificates with validity dates past Jan. 1, 2017, there will be a warning, plus the protected content will be treated as mixed content, which will require additional user interaction.
Microsoft has announced an even more aggressive stance:
There will be separate timelines for discontinuing SHA1-based SSL and code signing end-entity certificates … CAs must stop issuing new SHA1 SSL and Code Signing end-entity certificates by 1 January 2016 … For SSL certificates, Windows will stop accepting SHA1 end-entity certificates by 1 January 2017. This means any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017 … For code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps after 1 January 2016. SHA1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.
Check with vendor of your browser of choice for more details. It’s expected that most public CAs (Certification Authorities) will no longer issue SHA-1-based certificates with useful lives beyond Jan. 1, 2017. Everything after will be SHA-2. If you currently have a public-facing website with an SHA-1 Web certificate, you’ll most certainly want to upgrade to SHA-2 before that date.
Unfortunately, the move from SHA-1 to SHA-2 is a one-way operation in most server scenarios. For example, once you move your Web server’s certificate from SHA-1 to SHA-2, clients that don’t understand SHA-2 certificates may see warnings or errors -- or fail. SHA-2 migration will be a risky jump for unsupported applications and devices.
The hardest part of an SHA-2 migration project is determining which devices and applications work with SHA-2. If the consuming devices don’t understand SHA-2, expect failure or an error message -- which probably won't be as enlightening as “SHA-2 unrecognized.” Instead, brace yourself for: “Certificate not recognized,” “Connection not sure,” “Connection can’t be established,” “Bad certificate,” or “Untrusted certificate.”
Think of your mission to determine what will or won't work as a kind of mini-Y2K project. Start by trying to inventory every unique device, OS, and application that will need to understand SHA-2. Then put together a team of people to test whether SHA-2 works. You can tentatively rely on vendor attestations, but until you test using a SHA-2 certificate, you won’t know for sure.
Upgrading your applications and devices will not be trivial and probably take longer than you think. Even now, I see a ton of devices and applications running older versions of OpenSSL, which should have been patched following Heartbleed, but were not. Remember, too, that upgrading requires formal user testing and acceptance.
If you have an internal PKI (public key infrastructure), you’ll need to prepare it for SHA-2 as well. Sometimes that means upgrading your CAs, getting new CA certs, or installing entirely new PKIs. I recommend the last for a lot of reasons, mostly because a new PKI gives you a chance to start again, free of past mistakes.
On a positive note, you can run parallel PKIs, one with SHA-1 and the other SHA-2, then move consuming devices and applications over as testing allows. Public CAs will move from SHA-1 to SHA-2 for any certificate lifetimes past Jan. 1, 2017, so you might want to concentrate your efforts on servers and applications with public digital certificates.
Migrating from SHA-1 to SHA-2 isn’t hard technically, but it’s a massive logistical change with tons of repercussions and requires lots of testing. It's a lot easier to do over six months or two years than in a rushed panic at the end of 2016.
I don’t think most vendors know the ultimate kill date for SHA-1, but I would guess it will arrive as more and more consumers move to SHA-2. I’ve already seen lots of customers doing this, so avoid being caught up short.
SHA-3: Coming soon
Although no cryptographic weakness has been found in SHA-2, it's considered algorithmically related to SHA-1. Many experts believe its lifecycle will be similar to that of SHA-1.
NIST is already working on SHA-2’s stronger replacement, known as SHA-3, chosen from many submitted hash algorithms and derived from the Keccak family. It was selected in 2012 and is now under review; unless weaknesses are found, it will likely become our next hash standard and recommended for global adoption.
Nonetheless, anyone thinking of delaying their SHA-2 migration in hopes of moving directly to SHA-3 will be greatly disappointed. Widespread adoption of SHA-3 is probably five years away, whereas SHA-2 will likely be required in the next two years.
On top of this, you should no longer consider any SSL certificate secure. If you have an SSL site, it should be migrated to TLS and preferably to TLS 1.2 (or later), which of course supports SHA-2. Personally, I think staying on SSL (versus TLS) carries more risk, so you should switch immediately. When you move from SSL to TLS, you might as well upgrade to SHA-2 at the same time.
Start moving on your SHA-2 and SSL migration projects and don’t get caught looking.