Unlike Mozilla, Google anticipated SHA-1 errors caused by HTTPS traffic inspection systems
Instead of banning all digital certificates signed with SHA-1 and issued after Jan. 1, Google plans to only "untrust" those that originate from public certificate authorities.
This decision takes into account that some companies might still use self-generated SHA-1 certificates internally on their networks, or that some antivirus programs and security devices will continue to generate such certificates when inspecting HTTPS traffic.
Man-in-the-middle HTTPS traffic interception is generally frowned upon by privacy advocates because it breaks the trust between users and servers and because, if done incorrectly, can expose users to serious attacks. However, it has some acceptable uses.
For example, some companies might install HTTPS traffic inspection devices at the network perimeter to ensure that sensitive corporate data is not leaked over encrypted traffic. Many antivirus programs also inspect HTTPS traffic locally on computers using man-in-the-middle techniques in order to detect whether malware is being served through such connections.
Such applications and systems re-encrypt the traffic between users and websites by creating new certificates for those connections using self-generated CAs (certificate authorities). The root certificates of those CAs are not trusted by default, so they need to be manually deployed on the computers and devices whose traffic is to be intercepted, so that users' browsers will trust the mock website certificates signed with them.
SHA-1, an aging hashing algorithm, is in the process of being phased out because it is theoretically vulnerable to attacks that could result in forged digital certificates and it's only a matter of time before someone gains the capability to do so.
As a result, the CA/Browser Forum, a group of certificate authorities and browser makers that sets guidelines for the issuance and use of digital certificates, decided that new SHA-1-signed certificates should not be issued after Jan. 1, 2016.
SHA-1 certificates issued before this date will continue to be trusted until at least July 1, 2016, depending on the browser, but no later than Jan. 1, 2017.
Mozilla decided to stop trusting SHA-1 certificates in Firefox that were issued after Jan. 1. At first glance this shouldn't have had much impact, because trusted public CAs are not supposed to issue new such certificates after that date.
However, the browser maker did not consider the fact that some HTTPS inspection systems and applications might continue to generate SHA-1 certificates as replacements for the real ones served by websites. Because of this it started receiving reports from users of such systems who could no longer access any HTTPS websites, even if their real certificates were signed with the more secure SHA-2 function.
Mozilla decided to lift the SHA-1 ban, at least temporarily, in Firefox 43.0.4, released Wednesday.
"The latest version of Firefox re-enables support for SHA-1 certificates to ensure that we can get updates to users behind man-in-the-middle devices, and enable us to better evaluate how many users might be affected," the company said in a blog post. "Vendors of TLS man-in-the-middle systems should be working to update their products to use newer digest algorithms."
Google also plans to ban SHA-1 certificates issued after Jan. 1, starting with the next stable version of Google Chrome -- version 48. However, the company said in blog post in December that it will only ban certificates that meet three criteria: are signed with SHA-1, are issued on or after Jan. 1 and chain back to a public CA.
"Note that sites using new SHA-1 certificates that chain to local trust anchors (rather than public CAs) will continue to work without a certificate error," the company said.
Since self-generated root CA certificates like those used by man-in-the-middle HTTPS inspection systems are not "public" CAs, their users should not be affected. This might be a solution for Mozilla too when it decide to reinstate the ban.