‘Secure’ does not mean ‘safe’

Joel Samuel
5 min readJul 1, 2018


I have previously written about good TLS configurations for HTTPS, intercepting HTTPS user traffic (why organisations shouldn’t) and briefly touched on very small aspect of Security-v-Privacy (data retention for security purposes).

The conversation around TLS for HTTPS is peaking in regards to the benefits of HTTPS on websites and changes web browsers are making in regards to the same— so I thought I would jump in on that bandwagon and then extended the conversation.

What are web browsers changing?

Lets start at the underlying technical, user-design and user-experience changes which are at the centre of all the hoo-ha.

We’re approaching a series of changes to how HTTPS (encrypted) and HTTP (unencrypted) website indicators are being displayed in browsers.

In essence, HTTPS is the new norm (it should be the standard, not a positive) thus HTTP is no longer good (it is now sub-standard, so should be flagged and penalised).

We’re also seeing a move away from positive messaging (green bars or text, padlocks etc) given the shift in standards.

First, changes to the display of HTTP (unencrypted) websites

Chrome 68 (July 2018) will be released and it will display a ‘Not secure’ message for all HTTP pages.

The Chrome Security Product Manager discusses the change in this blog entry.

In Chrome 68, the omnibox will display “Not secure” for all HTTP pages.

Then, the changes to the display of HTTPS (encrypted) websites

Chrome 69 (September 2018) will display a small padlock (for now…) and no longer show a green ‘Secure’ in the omnibox for HTTPS pages.

Chromium’s blog post on this here.

Chrome treatment for HTTPS pages

Eventually, we’ll see the non-display of Extended Validation certificate information within the omnibox

Currently, the ‘Organsation’ and ‘Country Code’ fields from valid Extended Validation (EV) certificates are display within the browser’s omnibox.

At some point, we will see browsers not display this information and drop the associated green colour coding.

Why do these changes matter?

HTTPS is better for you, your users and the relationship in between

There are various reasons why HTTPS is always good and through extrapolation of the inverse why HTTP is always bad.

So, what does ‘safe’ have to do with this?

HTTPS is pseudo-management validation, privacy and integrity

  • Pseudo-management validation— the website manager(s) must sufficiently pass certification issuance checks — whether domain validated (DV), organisation validated (OV) or extended validation (EV) — to be issued with a certificate from a public/recognised Certificate Authority (CA).

I say pseudo-management validation as opposed to ownership or identity as the most popular validation type (domain) only requires an email, DNS or file verification workflow for one-time proof that the domain/website is indeed under the certificate requester’s management.

Domain validation does not seek to understand the identity or legitimacy of the website manager/owner nor their intentions.

  • Privacy — assuming well-configured TLS is in-use: the data exchanged between the user and the website’s servers will be encrypted and not visible to third-parties (ISPs and so on)

Tip: Qualy SSL Lab’s test can help you identify bad encryption configurations on your website.

  • Integrity — stemming from the encryption mechanisms the integrity protects data from being manipulated between the user and the website’s servers.

Integrity is important — you can read more in my open letter to the BBC about their HTTP and HTTPS configurations.

HTTPS is great, but it does not tell you if the website is ‘safe’ (true, dangerous or responsible)

  • True —whether the site is what it says it is

HTTPS alone will not tell you if https://trust.onlinebanking.hsbc.com.ech0.com is a legitimate online banking service from HSBC or not.

  • Dangerous — whether the site is bad for you

HTTPS alone will not tell you, nor save you from, sites containing malware or otherwise intending to harm you or your device.

  • Responsible — whether the website operator is not bad

HTTPS will not tell you whether the website operator has good security within their office or backend systems to keep your data safe, nor whether their intentions are pure and if they intend to sell your data or steal your credit card information.

What does keep me ‘safe’ online?

Web browsers do have unsafe site detection systems to help keep users aware and away from websites detected and/or reported as being illegitimate or nefarious.

Even with these systems, given the automated scale of how phishing (for example) sites can be born and operated the war against online baddies will continue to rage on.

Making HTTPS the new standard means phishing sites based on HTTP are less likely to succeed on the basis that users will see the ‘Not secure’ indication and hopefully will be less likely to engage in the site (entering personal information etc).

While HTTPS is easy to implement, it will still add a layer of complexity (however small) for these online baddies which increases their ‘cost’ of being bad.

Quick-fire debunking of some of the related questions/statements circling at the moment

“Google is trying to influence the Internet”

By promoting encryption? Awful!

“My website doesn’t need HTTPS”

Read this, this and this.

“Extended Validation is important and wonderful”

Un-bias (non-vendor driven usually) data summarily shows that users do not behave differently when EV is not present in order to give EV any meaning/value.

“Implementing HTTPS will cost me money”

LetsEncrypt is free.

“Implementing HTTPS will cost me time/effort”

Yes, but what part of your website doesn’t? — content creation through to upgrading WordPress or patching your server all take effort.

“Implementing HTTPS is hard”

Putting any thoughts I have about CloudFlare to one side: check out a micro-site from Troy Hunthttps://httpsiseasy.com/.

My internet technology varies — I use different ISPs in different locations, I use AWS’ public cloud and multiple private clouds (usually VMWare) with a mixture of control panels (DirectAdmin and cPanel) or no control panel at all (boring LAMP on Ubuntu all managed via SSH) and even have some shared hosting.

I don’t recall expelling much effort implementing HTTPS across the board. HSTS was also easy/quick. CSP was much harder on my more complex sites.

You might find other exciting posts in my Medium profile. I’m on Twitter as @JoelGSamuel.