There has been a long standing issue between Google / Chrome (and now also Mozilla / Firefox) and Symantec regarding the SSL certificates that Symantec have issued in the past via their various subsidiaries (eg. Thawte, RapidSSL). In a nutshell, as of v66 of Chrome, certain SSL certificates will become distrusted (those issued prior to June 2016), and the browser will tell you accordingly. Similar will occur with Firefox v60 (or so I believe). Other certificates will get similar treatment later in 2018.
There are several free online SSL checkers out there such as SSL Labs, and as part of my role I have been looking at testing the certificate on a couple of sites to check their status. As D-Day has been approaching, I have seen the status of some SSL certificates becoming more urgent, and bumping up from “becoming distrusted in March 2018” to currently showing, now we’re in March 2018, “distrusted by Google and Mozilla”.
This should have become evident in the Developer Console as of Chrome v65, but I was finding that it wasn’t showing me any warning at all.
Switching to Chrome “Canary” (bleeding edge version of Chrome) I should have seen the warning in browser, as Canary is already on v67, but again, I wasn’t and I could simply view the sites as per normal.
Any distrusted SSL certificates were not reflected in the Chrome browser, nor the Developer Console. What was going on?
What I expected to see
Using Chrome v65 (current production build, as well as Beta build at time of writing) I should have seen some sort of warning as seen below:
Yet nothing of that sort was showing up.
Similarly, using Chrome Canary (v67) I should have seen the full effect of the now distrusted SSL, and seen the alarming message in browser below. Enough to scare most people away from the site, especially if an eCommerce site, possibly never to return.
But again, I was simply seeing the normal page, as though nothing at all was wrong.
Once I started exploring other options within the Developer Tools of Chrome, specifically the Security tab, I found that the certificate was appearing as though it was being served by the anti-virus package installed locally
Check the Security tab within the Developer Tools
Once I started exploring other options within the Developer Tools of Chrome, specifically the Security tab, I found that the certificate was appearing as though it was being served by AVG Technologies, which happens to be the anti-virus / firewall product in use within the office I most often work in.
Checking on my PC at home, where Kaspersky Total Security is installed, I found a similar situation where the certificate was appearing to be served by Kaspersky and not Thawte (or RapidSSL, or whatever).
It dawned on me that I needed to disable “something” in these anti-virus suites, to see the actual blocking effect imposed by Chrome that should have been occurring.
Disable scanning of encrypted (SSL and TLS) traffic in AVG Business
By default the option to scan encrypted (SSL and TLS) traffic is switched on, or at least it is in our environment in the office.
You can switch this off by going into the settings for Web Protection > expand Online Shield > select Expert Settings and un-check the box for “Scan Encrypted (SSL and TLS) network traffic”.
Disable scanning of encrypted (SSL and TLS) traffic in Kaspersky Total Security
You can do a similar thing in Kaspersky Total Security by opening the application, clicking the cogs icon (bottom left) > select Additional from the left hand menu > select Network > then in the Encrypted connections scanning section select the option “Do not scan encrypted connections”. You’ll need to confirm the selection. This will turn off certain in-built protection settings so it is recommended to turn this back on once the site has been tested (same goes for AVG).
Note: simply pausing Kaspersky protection doesn’t do the job.
You may need to restart your browser after making this change, though for me I simply needed to reload the page only.
In Chrome v65 I was now getting the warning in the Developer Console, and in Chrome Canary the page wouldn’t load and instead of was getting the alarming message, with the option to continue through “unsafely” if I wanted to take that risk.
Conclusion
This functionality for scanning encrypted connections, and ultimately providing self signed certificates from the anti-virus suites, may give you a false impression that a website with a distrusted SSL certificate is OK. Or you could look at it that this gives website admins a little more leeway when it comes to getting these certificates re-issued (though this relies on the assumption that most people are running anti-virus suites with inbuilt web protection functionality).
From a testing perspective it’s important to realise that this sort of functionality (of scanning encrypted connections) exists and that there should be an option within your own AV suite to do something about it, to see the full effect of a distrusted SSL certificate.
Of course, the best thing to do is to make sure any distrusted certificates get re-issued as a matter of some urgency, with the production release of Chrome v66 (and other browsers will follow) only about a month away.
