Back in February Google let everyone know in a blog article that their Chrome browser would start treating sites that were still delivered over HTTP (as opposed to HTTPS) differently.
Time is an odd thing. When I read advisories for 2020 I tend to discount them because “by then, we will all be in silver suits with spaceships” only to realise that this is, of course, a matter of months away. While July probably seemed a long way away in February – the day is upon us, and people are going to start noticing browsers prepending URL’s with NOT SECURE, and this is avoidable with a little bit of planning.
The short and sweet version is:
“If your website only supports HTTP, then Chrome is going to show NOT SECURE in the address bar next to the URL. Get a certificate now.“
This is likely the thin edge of the wedge, and wherever this progresses to, and however that manifests itself you probably don’t want visitors to your site seeing NOT SECURE next to your name.
While now is the time to sit back and be thankful you made those changes over the last six months – otherwise deploy the emergency plan:
1. Apply a Let’s Encrypt for the time being;
2a. Ensure you have a redirect from HTTP to HTTPS in your web.config or .htaccess;
2b. To replace the LE certificate, purchase a validated certificate or extended validation certificate to meet your further needs if you are a business, charity, or process funds.
If in doubt – get an authorized contact to email support@hostinguk.net or raise a ticket through your control panel so we can look into it further.
The TL;DR version of what it is and why it matters…
HTTPS is the ‘secure’ form of HTTP – while accurate, this doesn’t help as to what is going on, or what differs, and why you would want to be ‘secure’.
HTTP is the method used to ask for and deliver your requested web pages from the Server to the Browser.
So what is the big issue?
Assuming you are not connected to the Server delivering the page by a single cable (that you can see all of) then its pretty much a given that on its journey it will pass through a lot of
– Go down a cable into a switch, or switches of the server’s network;
– Pass through one or many routers;
– Through one or many security devices;
– Out onto one if not many networks not owned by the provider;
– Pass through ‘some’ pieces of hardware that you have zero control or knowledge of…
– Before making its way onto your provider’s network;
– Through one or many security devices;
– Pass through one or many routers;
– Go down a cable into a switch, or switches of the server’s network;
– Through the air or over a cable to your device.
You get a general idea: There is a heap of capacity for a device to be compromised en-route and thus the contents of the traffic. Whether this is the ‘bad man’, ‘a state entity’, ‘a curious soul’, ‘a competitor’, ‘a technically competent ex’ it doesn’t matter – the outcome is the same:
– They can see everything you see/type;
– The traffic you are seeing can be changed en-route without means of detection.
HTTPS – often referred to as an ‘SSL certificate’ is probably best thought about as a tunnel between two points. The two endpoints can see the contents (and rapidly become the focus of the ‘bad man’), but between the two – nothing. Certificates encode each tunnel as a combination of browser and server, so each encoding is different. While they are referred to in parlance as SSL certificates – the days are long gone since SSL was considered secure – and, with a bit of luck, and a fair wind, these will be dealt with over TLS 1.2 only (and maybe even TLS 1.3 if you are super shiny).
Servers deliver websites. Websites can have an SSL certificate. They can have their HTTP traffic redirected to HTTPS. Then automagically, with minimal friction, almost transparently, the traffic passed from them to you within an encrypted tunnel.
Errors – I am seeing Errors?!
Traditionally you would see a certificate error when one of the following occurred:
1. The certificate has expired;
2. The name on the certificate does not match the site it’s being used with;
3. The content on the page is not all delivered over https – some bits are provided over http.
The top two – strictly speaking are not any less secure – however are indicative of shoddy management, and you may wish to wonder if these are the people you need to be dealing with more than anything else.
The latter is darker, and is more likely to be indicative of bad code or something rather unpleasant happening between you and the server.
New on the list is going to be:
4. The site is only available in HTTP and is to be considered “NOT SECURE”
This was shown as below in the February article:
This is – like points 1, 2, and 3 – not the kind of thing you want on your business website. Trust is priceless.
This is why this, the thin edge of the wedge, and the beginning-of-the-end for HTTP only sites.
So what do I do about it?
Get a certificate. Story ends.
…as this is not just your customers, the way Search Engines view you also varies on your HTTPS status. So, install a certificate.
Simple as that huh? Yup.
All you need is a platform that will support the certificate (all), and any resources the server may need to deliver that. This would be either a certificate with an IP address just for you or more likely for current deployments (that support SNI), just a certificate and some magic glue that will allow many certificates to be on a single address. Amazing.
Things have moved on a great deal since their inception, however, there are essentially four flavours of certificate:
1. Self-sign – all the browsers complain but is secure, free;
2. Let’s Encrypt (or similar) – browser friendly and FREE;
3. Extended Validation – where your company name appears in the address bar;
4. Fancy and special purposes.
With point two being a thing – there is next to no reason why anyone would still have a site that was ONLY available in HTTP.
So, here we are.
If you would like to talk about the specifics of certificates, grab us in chat, drop us an email, or pick up the phone to speak with one of our engineers.