Sha 1 Certificates Error Are Your Certificates Future-proof? SHA-1 Sunset

I do not want to scare anyone but last week some important news broke out – Google security team managed to produce an SHA-1 collision in practice. Sooner or later you may expect to see problems with certificates.

https://shattered.io/

WOW! 

It is really important news for security vendors and all of us handling security in our organizations.

One may wonder:

• What is a real, practical implication for our organization right now?
• Do we need to take any action?
• Are we exposed to a threat that needs to be immediately addressed?

Let me help you answer these questions and highlight few points that may require actions.

SHA-1  – what’s the deal?

First of all – what’s the deal with SHA-1 and why you should bother?

SHA-1 is a cryptographic hash function. Simply speaking it is a function which takes input, for example, file, and through cryptographic calculations produces a hash. SHA-1 hash is 160-bit value known as a message digest.

The main property of a hash function is that same input will always generate same hash value. Output hash value will be different, even if you slightly change input.

Having this property is very useful. If we get a message, calculate its hash value and then send it to the other side over Internet, the receiver can calculate the hash value with the same algorithm and compare these values. If these are the same – file message was not altered in the transfer.

Simple and powerful!

You may ask yourself, this SHA-1 thing – is it used? Yes, it is everywhere!

Few examples:

• Signing digital certificates – when the certificate is being issued one of its properties is its signature which is done with a hash function. SHA-1 is pretty popular here however it is being phased out for some time now from public certificate authorities.
• Signing files – digital signature products can use SHA-1 and files delivered to you over the Internet may as well use SHA-1 to confirm its authenticity.
• Signing tokens in SSO protocols – SHA-1 is also used for signing tokens exchanged between parties in SSO protocols like SAML.

It is just a few examples where you find SHA-1 to create digital signatures to verify the authenticity of the files, documents, messages, and certificates.

So, where’s the problem? Google security team announcements show in practice what was predicted over a decade ago. You can produce two files with different contents, with the same hash value when calculated with SHA-1.

BOOM! That’s why we call it a collision.

Imagine that you have two different certificates, yet their signature calculated with SHA-1 hash is the same. Your browser will not be able to say which one is invalid – they look the same from a verification point of view.

Or digital signature on the document that you subscribe to lease a new apartment – you can sign the paper, but then it can be altered to change terms and conditions of the lease. If the hash value is the same, it will say – you’ve signed it. However, it is the same document.
I think the occurred problem is quite obvious.

What should I do now!?

Should you run and scream “OMG! There is an SHA-1 collision. Are we doomed!? – Nope! Scenarios like this will not happen overnight.

Google proved that it can be done but it takes time. Their technique is lowering this task complexity from a computation point of view however it is still very hard task to accomplish – to quote Google blog on the subject:

As you can see – it is not simple yet. However, it will get easier for two reasons:

• available compute power is growing
• once it is proven that it can be done, the bad guys will work to your disadvantage

What is an immediate impact for your users and organization?

Most likely the end users will be the first ones to notice the difference in their browsers.

Google Chrome already has some restrictions in place to block SHA-1 certificates – if you navigate to the site with SHA-1 SSL certificate that soon expires, you will get information that its security is broken.

Same happens with Firefox and Edge if you are running on Windows 10 anniversary update.

There is a plan for SHA-1 sunset enforcement in Windows OS – you can read about it on TechNet pages.

It is something that might affect your users but also your business.

You don’t want your customers visiting your website and seeing that it is not secure.

ACTION: Verify your public sites certificates. If it is issued with SHA-1  – replace it. 

Good news is that public CAs have been removing SHA-1 from use for a while. If you renewed or were issued certificate recently it should be signed with SHA-256.

https://shachecker.com is the website that can help you check your public certificate (also in services like Active Directory Federation Services used by your users)

HINT: SSL Labs from Qualys is a great tool to verify your certificates and SSL configuration in general. Check it out at https://www.ssllabs.com/ssltest/analyze.html.

What’s next with your PKI?

Now things get complicated. Your organization will have to move towards signatures with SHA-2 family gradually. It is however not guaranteed for your applications.

ACTION: If you have any applications that rely on certificates, you should start planning tests for those apps whether they support SHA-2 signed certificates.

If not – get in touch with vendor, development team or Predica team to get an update as it will start causing problems sooner or later.

The first step in this process is to check your PKI infrastructure. Many organizations have deployed PKI based on Microsoft CA or other CA products. Internal CAs are used mostly to support client login with certificates or to issue certificates for services and applications internally.

And there is PKI infrastructure itself. You can upgrade your current one to support the only SHA-2 family, however, not all applications (using certificates issued by this CA) may support it.

Your choice is between changing current CA or setting up new CA infrastructure and phase out SHA-1 certificates.

It is not a new issue, it was already covered by Microsoft in the past and our experience shows that even if it is known for a long time, most of the customers still have not taken any action. 

Now when SHA-1 collisions are proven it might be a good time to start to plan execution on it as software vendors will accelerate the move towards SHA-2 family and you don’t want to be left out in the dark.

Be warned – SaaS apps access may break!

SaaS applications area with SSO enabled is another area where you need to do review and planning.

In this case, it is based on one of authentication and federation protocols (SAML, OpenID Connect), where access relies on token issuance and exchange.

The token is issued by the identity provider and then verified at SaaS application. And guess what – this verification is based on a digital signature verification mostly using SHA-1 as a method to verify the signature of token delivered.

It is not only a case with SaaS applications but also with on-premises applications that are using federated solutions like AD FS, Ping, Shibboleth or other solution to provide SSO for applications.

ACTION: Plan review of all your relations with relying parties between your federation infrastructure and applications. If SHA-1 is in use as a method of verification, ASK your application provider if they support and if they can implement SHA-256. 

If not already – ASK THEM WHEN THEY PLAN TO SUPPORT IT.
It is in your best interest that your application vendor does this sooner than later.

It has a very practical problem. Previous week one of our Azure Active Directory integrated SaaS application used by our help desk suddenly failed to log in our users. A quick investigation showed that Azure AD started to sign application token with SHA-256 while SaaS application accepted the only SHA-1 signature. We had to revert it back to SHA-1 to make it work.

HINT: If you are experiencing SaaS application access problem insist on getting logs from an application perspective. It is probably the fastest way to solve it, however, have in mind that getting these logs through help desk is not always an easy task.

And with service itself – your SSO infrastructure based on federation is based on the certificates (communication, signature and encryption certificates). These certificates need to be checked and if needed rolled over to SHA-2.

Azure AD is doing certificate roll-over on its own – it phases out SHA-1 certificates already, but your AD FS infrastructure might still use it.

Worst case scenario

What is the worst-case scenario? Other than someone using this collision in practical security related attack to spoof some document or certificate?

In my opinion, worst outcome will be that as IT industry, we will have another IE6 moment. IE6 is not secure and we are aware of that. The main problem was that IE6 was required and many organizations had to live with it for a long time (probably still are) because applications were written in this way.

With SHA-1 we may face the same problem. It is not an immediate threat so many organization might not act on it yet. Sometime in the future, someone will refine this attack or approach to make it more practical – execute easier with less computation power required.

Then it will become practical.

It is not a full list of actions, but I tried to raise the issue to prevent Your loss.

Time to act right now on your SHA-1 certificates

As you can see SHA-1 collision is not something that will affect your security immediately, but there are lots of moving parts where validation based on SHA-1 is being used. You need to start to plan review of those and take actions to ensure that your applications and infrastructure will work as expected.

A quick summarize of this article: 

• Review your public facing sites and verify used SSL certificates. If it is using SHA-1 – replace it. You don’t want to lose customers because of your website marked as not secure.
• Update your helpdesk service desk on possible issues with modern browsers and sites which might be marked as not secured. Make sure that they have tools and procedures to solve it.
• Review your PKI depended applications– verify their support of SHA-2 and if You can rid of SHA-1 dependency. It might be a big task on its own, especially when you have many applications without clear dependency on certificates. Expect something to fail and have right procedures and tools to verify and troubleshoot.
• Check your PKI infrastructure and if needed plan deployment for CA with SHA-2 family certificates. It may take time and a lot of planning so the sooner you start the earlier you will be able to phase out old certificates. Remember – it will take the time to re-issue new certificates.
• Verify your setup for federation infrastructure for AD FS, Ping and another kind of products. They do use certificates, and you might need to roll-over those to remove the SHA-1 dependency.
• Verify your federation application setup, especially for SaaS applications – they depend on digital signatures. SSO based on federation approach depends on the validation of tokens. They are verified with digital signatures which might be using SHA-1. You need to work with your application vendor to change it.

Just to remind You – digital signatures, document signing solutions, e-mail encryption and signatures are just some of many more points that may be affected by this change.

I’ve just touched few issues in this post and eventually we will have to fix all of them. It is another challenge for IT industry.

Let Predica team help you become future-proof!