SHA1 Deprecation Policy
Today Microsoft has announced a new policy for Certificate Authorities (CAs) that deprecates the use of the SHA1 algorithm in SSL and code signing certificates, in favor of SHA2. The policy affects CAs who are members of the Windows Root Certificate Program who issue publicly trusted certificates. It will allow CAs to continue to issue SSL and code signing certificates until January 1 2016, and thereafter issue SHA2 certificates only.
SHA1 has been in use among CAs since the late 1990s, and today accounts for the overwhelming majority of SSL and code signing certificates in use today. US NIST Guidance has counseled that SHA1 should not be trusted past January 2014 for the higher level of assurance communications over the US Federal Bridge PKI. Common practice however has been to continue to issue SHA1-based certificates, and today SHA1 certificates account for over 98% of certificates issued worldwide. Recent advances in cryptographic attacks upon SHA1 lead us to the observation that industry cannot abide continued issuance of SHA1, but must instead transition to SHA2 certificates.
The deadlines in this SHA1 deprecation policy reflect Microsoft’s estimation of the seriousness of the threat from SHA1 attacks. Our primary goal is to protect the integrity of the Windows platform and Windows customers. We want to avoid a situation where customers are caught unprepared because of a sudden advance in hash collision attacks. Without any other motivator for CAs to transition their customers to SHA2, when SHA1 becomes exploitable a sizable number of customers may be dependent on an insecure hash algorithm.
SHA1 Deprecation Policy
The policy applies to Windows Vista and later, and Windows Server 2008 and later.
There will be separate timelines for discontinuing SHA1-based SSL and code signing end-entity certificates.
CAs must stop issuing new SHA1 SSL and Code Signing end-entity certificates by 1 January 2016.
For SSL certificates, Windows will stop accepting SHA1 end-entity certificates by 1 January 2017. This means any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017.
Code Signing Certificates
For code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps after 1 January 2016. SHA1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.
[We will Re-examine the impact of this Policy at mid-term]
With every algorithm or key length transition there have been unforeseen impacts on legacy systems. Windows users will not be affected by the transition to SHA2, however Microsoft, CAs and their affected customers must assess the impact on legacy systems and devices now and not later on the timeline. Microsoft will give new consideration to the SHA deprecation deadlines in July 2015. We will consider these among other conditions that may be prevalent at the time:
- whether SHA1 is still considered resistant to pre-image attacks by the security community, and
- whether a significant portion of the ecosystem is not capable of switching to SHA2. Third party legacy systems and embedded devices that cannot be upgraded to SHA2 may be particularly susceptible. We will continue to gather data on this portion of the ecosystem.
What this Policy Means for Windows Users
Windows users do not need to do anything in response to this new technical requirement – Windows XP Service Pack 3 supports SHA2 SSL certificates, and Windows Server 2003 Service Pack 2 or later add SHA2 functionality to SSL certificate by application of hotfixes (KB968730 and KB938397).
Website operators must request new certificates to replace SHA1 SSL and code signing certificates that expire after 1 January 2017. CAs will be integral to this transition as they begin to promote SHA2 certificates as replacements. CAs must also work with web site operators to replace already issued SHA1 code signing certificates before 1 January 2016. This deadline applies to code signing certificates intended for use on Windows only. CAs may continue to issue SHA1 certificates for non-Windows platforms.
Microsoft has examined the SHA1 issue, and consulted with affected CAs. We are committed to this SHA1 deprecation policy and its timeline. We believe that this provides the best assurance of security for Windows customers and the broader PKI-based ecosystem of users. The quicker we can make such a transition, the fewer SHA1 certificates there will be when collisions attacks occur and the sooner we can disable SHA1 certificates.
Note: Windows has not set any dates for blocking other types of certificates (e.g., S/MIME) but SSL and code signing; CAs, however, should expect SHA1 certificates issued after 1/1/2017 may stop working at any time.
Friday, September 05, 2014
The SHA-1 cryptographic hash algorithm has been known to be considerably weaker than it was designed to be since at least 2005 — 9 years ago. Collision attacks against SHA-1 are too affordable for us to consider it safe for the public web PKI. We can only expect that attacks will get cheaper.
That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.
SHA-1’s use on the Internet has been deprecated since 2011, when the CA/Browser Forum, an industry group of leading web browsers and certificate authorities (CAs) working together to establish basic security requirements for SSL certificates, published their Baseline Requirements for SSL. These Requirements recommended that all CAs transition away from SHA-1 as soon as possible, and followed similar events in other industries and sectors, such as NIST deprecating SHA-1 for government use in 2010.
We have seen this type of weakness turn into a practical attack before, with the MD5 hash algorithm. We need to ensure that by the time an attack against SHA-1 is demonstrated publicly, the web has already moved away from it. Unfortunately, this can be quite challenging. For example, when Chrome disabled MD5, a number of enterprises, schools, and small businesses were affected when their proxy software — from leading vendors — continued to use the insecure algorithms, and were left scrambling for updates. Users who used personal firewall software were also affected.
We plan to surface, in the HTTPS security indicator in Chrome, the fact that SHA-1 does not meet its design guarantee. We are taking a measured approach, gradually ratcheting down the security indicator and gradually moving the timetable up (keep in mind that we release stable versions of Chrome about 6 – 8 weeks after their branch point):
Chrome 39 (Branch point 26 September 2014)
Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is used to highlight other deprecated and insecure practices, such as passive mixed content.
Chrome 40 (Branch point 7 November 2014; Stable after holiday season)
Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.
The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.
Chrome 41 (Branch point in Q1 2015)
Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.
The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.
Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.