Chrome casts away the padlock—is it good riddance or farewell?

It’s been an interesting journey for security messaging where browsers are concerned. Back in the day, many of the websites you’d visit on a daily basis weren’t secure. By secure, I mean that they didn’t use HTTPS. There was no padlock, which meant that the traffic between you and the website wasn’t encrypted, and so it was vulnerable to being snooped on or changed.

Sites you bought goods from tended to use HTTPS so your credit card number couldn’t be intercepted as it traversed the Internet. But random blogs? Forums? Information portals? Not so much. People would often say that it wasn’t really dangerous if blogs or information sites weren’t using HTTPS. No personal data was being sent or received, no purchases were being made. What’s the big deal?

And yes, that sort of makes sense up to a point. However, as the Mozilla blog highlights, anyone on the network can potentially read or modify a website’s data before it reaches you. This is a bad thing whether or not you’re shopping or simply looking at humorous memes. It means that bad actors can insert ads into the pages you see, add malware to your downloads or redirect you to fake versions of the sites you want to visit.

Why was it so difficult to make sites HTTPS?

Cost factored into this. HTTPS certificates and setup were pricey, many thought HTTPS impacted performance, and the benefits of using it were often unclear.

In theory it was possible to get yourself a free HTTPS service as far back as 8 to 10 years ago, but in practice it’d often only be free for a year or the service might not be very good. On top of this, HTTPS was a pain to set up and non-technical site owners stood little chance of doing it themselves.

As an example: Until relatively recently, if you used a Google Blogspot blog with a custom domain (a domain hosted elsewhere) you couldn’t use HTTPs.

Worse, Google decided to ding search rankings for sites not running HTTPS and also mark them as “not secure”. Imagine having your blog on Google’s Blogspot, and Google both not offering HTTPS and penalising you for not using HTTPS!

In short, many were the obstacles for getting HTTPS up and running. If you managed to dodge the cost bullet back in the day, there was still the complexity bullet waiting in the wings. Considering many folks run different services with different orgs based on price, functionality, and location, firing up HTTPS on your site was not an easy task. For every person dismissing concerns with “that’s easy”, you could find a dozen more who follow all the steps and end up with something not working regardless.

What changed?

Google’s decision to penalise the search rankings of non-HTTPS sites was just one of a raft of carrots and sticks that emerged in the second half of the last decade which pushed HTTPS adoption from the niche to the mainstream.

The trend started about ten years ago with Firesheep, a browser plugin that shamed the big social media sites for not using HTTPS, before being accelerated enormously by Edward Snowden revealing the vast scale of Internet surveillance.

The response came in many forms including changes to search engines, free HTTPS services, better web hosting, new web protocols, and, as we’ll see later, web browsers.

A fanfare and a big parade for the good stuff

There is a tendency in security to focus on good security practices as unusual and point-from-across-the-street jaw dropping, and bad security practices as commonplace and not-very-pointworthy.

There’s a few problems with this. We’ll return to the ubiquitous padlock as an example.

If you go back a few years, when padlocks on sites became the Latest Big Deal(), it was an instant banner moment for “this is definitely a good thing”. You couldn’t move in some circles for endless promotion of the padlock, our new hero.

And hey, the padlock most definitely is good! However, it doesn’t mean it’s not also used for evil deeds.

A common talking point is “Look for the padlock. If it’s there, it means the site is safe”.

Well, no. It means it’s secure in as much as the data can’t be peeked at by random observers. The data can still be received as intended by an evil site owner. What do you think this means?

It means, lots of phishers and scammers started setting up HTTPs websites.

As a result of the “Padlock = safe” messaging at the time, some would-be victims probably didn’t land on a fake bank site and think “Oh my, this looks dubious. Time to leave. Nice try, phishers”. They likely assumed “The design is slightly off, but it’s got a padlock and everyone told me a padlock means that it’s safe. Phew.”

This problem became even worse once free HTTPS became popular and affordable, if not completely free for most folks. All of a sudden, we had lots of security resources and training saying “padlock means it’s the real deal” while lots of fake sites started sporting padlocks.

This is a small example of how hyping up a secure feature which becomes available to all, can go wrong without the consideration that bad people will use them too.

Back to browsers.

A fanfare and big parade for the bad stuff

Chrome is following the trend of rolling back on “this is secure” notifications, which as we’ve seen may not be 100% helpful, in favour of just saying “This one here is not secure. Avoid it”. This mirrors (deliberately) the change the web has undergone HTTPS being unusual to being the norm.

Sure, people trained to look for padlocks are suddenly not able to view them. On the other hand, padlock sites are so common now that seeing the padlock isn’t that useful anymore.

From now on, it’s business as usual until Chrome says BAD SITE.

This isn’t a recent plan, by any means. If nothing else, Chrome tends to give lots of advance warning of changes coming up so people can adjust for them as needed. It first mentioned this move way back in 2018, when it said “Users should expect that the web is safe by default”. To be more specific, they decided to change what displayed in your URL bar as follows:

[Padlock icon] | [Secure],

They stated their aim to remove the word “secure” so you’d only see

[Padlock icon],

Which would eventually lead to their final intended state of

[Website]

…with no padlock, or the word “Secure” next to it. Do you remember when Chrome used to say “Secure” next to the padlock indicator? I don’t! It hasn’t hurt my browsing in any way. I strongly suspect the padlock icon being removed won’t harm it either. Why continually highlight the norm, if the norm is functioning as expected?

It seems more sensible to hang a big sign saying “This is bad” on the bad stuff and call it a day. It’ll be interesting to see which browsers follow suit, assuming there’s some out there which haven’t already taken this step. If you’re a Chrome user, don’t be alarmed when our little padlock pal takes its last steps into the distance.

The post Chrome casts away the padlock—is it good riddance or farewell? appeared first on Malwarebytes Labs.