We do not want to scare anyone but 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.
WOW! It is really important news for security vendors and all of us handling security in our organisations.One may wonder:
- What is the real, practical implication for our organisation right now?
- Do we need to take any action?
- Are we exposed to a threat that needs to be immediately addressed?
Let us help you answer these questions and highlight few points that may require action.
SHA-1 - what's the deal?
First of all - what's the deal with SHA-1 and why should you 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 the same input will always generate the same hash value. Output hash value will be different, even if you slightly change the 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 the 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 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 a 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 has been 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 their authenticity.
- Signing tokens in SSO protocols - SHA-1 is also used for signing tokens exchanged between parties in SSO protocols like SAML.
These are 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 the verification point of view. Or a 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.The problem now 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: "This attack required over 9,223,372,036,854,775,808 SHA-1 computations. It took the equivalent processing power of 6,500 years of single-CPU computations and 110 years of single-GPU computations." 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 the immediate impact on your users and organisation?
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 a site with SHA-1 SSL certificate that soon expires, you will get information that its security is broken.The 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 they are issued with SHA-1 - replace them.
The 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.SHA Checker is a 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 here.
What's next for your PKI?
Now things get complicated. Your organisation will have to move towards signatures from the 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 SoftwareOne 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 organisations 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 phasing 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 another 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 implication. Recently, one of our Azure Active Directory-integrated SaaS applications used by our helpdesk 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 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, keep in mind that getting these logs through helpdesk is not always an easy task.And with the 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? The 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 organisations 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 organisations 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 we tried to raise the issue to prevent your loss.
Time to act right now on your SHA-1 certificates
As you can see, the 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 summary of action points:
- Review your public facing sites and verify used SSL certificates. If they are 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-dependent applications- verify their support of SHA-2 and if you can rid them 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 other kinds 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.
Author
