<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=352585001801011&amp;ev=PageView&amp;noscript=1">
Matt Kozloski

By: Matt Kozloski on January 6th, 2016

Print/Save as PDF

You Better SHA Up! - The Web's Transition to SHA-2 Certificates

Cybersecurity | Executive Consulting

shutterstock_213748822.jpgAll kidding aside, you may or may not be aware of a pending change in how secure sites (think SSL/TLS) are secured. This is the SHA-1 to SHA-2 transition. It’s actually been in the works for a while, and primarily involves upgrading the certificate(s) on your public-facing websites, with more secure certificates. So what is SHA-1 or SHA-2 and why do we need to change?

 

To understand this, we’ll do a quick crash course in cryptography. Cryptography, as we use it today, for secure communication is both simple and complex. The connection begins with two keys, a method called public key cryptography (asymmetric cryptography). This method uses two keys to encrypt and decrypt messages.

One of the keys is public (the one you get) and one is private (the one on the server). Because one of the keys is secret and secure, no one can intercept the messages. Your browser and the remote server use these keys to securely exchange a second, super-secret key (generated at random). This second super-secret key is used for the actual encryption of your connection (called symmetric cryptography). Why is there a second key, why not just use the first key-pair? Great question! Symmetric cryptography is much, much faster than asymmetric, which is why you get the second key to share.

Public key cryptography has the potential to be vulnerable to “man in the middle” attacks, where someone fakes the server end of the connection, essentially tricking you into thinking you are establishing a secure connection with the right person. The attack is that you’ve established a secure connection with a bad person. One way this is thwarted, is by certificate signing. You might have heard of Verisign or Thawte or other providers like GoDaddy. They are certificate authorities (CA’s) and issue and digitally sign public certificates. That way there is a trusted 3rd party to protect against “man in the middle” attacks. You usually notice a bad site, when your browser asks “this site’s certificate cannot be verified … do you want to continue?” (incidentally, don’t blindly say “yes” to those prompts).

This is where SHA comes in. SHA-1 is a hashing algorithm used by CA’s to sign a certificate. A hashing algorithm is a complicated mathematical formula, which returns a fixed-length value based on really large prime numbers. Without getting too deep, the reason we use prime numbers is because they are very difficult to factor. The important thing with SHA, is that the fixed-length value returned should ALWAYS be unique. That way you couldn’t “fake” a signature. This is called collision – when two different values generate the same hash.

Here’s the interesting thing – as computational power increases, so does the likelihood that a hacker can actually crunch enough numbers, in enough time, to do something bad. Something like generate a SHA-1 hash that matches a known-good certificate signature, but is used for a man in the middle attack. The current answer to the problem is SHA-2 (or SHA-256). SHA-2 results in at least twice as many output bits as SHA-1 (160 vs. 256 for SHA-1 vs SHA-256). Some analysts think SHA-1 collision attacks could be reality by the end of 2015.

The bottom line is that SHA-2 significantly increases the computation required to create a collision (or duplicate hash), making it more secure. It also probably means we’ll be talking about SHA-3 in a few years! If you really want to blow your mind, look into quantum cryptography and how quantum computers will forever change this landscape in the future.

Your call to action: Take an inventory of all your certificates and where they are used. Start upgrading your public certificates to SHA-2. Your certificate authority should offer this service for free (and have probably notified you already). You need to make sure your inventory is accurate, to avoid certificate revocation failures (when a registrar “expires” your old certificate and you are still using the old cert on a site). While you’re thinking about this, also consider what encryption ciphers you’re supporting and if you need them (such as the now weak and crackable RC4).

Also, don't hesitate to email our Security Experts here at Kelser. We're well versed in cyber security and would love to hear about your initiative.

webinar: finding cybersecurity gaps and vulnerabilites in your organization

 

About Matt Kozloski

Matt is an IT industry veteran and well-versed in professional services. He is the former leader of the CT VMUG. VCDX # 194, CISSP # 526947.