With Google including HTTPS (also known as HTTP over TLS) as a ranking signal in mid-2014 the discussion around it has been heating up ever since. Whatever you think about Google's argument that all web traffic should run over secured connections, you can't ignore the fact that it's now a significant part of the Google ranking algorithm and needs to be considered as part of your Search Engine Optimisation strategy if you rely on Google rankings. If SEO isn't your primary concern there are wider reasons why HTTPS might be worth considering.
Personally I was a little sceptical about the need to have all of the web running over HTTPS. In my opinion there were/are many websites and use cases where HTTPS is just encrypting the exchange of mundane data that has little to no value to an attacker. My view on this has shifted of late and I can see why the default of private connections and data is preferable, to put it simply, if you had the choice of having someone (anyone) listening to every conversation you had or not I think the choice would be simple.
So, with that out of the way let's have a look at HTTPS.
How does HTTPS work?
The best way to answer this is to describe how HTTP works. HTTP (HyperText Transfer Protocol) is the protocol that defines how web servers and web browsers communicate and share information. A simple overview of the process between a web browser and a server is:
- A user opens a web browser and either clicks a link or enters a url into the address bar
- The web browser (client) makes a request for a document (web page) from a web server
- The server checks the request and whether or not it can fulfil it, if it can it responds with a response code and a document, or an error on failure
- The web browser receives the response, if this is a page of HTML it displays it
- The user views the content, if the user clicks a link to another page the process starts again
That's a massive over-simplification of the process but it's sufficient to frame the role of HTTPS in the chain. The problem with this exchange is that HTTP is a simple, human readable protocol. Unfortunately it takes very little skill or knowledge to install HTTP packet sniffing software and interpret what you're seeing. What this means is that every part of the exchange is potentially visible to an eavesdropping third party. The kind of information they can see moving across the network includes:
- Your IP address
- The server's IP address
- Information about your system, OS, browser, plug ins etc
- The domain name of the site you're visiting
- The page you're requesting on the domain
- The contents of the page you're viewing
- Any information you have stored in a cookie
- Any information you have submitted in a form
Here's an example of a HTTP response message from a web server, this is how it would appear to anyone 'sniffing' the network.
HTTP/1.1 200 OK
Date: Mon, 11 October 2016 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Accept-Ranges: bytes
Connection: close
The HTML page you requested goes here, in plain text/html, all of those funny cat pictures ... and other stuff you look at.
The above is an example HTTP response from the server, as you can see it's easily readable
As you can imagine to the right person this kind of information could be incredibly valuable. Fortunately it's actually not trivial to carry out attacks that could take advantage of this inherent insecurity, they can and do happen but they're unlikely to affect most internet users. It's actually more concerning when you think of the mass surveillance of internet usage and collection of data for commercial use when you consider it's all so easily readable.
So HTTPS solves this problem?
The answer is... almost. HTTPS will encrypt the bulk of the exchange but there are a couple of pieces of information that have to be outside of the scope of the encryption for the underlying protocols to function correctly. The most significant pieces of data outside the encryption are the domain name of the site you're visiting and the IP addresses of the server and your computer. These things cannot be encrypted as they're both needed in the process before the data is actually encrypted - the IPs are needed by the TCP/IP part of the stack and the domain name is needed to ensure encryption can work on shared hosting environments. There are suggestions floating around that could improve this situation, but to go to that level you'd also have to look at encrypting the preceding DNS lookups.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Packet Tap), capture size 65535 bytes
..................www.cowshedworks.co.uk.....#..X..-"..b.n...uThis snippet of output from tcpdump shows the URL or this site in an encrypted HTTPS transfer.
So, whilst HTTPS isn't 100% private it essentially makes it a total PITA for anyone looking to snoop on what you're looking at on the internet. When you compare it to plain old HTTP it's an order of magnitude better as a default communication protocol.
Should my small business website be using HTTPS?
So, on to the question that this blog post is trying to answer, should a small business website be using HTTPS to secure the site and visitor sessions to it? The simple test is really to answer the question:
Is it ok that anybody who sits between your customer and your website can potentially see everything they are sending to and reading from the website?
Answer No - HTTPS is the way to go.
Answer Yes - you probably don't need HTTPS as your site isn't revealing anything significant about the user or your business, that's fine but read the next section to make sure you're aware of the potential issues of not going to HTTPS.
What happens if I don't use HTTPS?
There's nothing to suggest that your site or users will ever be the victim of an attack by not switching to HTTPS. If you run the kind of website that could contain valuable data the chances are you're already aware of this and are using HTTPS or have other safeguards in place. Just because the industry is shifting to HTTPS it doesn't mean there's an impending disaster for you if you don't do it.
However, whilst you might be comfortable with this setup there are two groups who aren't:
- Google - they've explicitly stated that they want to see the web move to a position of HTTPS as the default - websites not running on HTTPS will be seen as lower quality than those with - they will be returned lower in results - that's a fact.
- Privacy concerned users - people are becoming increasingly aware of privacy and are taking steps to protect it with the use of anonymising software, ad blocking plug ins and increasingly they're not prepared to trust websites that don't have the HTTPS padlock displayed
It's not a huge leap of imagination to see a situation arising where the major web browsers move to warn users that the site they're about to visit isn't secure. At present if an invalid SSL certificate is discovered the browser will put a roadblock page in the way before the user accesses the site. I can see a time coming where this roadblock is there whenever a user tries to access a non-HTTPS website, perhaps more of a warning initially but this kind of functionality will no doubt be appealing to most users.
Switching to HTTPS
It's really not tricky to do, you can pick up a certificate for around £35 / year and lots of website CMS systems will have a way for your to force redirect to it. You just need to ensure that the redirect works properly and you're giving Google everything it needs to see what's going on with the switch.
It goes without saying that we can help with this.... there it is, the plug.... to be fair I wouldn't have spent an hour writing this to not drop this plug in would I? Let us know if you need help with any of this stuff, better still put your site on our platform and we'll take care of it all so you can forget everything you've just read, if you haven't already! :)
