Chrome has certainly been one of the main contributors towards the recent push to HTTPS online and without their contribution, I do find myself wondering how much progress would have been made. The Chrome team have just announced two more big changes coming soon and they will help push the Web to be even more secure.
The adoption of HTTPS on the Web has seen huge increases recently and we can see evidence of that all around us. My own reports on the top 1 million site, most recently in September, show that and so do browser statistics from the like of Mozilla. Here is the % of pages loaded in Firefox that use HTTPS: https://letsencrypt.org/stats/#percent-pageloads
As the drive to HTTPS adoption for site operators continues, we also need to drive the use of modern TLS protocol versions, remove the use of legacy TLS protocol versions and take care of other issues like mixed content.
Legacy TLS versions
Whilst they may not seem legacy, TLSv1.0 was released in 1999 and TLSv1.1 was released in 2006, that's 20 years ago and 13 years ago respectively! A lot has changed in that time, we've made significant steps forward in both security and performance and we need to keep moving forwards with the times. This recent push from Chrome isn't the starting point though, this shift has already been underway for a long time. I've written about deprecating TLSv1.0 and TLSv1.1 on my own websites and how you can do that easily with Cloudflare Workers, the PCI announced way back in Jun 2017 that they were planning to deprecate TLSv1.0 and GitHub announced in Feb 2018 that they were also going to disable TLSv1.0 and TLSv1.1 too. This list is by no means exhaustive, I just wanted to demonstrate that this process has been ongoing for years and a significant number of larger organisations are already underway with their plans to deprecate these legacy TLS versions. What Chrome is now announcing is their plans to drop support for these legacy protocol versions starting off with warnings for sites using them.
In their post on the Google Security Blog, the plans have been outlined to start introducing the 'Not Secure' connection indicator shown above for sites using legacy TLS versions. This will begin on Jan 13 2020 in Chrome 79. Looking at my crawler data from the top 1 million sites on protocol versions, it seems that the impact will be minimal.
Protocols: TLSv1.2 310,762 TLSv1 2,980 TLSv1.1 51
I'm going to update my crawler to start looking for TLSv1.3 but that shouldn't really matter here anyway. The only problem is sites that can only do TLS1.0 or TLSv1.1 as their maximum protocol version. To be clear, at this point nothing will stop working and all you need to do to make sure that everything continues to work is add support for TLSv1.2 or higher. You do not need to remove support for TLSv1.0 and TLSv1.1 so if you have legacy client concerns, that's not a problem. That's also true once Chrome disables support.
In March 2020 Chrome will stop connecting to sites using legacy versions of TLS and you will see the error above. Again, to clarify, this does not mean you need to disable TLSv1.0 or TLSv1.1 on your site, it just means you also need to support TLSv1.2 or above. Don't get me wrong, you absolutely should disable these legacy versions anyway, but you don't need to because of this change. For more details on how to improve your TLS config, Chrome has an earlier blog post on improving your config that you should check out.
Once a site migrates to HTTPS, a common problem they can have is mixed content. Mixed content is where the page is loaded over HTTPS but something on the page, like an image/iframe/js/css, is loaded over HTTP. This breaks the security of the page and can be a difficult problem to solve, especially if you have a large site. I wrote about how to fix mixed content with CSP way back in Dec 2015(!) and that would be a great starting point if you have this issue, but Chrome is also doing things to help out. The second recent announcement from Chrome is how they're changing their handling of mixed content to gradually block everything that is mixed content. This is a pretty big change so it's being rolled out in a series of small steps starting as the end of this year in Chrome 79.
Chrome already blocks mixed script on secure pages because of the obvious danger it poses. You may have seen the small shield icon in the address bar when this happens which also allows you to enable the script if you'd like. In Chrome 79 the shield icon will be removed and replaced by a more general setting to allow mixed content on a specific site, shown in the image above. The next significant step comes in Chrome 80 when Chrome will start auto-upgrading certain types of content (audio and video) but start showing warning when mixed images are loaded. Passive content like images is less dangerous but still a problem and will attract a Not Secure connection warning.
The Chrome blog goes on to recommend CSP as one of the options to help site operators get ready for this change and regular readers will know how much of a CSP supporter I am! Over on Report URI not only do we support all types of CSP reporting, we have specific guidance on how to detect and locate all mixed content on your site. If you think you don't have any, great, but maybe still run the reporting for a few days and make absolutely sure?
This isn't the first push a browser vendor has made to help secure the web and it won't be the last. I've no doubt that over time other browser vendors will implement similar changes and overall we are seeing the whole industry taking these kinds of steps forward. Being secure online requires a little commitment and maintenance and these changes are just the latest efforts to clean up the web and keep everyone secure.