Chrome Debuts “Not Secure” Warnings; SHA-1 Certificates Untrusted
Last week Google Chrome 56 hit the stable channel, which means your users’ browsers are being upgraded now. We have run down the changes in Chrome 56 as related to SSL, as well as just general cyber security, to make it easy to keep up with all the new behaviors:
Not Secure Warning for Passwords/Credit Cards Over HTTP: Chrome has started seriously tightening the screws on HTTP. With the release of Chrome 56, a nasty warning will accompany any page that contains a password field or credit card form and loads over HTTP.
On these pages, a prominent “Not Secure” warning will appear in the address bar. This is a serious notice to users that their information will not be secure if they enter it on these pages.
This is one of the biggest motivators pushing websites to adopt HTTPS. It does not stop here – Chrome will continue to make warnings about HTTP more severe. In an upcoming version of Chrome this “Not Secure” warning will spread and appear within the forms themselves, not just in the address bar. The new release of Firefox also warns users when it encounters a password field on HTTP, and Mozilla is working towards a similar goal to make HTTP a thing of the past.
Chrome has added a new message in the Security panel in Developer Tools to help you diagnose this problem.
Certificate Details No Longer Available Through the Padlock: If you wanted to check a website’s SSL certificate or HTTPS connection, you used to start by clicking the padlock icon in the address bar. But in Chrome 56 the path to certificate details has been moved out of that menu.
Now you will need to go directly to Developer Tools, accessible through the Chrome Menu (⋮) or by keyboard shortcut (Ctrl + Shift + i / ⌘ + Option + i ). We have a dedicated post about this for anyone looking to know more and get more complete instructions.
Distrust all SHA-1 Certificates: Chrome will no longer accept any publicly-trusted SSL certificates signed with SHA-1. This means even other-wise valid certificates will be rejected by Chrome if they have a SHA-1 certificate. This is it – the official death of SHA-1 in Chrome.
If you are still using a SHA-1 certificate on your site, you need to upgrade now to allow continued access to your site, even if your certificate has not expired yet.
Blocking SHA-1 certificates at the browser level provides more protection than solely relying on Certificate Authorities not to issue them. Because the industry has been moving away from SHA-1 for quite some time, this should only affect a handful of sites.
Manually-trusted roots, like those used for enterprise PKI, will not be affected until v57. At that point, you will need to turn on the EnableSha1ForLocalAnchors policy to continue using SHA-1 signed certificates.
Distrusting WoSign/StartCom Certificates: Late last year a huge scandal involving the Chinese CA WoSign was discovered. The CA had mis-issued certificates and was found to have been grossly negligent in its duties. It was also found that WoSign had acquired the Israeli CA StartCom, which subsequently mis-issued certificates under WoSign’s management. As a result, Chrome decided to slowly eliminate both as a trusted CA in Chrome.
In Chrome 56, WoSign/StartCom certificates issued after October 21st, 2016 will no longer be trusted. Some certificates issued before that date may continue to be trusted if they are compliant with Certificate Transparency. However Chrome plans to eventually dis-trust all certificates issued by these CAs, so it is only a matter of time until they are completely removed. If you used either of these CAs, you should switch to a new provider.
Remove the Certificate Transparency “Timebomb”: Chrome had implemented a mechanism to protect browsers from getting stale Certificate Transparency data. This mechanism made the browser stop trusting CT data 10 weeks after its build date. However there was an unintended side-effect: if a certificate HAD to be CT compliant to be trusted by Chrome then this “timebomb” made it impossible for those certificates to be trusted.
This affected Symantec certificates. After it was discovered that Symantec had improperly issued certificates they were using for testing, Google required them to be CT compliant in order to prevent this from reoccurring. As a result of the Chrome bug, compliant Symantec certificates became untrusted after the 10 week threshold was hit.
Chrome will now skip this check to eliminate the bug. This will not help users using Chrome versions earlier than v56.
Testing TLS 1.3: Chrome 56 adds support for draft-18 of TLS 1.3 and turns it on by default for a small number of users. This is in order to test TLS 1.3 in the wild as the protocol will soon be finalized and adopted.
Anyone who wants to start using TLS 1.3 now can turn it on in chrome://flags/ by changing “Maximum TLS version enabled” from “Default” to “TLS 1.3.” Cloudflare is among a small numbers of sites that have already adopted the new protocol.
HTML5 By Default (bye bye Flash!): Chrome 56 will be “HTML5 Be Default,” meaning that the browser will automatically prefer HTML5 over Adobe Flash when applicable. For sites that only support Flash, users will be prompted and have to explicitly allow Flash to run. For more information on the removal of Flash from Chrome, see Google’s documentation.
Gmail Will Block .JS File Attachments: Finally, we want to note that Gmail will soon block .js file attachments. This is not related to Chrome 56’s release, but we are including this as it impacts user security and is happening around the same timeframe.
On February 13th, Gmail will start blocking .js file attachments and return an error noting that the file type is no longer allowed. If you want to send a .js file, you will need to upload it to Google Drive or similar service.
More Changes in Chrome 56
Every update of Chrome involves hundreds of changes and only a tiny number of them get any sort of coverage or notice. The majority involve persistent tweaks and improvements in behind-the-scenes behavior.
We wanted to take a minute to highlight some of these tiny, often ignored (and possibly imperceptible) changes.
Measuring Effect of the “Not Secure” Warning: Chrome’s security team has been spending on a lot of time on SSL lately. One of the most notable changes is the new “Not Secure” warning that is debuting in V56. To help measure the effect of this warning, Google has added a new metric that will track how much time elapses between the “Not Secure” warning displaying on an HTTP page with password/credit card fields and the user closing/leaving that page. This will help the Chrome team know if the warning is causing users to leave the unsecured page.
Prefer SHA-2 chains on Win 8+: Path building is one of the most complicated parts of certificate validation. Due to cross-signing, and all the software that has its hands in this process, path-building can vary from computer to computer and is often the causes of mysterious bugs.
Thanks to new functionality first exposed in Windows 8, Chrome now has a way to nudge Windows to build a path with newer, stronger signatures when multiple paths are available. This will help ensure Chrome builds a path through SHA-2 intermediates when there is a cross-sign that also has a SHA-1 path.
Chrome is also adding a new check to see if a root certificate is included on the user’s Windows OS. Previously Chrome used a static list, but again, thanks to new Windows functionality there is a way to do this via API. This will provide better detection of root certificates on Windows 10 devices.
Remove CBC-mode ECDSA ciphers in TLS: CBC is an encryption method in TLS that is regarded to be “fragile” – meaning that it is hard to implement properly and easy to break. Use of CBC ciphers with RSA is still moderately popular, but CBC is almost never used in combination with ECDSA. It is so uncommon that Chrome’s user metrics round-down and record it as 0.00%.
Because CBC-mode is inherently flawed, and these two ciphers are rarely used, Chrome’s team has decided to just remove them entirely. The affected ciphers are: ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS.