SHA-2 algorithm: The how and why of the transition

I saw that Microsoft is phasing out SHA-1 support as of Jan. 1, 2016, but nearly all of the production Web servers on the Internet still use it, including ours. In the wake of Heartbleed, is it time to prioritize the transition to the SHA-2 algorithm, and if so, how should we go about it?

More than half a million SSL certificates have been potentially compromised as a result of the Heartbleed vulnerability. Affected certificates should be revoked and reissued as a matter of urgency, and administrators would be wise to take advantage of this forced change to migrate to the SHA-2 cryptographic algorithm instead of using the less-secure SHA-1 algorithm.

Nearly 200,000 valid third-party certificates are now signed with SHA-2, yet this still only accounts for 6.6% of all valid third-party certificates currently in use on the Web. In the wake of the Heartbleed flaw, the total number of certificates signed with SHA-2 has jumped by more than 50%. As the migration to SHA-2 is inevitable, it makes sense even for those not affected by Heartbleed to plan for the transition now.

Practical attacks against the SHA-1 algorithm are close to being in reach of government agencies, potentially enabling attackers to impersonate secure websites. SHA-2 doesn't suffer from SHA-1's mathematical weaknesses and offers hash functions with digest lengths of 224-, 256-, 384- or 512-bits with SHA-256 and SHA-512 the most commonly used. The majority of SSL certificates are using 2048-bit keys, and at this point there is no need to consider a longer key length unless a certificate is being used for an extended period of time (such as an in-house certificate authority or an OpenPGP primary key). Some hardware -- including smart cards and readers -- don't yet support keys bigger than 2048-bits, and longer keys use more CPU cycles during encryption and authentication. The NIST speculates that 2048-bit keys will be valid up to about the year 2030.

SHA-2 certificates are compatible with most updated modern Web browsers, OS platforms, mail clients and mobile devices. For enterprises running their own websites, webmasters need to request new SHA-2 certificates to replace any certificates using SHA-1 and expiring after January 1, 2017, otherwise their servers will not be trusted by Windows-based devices (all Windows devices will stop trusting SHA-1 certificates after this date).

Legacy systems that make SSL connections along with software and hardware (such as games consoles, phones and embedded devices) that rely on hard-coded certificates will require a well-tested migration plan to ensure that any certificate replacement doesn't cause major disruptions or break existing technologies. Certain software may also need updating if it is unable to support SHA-2 encryption.

Wherever possible, use one of the two established crypto libraries -- either Windows Crypto library or OpenSSL. Both support SHA-2.

If you start the migration process now, 15 months should be plenty of time to make the necessary changes and avoid a situation where mission-critical systems become reliant on insecure protocols.

Note: Certificate usage statistics by Netcraft.

Ask the Expert!
Have a question about application security? Send it via email today! (All questions are anonymous.)