Chrome compounds a decades-old mistake

Henry Harrison

Nearly twenty-five years ago, Netscape introduced SSL. The https protocol was born, together with the now-venerable “padlock” icon that is used to signal encrypted sites.

That padlock was the beginning of a mistake that’s now got out of hand.

Ten years ago, Extended Validation Certificates were introduced – allowing a website to provide some level of evidence about the identity of the organisation behind the website. Browsers started to differentiate between standard certificates (just the padlock) and EV certificates (the “green bar”). More recently, some browsers show that sites with EV certificates are “secure”.

Today, Chrome marks unencrypted websites as “not secure”.

This has all gone too far.

The world has moved on a long way in the past twenty five years. Yes, HTTPS protects against the risks of interception and man-in-the-middle. But in most cases there are much bigger risks to worry about, where HTTPS provides quite limited protection. By marking websites as “secure” or “not secure” based purely on whether they use HTTPS, browser companies are quite seriously misleading their users.

In today’s Internet, the biggest risk associated with web browsing is that the website you browse to tries to deliver malware to your endpoint. A successful attack can of course result in ransomware, data theft, financial theft or even disruption of critical infrastructure.

In some circumstances, HTTPS does provide some protection, at least if the website has an EV certificate, in that you can know who it is that’s running the website. But EV doesn’t guarantee that the website owner isn’t criminal or malicious. And it certainly doesn’t guarantee that the site is well protected against hackers who might compromise it and put malware on it.

In other circumstances, HTTPS can even be negative. Businesses usually invest in proxy and firewall technology to scan web traffic in order to detect and block malicious payloads. In many cases, the business can’t scan HTTPS traffic (particularly if certificate pinning means that they can’t MITM their own traffic) and you could argue that in these cases HTTPS even makes security worse.

We need to get away from this obsession with HTTPS. The risk associated with visiting a website depends on many factors, of which encryption is just one. Much more important are factors like: how well-established is the website? Has the domain been registered through a reputable registrar? Is the site serving up pages that show evidence of out-of-date (unpatched) templates? Is there a history of this site (or other associated sites) serving up malware?

Using that sort of information, we could really give users a good idea of whether it’s safe to visit a site or not.