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.