I’m sure most of our readers (me included) have been telling users for years to always check the existence of the lock icon when entering sensitive data in a browser. This was always an easy way to check at least if data in transit is secure, provided that the user did not blindly click on Accept when a popup about an incorrect certificate appeared.

Now, we can probably debate till tomorrow about how good or bad this is – there are many, many attacks that can abuse such naïve users – Moxie’s sslstrip (https://moxie.org/software/sslstrip/) probably being the most commonly used: when hijacking HTTP traffic it will silently supply a favicon file that looks like the lock icon in order to fool users into thinking that everything is OK. And this is just one (cool) example.

Back in February, Google announced that sometime in July, with Chrome version 68, all HTTP sites will be marked as “not secure”. This is Google’s initiative to move everything to HTTPS, which is nice – since SSL/TLS certificates can be now obtained for free (see Let’s Encrypt https://letsencrypt.org/ but also be aware that also bad guys can get them for free), there is no more reason not to have your site accessible (only) via HTTPS. Indeed – if you haven’t done so already, make sure that you do this as priority.

If you want to test this feature, you can download Chrome Canary (version 69 currently - https://www.google.com/chrome/browser/canary.html) and simply open a non-HTTPS site and you will get this:

About 2 weeks ago, there was a new post about Chrome’s security indicators at https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html. It seems that Google will again change security indicators, this time with Chrome 70, which is supposed to be released in September.

With this version, HTTP sites will be additionally marked with a red warning sign when a user starts entering data in a form. I like this feature.
However, I’m not sure what to think about the second change they will probably introduce: Chrome will no longer mark HTTPS sites as Secure. Google’s reasoning behind this is that the default unmarked state will be secure, and that they will show non-secure warnings to users.

This is kind of odd from a user education perspective. There are two potential issues here:

• First, users might get confused about not seeing the lock icon and the Secure text any more. Not too big of an issue though – they are at least secure.
• This is what I don’t like though: once users get used to everything being “secure” by default, what happens if they go to a machine with an old version of Chrome (or a different browser)? I recently did a penetration test in an enterprise that had all users running Chrome 44 – the reason being that this was the last version with NPAPI (read: Java) support. While we can discuss how bad this is, it can certainly be problematic for a user that gets used to behavior of Chrome 70 and then ends up with Chrome 44.

Google is sure aggressive with updating Chrome, but can we make sure that everything is updated? I think we all know the answer.

As always, time will tell if this was a good decision or not. 

What do you think about these changes? Good or bad? Let us know!

--
Bojan
@bojanz
INFIGO IS