SHA1 (Secure Hash Algorithm 1) is a popular cryptographic method used to secure eCommerce websites, backups, software updates, document signatures and more.
On 23 Feb 2017, Google announced that they were able to crack SHA1 by using a collision attack dubbed Shattered. This means any server that still uses SHA-1 are vulnerable to attacks.
See how we help web hosting companies
As an Outsourced Tech Support company, we help web hosting providers secure their servers and websites against such vulnerabilities. SHA1 was deprecated in 2015 (dubbed SHA1 sunset), and we replaced it with SHA-256 in all our customer servers by Dec 2016.
In the light of the new Google disclosure, we’re noting down a few common server hardening steps we performed on our customer servers.
1. Find and disable SHA1 certificates
Many of our customers (web hosts) provide SSL to their clients (web site owners). Since 2015, we’ve recommended issuing only SHA-256 certificates when SSLs were renewed.
However, there were websites that obtained certificates from other providers who didn’t insist on SHA-256. We knew these sites would be penalized by Google, and was potentially a hacker magnet.
To find vulnerable websites, we scanned all SSL enabled domains in each server with our proprietary Signature Algorithm check routine, like here:
Once we built a list of weak SSLs, we recommended our customers (web hosts) to contact affected web masters, and offer them SHA-2 certificates. Our tech support team opened pro-active tickets to these webmasters and followed up until a secure SSL was installed.
[ Take care of your customers, before your competitors do. Get world-class support specialists to delight your customers. ]
2. Fix weak self-signed certs in mail, FTP & admin panels
Secure connections in SMTP, POP, IMAP, FTP and server administration panels (such as cPanel/WHM, Plesk, etc.) use self-signed certificates by default.
Unlike website certificates, these certificates do not show a prominent error in Mail or FTP clients, and could be ignored for a long time. Our tech support team found quite a few self-signed weak certs in self-managed VPS, dedicated and shared web hosting servers.
To prevent future occurrences of such SSL issues, we beefed up our 24/7 server monitoring with SSLLabs-SSLScan for in-depth scans.
3. Replace self-signed certs in server clusters
We provide tech support several VPS and Shared hosting providers. In many of these companies, accounts are provisioned from a central control server using SSL encrypted connection.
Since these are inter-server connections that’s isolated from end-customers, no SSL warnings would be seen even if the certificate expires. Our engineers found many such SHA1 enabled certificates in server clusters, which were replaced by SHA-256 enabled LetsEncrypt certs.
[ Don’t lose your sleep over server issues. Keep your customers happy with the best support specialists. ]
4. Generate only SHA-2 CSRs
Almost all Linux servers use OpenSSL to generate Certificate Signing Requests. The trouble with that is, OpenSSL by default uses SHA1 as the hashing function, and therefore the certificates generated from it will be SHA1 enabled.
Some of our customers that provided VPS and dedicated server hosting had customers that used old versions of control panels or outdated CSR generating scripts.
Our tech support engineers modified these CSR generation scripts, and included the option -sha256 to make sure all certs will be SHA-2 compliant. An example command is:
openssl req -new -sha256 -key domain.com.key
5. Disable SHA1 in software updates
All major server operating systems already use SHA-256 as the default method for verifying packages. So, in servers with the latest operating systems have updated safeguards to detect modified packages.
But, that was not the case with a few of our customer servers that used older OS versions to ensure compatibility to legacy software systems. These servers were updated using un-official software packages. The trouble with that is, many of these unofficial packages and update scripts rely on SHA1 signatures to verify authenticity.
To solve this, we re-configured the scripts to use only SHA-256 to verify packages. In cases where SHA-256 was not supported by package authors, scripts were updated to download package only from the original server (not a mirror) over https.
[ Focus on your core business without interruptions. Our tech support experts are here to manage your customers 24/7. ]
Lastly, SHA1 ciphers in Apache, Nginx, etc. are OK
A lot of our customers (web hosts) asked us whether the SHA1 deprecation should necessitate a revision of SSL ciphers in web servers such as Apache, Nginx, etc.
In short, No.
The way SHA1 is used in ciphers does not make the ciphers weak. In contrast SHA1 in certificates does pose a risk. So, while we recommend using only strong ciphers, if business requires use of intermediate risk ciphers, there’s no immediate danger in it.
Question, we use and do the following HMAC=SHA1? Is this a problem?
I have the following.
I also have OpenSSL and the following.
TLSv1
DES-CBC3-SHA Kx=RSA Au=RSA Enc=3DES-CBC(168) Mac=SHA1
Is the use of SHA1 for the MAC a problem or not?
I’m beginning to think not given the way MAC and HMAC works.