Over the last few months, we've been receiving a growing number of inquiries on how to enable support for SHA2 certificates in JSCAPE MFT Server. We later learned that the intention was not just to accommodate SHA2-signed certs but to actually replace SHA1-signed certs with them. In this post, we explain why people are moving from SHA1 to SHA2 and why you need to do so as well.
What are SHA-2 Certificates?
SHA2 certificates are digital certificates whose digital signatures were obtained using the SHA2 (Secure Hash Algorithm 2) cryptographic hash function. To review, X.509 certificate signatures are obtained by running the plaintext portion of the digital certificate (consisting of the subject's name, certificate issuer, validity period, and other information) through a hash function like MD5, SHA1 or SHA2 and then running both the resulting message digest and the CA's private key through a signing algorithm like RSA or DSA.
If you're not familiar with the concept of digital signatures and the role cryptographic hash functions play in generating them, I suggest you read the post "What is a Digital Signature?".
So what about SHA2 certificates? As mentioned, we've been seeing a growing number of migrations from SHA1 to SHA2 certs. This is likely due to the decision of major Web browsers like Chrome, Firefox, and Edge/Internet Explorer to cease support for SHA-1 certificates.
Major browsers are ditching SHA1
Google announced their intention to gradually drop support for SHA1 in Chrome on September 2014. In their original plan, the goal was to put a complete stop to SHA1 support no later than January 2017. However, what they discovered in recent researches was probably not very encouraging because it looks like that January deadline could be moved much earlier.
In fact, the Chrome developers are starting to consider moving it to as early as July this year (2016). As of this writing, that's just less than 2 months from now.
Chrome isn't the only major web browser that's deprecating SHA1. Microsoft's browsers, Edge and Internet Explorer, will likewise start blocking SHA1-signed certificates starting February 2017. However, Mozilla, who originally outlined a similar timetable for Firefox, has currently re-enabled support for SHA-1 to evaluate the impact on users who are still employing legacy devices and software. This move is only temporary, as Mozilla has affirmed its commitment to completely remove SHA1 support eventually.
Once these browsers start blocking SHA-1 certificates and you still haven't migrated to SHA-2, your users will experience problems when they attempt to load web pages through them (i.e. through Chrome, Firefox, and Edge).
But all this leads us to the penultimate question. Why exactly are these browsers ditching SHA-1? Clearly, it should have something to do with some serious vulnerabilities.
Vulnerabilities in SHA-1 and why we need to address them
One of the main properties that determine whether a hash function can be considered secure and fit for use in a production environment is its collision resistance. A collision refers to the condition wherein two messages produce the same message digest.
Collisions can cause problems because it would mean that it would be possible for an attacker to, for instance,
- create an altered version of a document that computes to the same hash as the original,
- affix the digital signature of the original, and
- present the altered document (whith the attached digital signature) as the original.
That explains why, once a cryptographic hash function already becomes significantly susceptible to collisions, it can no longer be considered secure.
There are two main factors that can affect the probability of collisions. One is the design of the hash function itself. The other is the computational power of existing processors. There was a time when, although theoretically possible, it was practically infeasible to break SHA-1 through collision attacks.
Alas, computers, as they always do, have become more powerful. And so today, it is increasingly becoming nearly affordable to overcome SHA1 through collision attacks. That is, organized crime syndicates and nation states who have the financial capability of purchasing powerful computers would be able to carry out collision attacks against SHA1 in the very near future (if they haven't done so yet).
Because cryptographic hash functions are used in data integrity checks (e.g. in HMAC) and digital signatures, this vulnerability can impact secure file transfers that rely on technologies like SSL, TLS, and SSH.
SHA2 vs SHA256
In spite of what might have been seemingly implied earlier, SHA-2 is actually a not a hash function. Rather, it is a family of hash functions that produce 224, 256, 384, or 512-bit hash values (a.k.a. message digests). It currently consists of:
Of the six, SHA256 is the most widely used.
A sample digital certificate displayed in Chrome showing SHA256 as the hash function used
How to enable SHA2 support JSCAPE MFT Server
In order to enable SHA2 support on JSCAPE MFT Server, you just need to install the latest version and the JCE Unlimited Strength Jurisdiction Policy Files distributed by Oracle. The instructions for installing the required files can be found behind that link.
Would you like to start transferring files over secure file transfer protocols like FTPS, HTTPS, AS2 over HTTPS, and SFTP? Download a free, fully-functional evaluation edition of JSCAPE MFT Server now.