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.
It is really important news for security vendors and all of us handling security in our organizations.
One may wonder:
Let me help you answer these questions and highlight few points that may require actions.
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!
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
Your ticket time resolution is taking too long, new issues are coming, but you are tied by a pile of incidents that are ...
I covered security in GitHub last time. But some of you likely use Azure DevOps for building your products, so let’s t...