HTTPS: Following Protocol for a Secure User Experience
If you’ve ever been searching the web and found yourself wondering why some URLs start with “http://” and others start with “https://”, you’re definitely not alone.
More than an Internet eccentricity, this one letter difference is the difference between a secure and unsecure website. And, in this age of identity theft and data misuse, you can see how that can make a huge difference.
Where’d That “S” Come From?
First off, let’s talk protocol. When you enter a URL into your browser, it usually starts with a protocol which tells your computer how you want to access something. In addition to HTTP and HTTPS, there are several other protocols like “file://” which loads files from your own computer or “ftp://” which gives you a two-way connection to server files.
Now for the “s” – that extra letter in HTTPS comes from its SSL (Secure Sockets Layer) certification, a standard security protocol for establishing links between a web server and a web browser that ensures all data transmitted remains encrypted.
We’re not just securing a site, we’re securing its Network.
When you access a site using HTTPS, and the website has an SSL certificate, your site is accessed with strict rules for security. The SSL certificate is a computer’s ID card. Your computer and the server “show each other their ID”, so to speak, and you both take responsibility for all information sent back and forth. If you both have valid ID’s you see the little green lock in your browsers address bar.
Now, because a website is made up of links and references to other pages and because it loads scripts and images using links, the security rules require that all of those references and links are also loaded securely. Every picture, link and form in a site is represented in the code as a link to something else on the internet, even if it’s on the same website and those links have to start with HTTPS.
If the developer who wrote the site chose to make those links all start with HTTP instead of HTTPS then the SSL connection fails and the browser essentially says, “You can’t completely trust this site, because it has a bunch of shady friends hanging around who won’t show their ID.” This will cause a red lock or a red x in your browser, it may even make Chrome give you a big red screen that says “THIS SITE IS NOT SECURE.”
Why Does This Matter?
With the July release of Google’s Chrome 68, which makes up just under half of the browser market share, all unencrypted sites will now be flagged as “not secure,” whereas previous versions only required SSL in place on pages that include forms or login certification.
More than just an annoyance, this can also a problem where content is concerned. A recent HubSpot survey found that as much as 85% of people will not continue browsing if a site is not secure. So, if blog or social post that contains unsecure links, it can prevent people from engaging with that content. Not a great use of time or resources.
Additionally, if your site is unsecure, it’s easier for malicious entities to spoof (or impersonate) your site using a similar domain to mislead users and steal their information.
So, What Can You Do?
You want a secure site and you want your customers to feel secure using it. It’s not rocket surgery. That said, adding or fixing an SSL certificate on your site can be expensive.
Some certificates can cover all of your websites; they are more expensive at first, but cheaper in the long run. Other certificates are considered more secure because the people issuing the ID actually reach out to the company purchasing it and verify phone number, physical address, employees etc.. These are expensive and can take WEEKs to verify, but you can be trusted to do more things then. But most of the certificates we’re concerned with take a day to verify, and cost about $50/year – a small price to pay for ensuring your visitors can actually access your site, if you ask me.
If a site has a certificate but it gets the big red X, or sometimes a little “i” in a circle, it’s a certificate problem. To fix that problem, we need to fix the links or fix the SSL certificate. Sometimes it’s making a bunch of bad references like we’ve discussed so far, but sometimes the certificate is just expired, or perhaps when we moved the site to a different server, the new server didn’t have ID, so we need to make a new certificate.
When we add an SSL certificate to an existing site, we have to go through all of the code and the database and hunt down every single link and reference and change them from HTTP to HTTPS. It’s, quite frankly, a pain in the butt. That’s why a smart developer won’t use “http” or “https” in his or her code (called an absolute link). Computers are smart enough to make URLs that start with a “/“ just match whatever access method was used at the time (relative links). We developers get all riled up when we see someone else’s code full of absolute references – it leads to a nightmare of rewriting code and a very large bar tab.
In web protocols, that little “s” in HTTPS matters a whole lot. Without an SSL certificate, it can cause your site to not load when you click on the Google search result or integrations like social media feeds within your site to not function. At the very least, it’s a bad user experience for your visitors – and at worst, it’s a security breach waiting to happen.