We previously wrote about Google’s announcement to prioritise websites with a secure HTTPS URL in website rankings, and talked about how the switch can not only improve your ranking but also help make your site more secure.
Here at Axonn we’re not going to tell you how and why to do something without doing it ourselves, so we also recently made the switch to HTTPS. This means we can accurately show you how to move over successfully, and how to deal with the bumps in the road we experienced along the way.
Why did we change over?
HTTPS makes websites safer. That is the major selling point. While it does not protect against potential GCHQ intercepting and analysing traffic, organisations with less resources are unable to intercept and modify the data sent between the website and the browser.
Without HTTPS, criminals can both read and modify the data that is sent back and forth between browser and server. One of the consequences of an unsecured site is that someone could use it to steal your Facebook login. A more catastrophic result is that someone, or something, could install malware that steals your online banking login.
The cherry on the top is that Google (slightly) prefers sites that work on HTTPS.
Why should you change over?
We use the word “community” a lot when speaking about websites we frequent. Being part of a community also means to keep the community alive and active. Not securing a website means that it is open to spread malware and that hurts the community. A part of simplifying content marketing is making the tools safe to use, making the web safe to use. So it can stay fun to use. Enabling TLS is one part of this.
Even where altruism is not the motivation, the damage done to a brand can be great if that brand’s website is (unwittingly) used to distribute viruses.
The likelihood of your website being used to spread malware is of course low. But just like with car insurances, if an accident does happen in the end, the costs can be very high. Imagine users seeing this when trying to reach your website:
People aren't going to give you the benefit of the doubt if they think your site could be dangerous. They're not going to risk their computer and their personal details to access your site.
What did we have to do, and how did we do it?
The essence of switching a site over to HTTPS is acquiring TLS certificates from a reputable certificate authority and installing them on the web server hosting the site. This is, unfortunately, something that requires development / IT time in almost all cases, but is (again in almost all cases) something that needs to be done only once.
In practice, for best security and trust, a move to HTTPS involves not just securing one’s own website, but also making sure that all resources used – widgets and scripts from various marketing tools, analytics, CTA services etc, as well as images and videos that are embedded – use HTTPS as well. This is where that complexity usually arises.
How complicated was the switch?
There is a certain overhead, especially for “newcomers” to HTTPS. If the company never had any TLS or SSL certificates, or if the administrators are unfamiliar with it, there is a small learning curve. But understanding certificates and how to use them is the only barrier of entry on the “technical” side.
Implementation-wise, the principal idea of TLS is to make sure that no one can sneak in malicious content; to achieve that, the browser must be able to trust the data it receives. That means every single item the browser loads – HTML, styling, images, scripts – need to be trusted and need to be properly served via HTTPS. This is where issues can arise. For example, Instagram does not support HTTPS at all as of the time of this writing. Your CDN might support HTTPS, but not if you use them with a custom host name; or if they do it is prohibitively expensive for smaller companies.
What is HTTPS and how can I use it to improve my rankings?
Is there an easier way of doing it?
HTTPS/TLS solve a specific problem. As far as web browsing is concerned, there is no viable alternative to date. However, HTTPS is only one part of a comprehensive security strategy – unfortunately, it alone does not make for a secure website, but it definitely is an important step to do towards that goal.
Furthermore, achieving a basic TLS-encrypted serving of one’s website is fairly straightforward, as hinted above. Allow your developers to get a certificate and install it, and already the web is a safer place. If your company is committed to high levels of trust and safety, it definitely helps to check existing web pages, and have a strategy in place to move to a fully HTTPS-enabled website before implementing this.
There are varying levels of trust in TLS. In order of trustworthiness, the levels are:
Green padlock icon: Certificate signed by a trusted party, all resources delivered through trusted channels.
Padlock with yellow triangle: Certificate signed by a trusted party, but the page contains so-called mixed content. That is, some parts of the page are unencrypted.
No padlock: Page is not encrypted.
Red icon: Page is encrypted, but the certificate is not trustworthy. Be very careful about trusting sites with this kind of icon.
There is a trade-off between effort and trust; it can take up some time to “clean up” a website to present green padlocks. Generally, the “yellow lock” level of mixed content is sufficient for the average website. If your site accepts or emits sensitive information, or information that can be used to identify visitors, I would emphatically suggest making some effort to move completely to HTTPS and get a more trustworthy green lock. The website whynopadlock can be used to analyse a page and find out what elements prevent getting a shiny, green secure lock.
Another, smaller effect that the switch to HTTPS will have is that the website will consume more CPU time. Encryption implies that certain computations have to be done, which will increase load on the CPU for each request. In general, this should not pose any problems; it is likely to only cause issues on websites with a high load to begin with, or websites that are hosted on so-called “shared hosters”, that need to share one server with many other websites as well.
What went wrong?
Here is our devil in the detail: Instagram. The purpose of TLS encryption is to ensure authenticity of the server as well as integrity of the data. Instagram simply does not offer embedding content TLS encrypted, only via HTTP-without-S. So content we had hosted on Instagram had to be moved to another provider.
Another point for us are content delivery networks (CDN). They are a tremendous boon for page speed if static resources are placed there. A website’s images often rest on CDN servers for this reason – but then these images qualify for “external resource” and need to be served on HTTPS as well. However, some CDN providers ask quite tangible fees to allow customers to use TLS encryption, especially if they wish to use their own TLS certificates. Several hundred pounds per month is not unheard of.
How did we fix it?
Training content producers to be aware of this issue and use care when including external content, libraries and services is a first step. For example, if I am not aware I have to use HTTPS when embedding services like Flickr or YouTube, I will keep accidentally breaking out of a TLS encrypted delivery.
A second step follows naturally: cleaning up the website’s content and ensuring that every dependent resource is requested on HTTPS. Which included some updates to Axonn’s background services, like our CDN as mentioned above.
What were the results?
It is the nature of the beast of security that ideally it is invisible. No-one wants to have to deal with safety and security on every website they browse. As security-related topics only come to attention when things go wrong, I am rather happy that the upgrade has been quiet and uneventful. We’re working out of the way of our visitors to keep them safe as best as we can.