See how your site could get more than just a warning, and actually get elements blocked from view, if your HTTPS is not set up properly.
Why is Google Doing This?
Google is part of a large cyber security consortium that wants to make the web safer to navigate.
Google is considered the strong-arm muscle to encourage more site owners to get serious about their site’s security, including HTTPS.
Google does this via SEO ranking/penalties on their search engine.
But it also does it through settings in the Chrome browser.
And that’s the tool they are using in this latest uptick of cyber security.
Google’s Mixed Content Announcement
On Oct 3, 2019, Google published a post on the Chromium Blog that they were taking stronger measures beyond warnings when sites delivered a mix of HTTPS and HTTP links.
In 2018 Google began showing warnings and yellow and red padlocks in the URL bar of any site that was not being delivered as HTTPS or if it had mixed links on the page.
Those padlocks are also accompanied by a shield icon to indicate whether the site is fully encrypted and safe or not.
A fully secured site’s URL looks like this in FireFox:
And it looks like this currently in Chrome:
(Note Chrome doesn’t even show the https or http anymore, nor does it show a shield.)
Now Chrome will completely block delivery of an inbound HTTP link element and instead display a warning that the site is not safe.
Rolling Out Blocked Content in Steps
With the release of Chrome 79 in December 2019, a new setting will be introduced so that site visitors can choose to unblock mixed content on the pages they are viewing.
Currently those elements are simply blocked and not shown, but the rest of the page is shown.
In Chrome 80, due out in January 2020, the following measures will be taken:
- Audio and video content with HTTP links will be auto-upgraded to HTTPS.
- External images loaded with HTTP will be allowed to load, but will show a “Not Secure” warning in the URL bar.
That warning in the URL bar will look like this:
In Chrome 81, due out in February 2020, external images loaded with HTTP will be auto-updated to HTTPS. If they fail to respond, meaning no HTTPS delivery is possible, then they will be blocked from view.
How to Ensure Your Site is Ready
If you cheated on how you did your HTTPS, meaning you used some plugin, or had your host do it, then you’re missing a lot.
That includes all of your security headers, like a CSP, which is a Content Security Policy directive in your .htaccess file.
You are also missing the HSTS directive, which is HTTPS Strict Transport Security and is the one that Chrome requires for you to get on their preload safe site list.
Check your security headers at SecurityHeader.com
If you are getting anything less than an A score, you’re missing critical HTTPS related headers.
If You Run Ads
ALL ad agencies randomly deliver ad links that are HTTP.
To keep your site from getting these mixed media warnings, some of the good ad agencies give you a way to easily add the CSP directive.
Mediavine has a setting to Block Insecure Assets in their plugin.
But, if you are using the WP Fastest Cache plugin, it won’t work properly.
The directive needs to be coded a different way.
I have shown their developer this and why they don’t change the way they code their directive to work with all caching plugins is beyond me. Instead, they continue to recommend crappy caching plugins like WP Super Cache that don’t even begin to work.
They also recommend WP Rocket, which does work if configured properly.
But, the premium version of WP Fastest Cache works even better and it’s way cheaper as you only have a one-time fee, not an annual subscription.
And the free version of WP Fastest Cache beats the pants off any other free version of caching plugin.
Get a Real and Full HTTPS Conversion
Besides the missing headers, if you cheated, all of your links are simply being redirected from HTTP to HTTPS.
That’s not just your permalinks. It’s every image and every other internal link within your posts too.
In other words, your site has not been converted to HTTPS. It has simply been redirected.
And that’s going to bite you in the butt down the road.
If you’re using Cloudflare as a way to get your HTTPS delivery to the visitor’s browser, without having converted your site to HTTPS, that’s even worse. You don’t have end-to-end encryption and you’re leaving yourself open to a man-in-the-middle attack.
READ: Top 10 Reasons Not to Use Free HTTPS
And then go fill out the request form to get your site converted for real and all of the associated stuff that was not done for you taken care of.
That way you’ll never have to worry about Google’s future changes with regard to HTTPS. And there will be more of them!
My clients are peacefully going about their daily lives instead of fretting over this new Google announcement. Their sites have already been future-proofed and they don’t need to do a thing to be in compliance with this latest development.
They are already years ahead of the penalties that are coming.
I am so glad that you sorted out my https, MaAnna.
Paying for your professional service has paid dividends in peace of mind. Thank you.
Thanks, too, for all the news and info you pass on to us. You are much appreciated.
We like being way ahead of the curve on this stuff, don’t we? Calm is good.
Been saying this for awhile that it was coming. Use this to sort out all NOT SECURE site content on WordPress sites.
https://wpfixit.com/product/wordpress-ssl-https-setup-service/
I’ve been preaching like a lone voice in the wilderness that cheating around ways to do HTTPS would bite folks in the butt later. And here we are.
Most folks just don’t move unless they are in pain. And they are about to feel it again.
Yup. Remember when last year it was the NON SECURE display and nobody listened then.
Besides that, the SEO benefits and with HTTPS you get to use HTTP2 browser technology making the site faster. That should be an even better reason to run in HTTPS mode.
Hi MaAnna, I have a doubt about the CSP. How do you implement it in a WordPress like scenario where there are many scripts and styles files of plugins? You can’t individually add everything in “script-src” and “style-src” directives. Plus there are pages where you need the use of “unsafe-inline” and “unsafe-eval”.
Do you suggest a more relaxed content security policy like this “default-src ‘self’; script-src * ‘unsafe-inline’ ‘unsafe-eval’; style-src * ‘unsafe-inline’;”?
While you can get pretty fancy with that security header, I find a simple approach works just fine for me and my clients, especially those who are on ad agencies that send in all manner of things.
If an inbound link displays something from an outside source that is not https – block it.
And they way I read it, that’s basically what Chrome will be doing too if there is not an https source available.
I tried that type of “nudge” CSP, but not all browsers support it. So, going with the block.