Update: 15th March 2017:
The first practical attack against SHA-1 took place in February 2017 and is discussed in a more recent blog post.
Thank you.
=======================
Update: 25th June 2016:
Microsoft have updated their SHA-1 deprecation roadmap to state that from the 12th of July changes described in that psot will be seen for Microsoft Edge, Microsoft Internet and Windows 10 (with the Anniversary update) with regard to how they display the status of SHA-1 certificates. Further details are available within that post.
Thank you.
=======================
Update: 10th January 2016:
As mentioned in a recent blog post Mozilla have needed to re-enable SHA-1 certificates for “man-in-the-middle” (defined) devices due to issues being experienced by companies/organizations using such devices.
In addition, in mid-December Google announced their schedule for phasing out SHA-1. They too are considering moving the deadline forward to 1st July 2016 but have set a hard deadline of the 1st January 2017.
At the end of their blog post announcing this schedule they also provide advice on migrating from SHA-1. It is notable that within Step 2 of their plan they mention they took into account the issue Mozilla encountered (mentioned above; however, Google published that blog post before Mozilla Firefox users encountered that issue and worked around it in advance).
The migration from SHA-1 poses some very difficult issues for both users who cannot upgrade their web browsers before the imposed deadlines as well as corporate users who will be unable to make the transition in time (e.g. they are using custom applications that are critical to their business). These issues are discussed here with a possible work around being voted upon by the CA/Browser Forum discussed in a separate post.
Thank you.
=======================
Update: 24th November 2015:
Since publishing this blog post last month Mozilla and Microsoft are considering moving forward the deadline for phasing out SHA-1 to the 1st of July 2016. Their decisions have come in light of the recent disclosure of potential attacks on SHA-1 previously discussed within this blog post. The final deadline has not yet been decided but this should be yet another reason to begin planning to move your organization’s website away from using SHA-1.
Thank you.
=======================
Original Post:
=======================
Earlier this month a report was published by a team of researchers which shows that a potential attack on a SHA-1 hash (defined) could take as little as 3 months and cost in the region of USD $75k to $125k. The time and cost necessary are significantly less than the previous 2012 estimates of $700k necessary in 2015 and $173k by 2018.
Why Should This Potential Attack Be Considered Important?
In October 2012 possible attacks on SHA-1 were discussed and estimates provided on how time such attacks would take to carry out. Migration away from SHA-1 at the time was suggested. With the publication of the new research this month the need for migration has become more important.
An attack against the MD5 hash algorithm in 2012 was used by malware known as Flame to allow the installation of the malware onto PCs by making it “look like” genuine Windows Updates from Microsoft.
This was accomplished by the malware authors making improper use of Microsoft’s Terminal Services licensing certificate authority (CA)(defined). The certificate used to sign the updates was created using the MD5 algorithm (defined). A hash collision attack (defined) was used by the malware authors to make a different signing certificate produce the same hash as that of the genuine signing certificate. This seemingly “genuine” certificate was then used to sign their malware making it look like those malware files were Windows Updates.
While weaknesses in the MD5 algorithm were used to accomplish this, the same method of attack could potentially be used with SHA-1 to once again make malware look like legitimate/non-malicious files. When I say this, I don’t mean that an attack of this kind could again be carried out against Windows Update but I am referring to the use of SHA-1 in general. It’s not uncommon to see SHA-1 hashes provided when downloading new software or software updates from a software vendor’s website. If those files could be replaced with malware that has an identical hash to that of the legitimate file, the same type of attack could be carried out. You could download the file which would be malware but it would have the same SHA-1 hash as the genuine software.
SHA-1 is not only used for code-signing certificates but also with TLS (defined) secured websites. For example, if a website e.g. example.com has a legitimate certificate, that certificate could potentially be used by an attacker to provide more trust to a website of their choice using a collision attack on SHA-1. Thus when you visit the attackers website, malware.com it would appear to have a legitimate/trusted certificate. If this fake certificate were used in combination with another attack e.g. pharming (defined)(also discussed further in this post), there is the potential for you to visit example.com and actually be taken to the attacker’s website but example.com would appear in your web browsers address bar (while at the same time having a seemingly legitimate TLS certificate making the website appear even more trustworthy).
How Can I Protect Against The Known Weaknesses in SHA-1?
If you would like to check if your website uses a SHA-1 certificate you can visit this website. That site also provides advice on obtaining a newer SHA-2 certificate.
In addition this link provides advice on generating a new TLS SHA-2 certificate. Moreover a list of compatible web browsers, operating systems, web servers, databases, firewalls etc. is provided here. Finally the current planned roll-out phases of SHA-2 is provided here. Moreover you may find that this article provides useful background information and advice. For TLS certificates, the deadline for transition to SHA-2 is currently January 2017.
However a ballot with the CA/Browser Forum wishes to extend the issuing of SHA-1 certificates throughout 2016 giving large organizations with too many certificates to switch over during 2016 more time to do so. It appears from this post that this 1 year extension was granted (please see the update below for clarification on this).
Update: 4th January 2016:
I have been contacted in relation to the CA/Browser forum vote and have been informed that Symantec withdrew their ballot and the Baseline Requirements section on SHA-1 are unchanged. Many thanks to Mr. E. Mill for this information.
Update: 7th February 2016:
Qualys in September 2014 published a thorough blog post detailing how to migrate from SHA-1 including what to do should you need to support devices that cannot migrate from SHA-1.
I hope that the above information is useful to any organization or individual wishing to migrate their websites TLS certificate from SHA-1 to SHA-2.
Thank you.
securityinaction 