Secure websites with HTTPS

HTTPS, or the green padlock, as most internet users probably understand it, is a little understood technology (even for IT literate people never mind the general public!) - mostly because it's quite complicated. Most know a green padlock means the website is secure, but don't really understand why that matters or how it is made secure. And why it's a really really good thing, but I'll do my best to explain.

The internet was built on the HyperText Transfer Protocol (HTTP) which basically defines how pages can be requested by a web browser, and how the web server should respond and deliver the page requested. HTTP's major flaw is that it sends messages back and forth in plain text that can easily be listened in to. This was not a problem when the internet first started and was just a few web pages that anyone was allowed to read, but now with rich web sites that allow anything transferring money from your internet banking, to shopping - security is a key consideration and HTTP is just not right for any of these sites.

The classic analogy is that it is like a postcard. If you wanted to post a cheque to your bank, would you staple the cheque to a postcard, where anyone could read it, steal it, or maybe alter it? Of course not!

HTTPS is a way of adding security on top of HTTP. HTTPS works by having an initial set up phase were encryption methods are agreed between the web server and the web browser, and then all traffic is sent encrypted, rather than as plain text, but is basically the same as HTTP traffic. Using HTTPS gives three things:

1. Encryption: All web traffic will be encrypted. So passwords sent using HTTPS from login pages will not be able to be read by anyone listening in (including hackers, Internet Service Providers.
2. Integrity: Reassurance that the web traffic will not be altered en route. So if you send a message through your online banking over HTTPS to transfer €1,000 to someone, it cannot be changed to €100,000, or the destination account changed.
3. Authentication: Confirmation that you are talking to the real website your typed. This is the weakest part of HTTPS (we will go into why below) but in theory HTTPS gives you this confidence, though there is some debate as to whether that just means the website your typed (including any typos which means you are actually on a different website than you intended), or the website you trust.

Or, as to the average internet user sees it, "it means the website is secure" which, when all the above is true, is a pretty good summary. Any time you are sending personal data - be it a password, or credit card info, or pretty much any personal details you should be using https:// as your web address and have a green padlock. There is some misunderstanding on whether this means the connection to the site or the site itself is secure however, and I've blogged separately on What does the Green Padlock really mean?

HTTPS is basically HTTP over SSL or TLS encryption. SSL (or Secure Sockets Layer) is the predecessor to TLS (Transport Layer Security). So you will often hear HTTPS referred to as SSL, TLS or sometimes even SSL/TLS. In terms of website security you can assume they all mean the same, and I've chosen to go with HTTPS on this site.

So should you implement HTTPS on your website? Almost certainly yes. More and more websites are moving to HTTPS. This is due to a number of factors: an increase in online activity that should be kept private and secure (e.g. e-commerce), privacy considerations (e.g. with government spying), the trust this gives with your visitors and finally because the cost (both in terms of the certificates, and the computational burden) of supporting HTTPS on your website has dropped dramatically, so there less reason to not support HTTPS. Currently when you enter a website without the protocol (e.g. www.google.com, instead of http://www.google.com or https://www.google.com), then your web browser assumes you mean http:// and, while that will probably stay like that for some time, there are already calls that https:// should be the default. Google have already that they will be using HTTP as a ranking signal. HTTPS should be the new norm for any half decent website and you really should be always looking to use it unless you have a very good reason not to use it.

HTTPS basically works like this: Any web browser connecting to a https:// site rather than a http:// site will be presented with a digital certificate by that web server. The browser will check that certificate matches the server you are trying to connect to (www.google.com), that it is still valid (certificates have an expiry date), and that the certificate was issued by a Certificate Authority (CA) that your browser trusts (each web browser and/or PC comes with a list of 50-60 accepted certificate authorities - though they will in turn cause you to trust many more sub-authorities). This confirms you are talking to the correct website (though see below for further discussion on this), so after that the browser uses the certificate to encrypt some information about how it could handle the HTTPS session. The web browser, as the certificate owner, can decrypt this and then confirm to the web browser how the HTTPS connection will be handled. After this the browser can request the web page it originally wanted but over an encrypted channel now.

Therefore to set it up you need a certificate. Certificates have to be bought from one of the 50-60 trusted certificates that most web browsers trust, or some of your potential visitors will not be able to visit you website. Certificates typically cost anything from nothing, right up to several thousands of euros/dollars/pounds. So what's the difference? Are the free ones any less secure?

There are basically three different types of certificates:

1. Domain Validated (DV) certificates just involve the CA validating you own the domain you are trying to buy the certificate for. This is typically done through an automated system by asking you to upload a file to a specific directory on that domain, sending a link to the e-mail address associated with that domain, or by adding an extra tag to the DNS entry for that domain. The prevents you buying certificate for www.google.com for example. DV certificates are the easiest for a Certificate Authority to issue, and so are the cheapest (LetsEncrypt issue them for free for example). They show up with a basic green padlock symbol.
2. Organisation Validated (OV) Certificates involve the CA checking that, not only do you have access to that domain, but also verify your identity of you and/or the company (e.g. by asking you to e-mail a scanned copy of your passport, proof of address, the company registration documents...etc.). As there are some manual steps to verify OV certificates there is a higher cost for these typically €100-€200 for a one year certificate. Weirdly browsers pretty much do not treat OV certificates any differently to DV certificates as you get the same green padlock in the address bar. This might get you wondering what the point of an OV certificate is and that is a very good question! Some CAs do not issue DV certificates, presumably as not worth their while since they can't be competitive with this given the price some companies issue them for. So if you want to purchase a DigiCert certificate for example you have to go with OV (unless you are willing to spend extra on EV). So what you are really purchasing there is the help and support of that CA, and they just give you an OV certificate as the cheapest version they support.
3. Extended Validated (EV) Certificates involve extensive background checks to verify the company is officially registered and the person requesting the certificate is entitled to request a certificate for that domain. These typically cost €300 - €600 for a one year certificate. EV certificates show the company name in most browsers and make the whole address bar green.

These are shown in the pictures below for a range of browsers:

There's a few interesting things to note: Chrome and Firefox have started marking HTTP sites with an info bar and Chrome explicitly marks HTTPS sites as Secure. IE11 and Edge only show a grey padlock for HTTPS. Interestingly some of the browsers emphasize the main domain (and show the www part in a lighter grey colour and/or remove it completely). The main point however is that an EV certificate is not any more secure in terms of the encryption it uses, but is more secure in terms or the CA validating who the certificate requester is, and that is rewarded with extra green assurances in the browser. I'm not aware of any incorrectly issued EV certificates that were given to third parties (though Symantec a well known CA did recently issue some internally for testing), though there are many, many cases of DV certificates issued in error to incorrect parties.

As well as the certificate type, the following factors will alter the cost:

• How many domains you want the certificate for. It is possible to have one certificate for multiple sites, which is usually cheaper than buying separate certificates, but you do pay per domain.
• Whether you want a wildcard certificate. Wildcard certificates allow you to have several subdomains without having to explicitly tell the CA which ones you will use (e.g. if I had a certificate for *.tunetheweb.com could be used for many subsites under the tunetheweb.com domain). These tend to be expensive.
• How long your want a certificate for. Most certificates are valid for a year, but you can pay extra to get a two year certificate. Any longer than 2 years are not recommended given the rate of change in certificate standards, and that it's generally good practice to renew.
• The CA you are buying from. Different CAs charge different amounts and market forces don't seem to be pushing them all to the same price as you would think they should. They will argue that they provide better customer service, and online reviews of CAs do seem to show this to be the case.

So, for personal sites, I think the free cert providers are fine and I don't really see the point of paying extra for a certificate, unless there are any features (like wildcard certs or Certificate Transparency) that you need. For companies, the support given by the CA will come into play more and you probably do want to spend the money on getting a certificate who will give you the support you need if you need a certificate reissued quickly, even if in the middle of the night for some reason. Additionally you would hope that larger CAs will be less likely to be compromised (though the recent Symantec issue means we might have to re-evaluate that!). When a CA is compromised for a single certificate, that can be bad news for anyone else with certificates from that CA as browsers may revoke the issuing certificate that your website uses meaning you have to get a new certificate and may be blocking users until then. For a blog this may not be such a big deal, but businesses should not take that risk. Additionally EV certificates provide a further trust message to the users, but at a price so again larger companies may see this as a good investment.

Once you have decided which certificate you will be buying, and from who, you usually need to create a private key, and a certificate request (CSR) file. This includes all the details of the certificate you are asking for (the domain name this is for, and details of your company or you). A key and csr is generated, typically by using openssl with a command like that below:

The CA will then sign this CSR (after doing the appropriate validation depending on the certificate type) and send back a certificate in one of a number of formats which will typically end in .cer, .crt or .p7b. You need need to configure the private key and certificate on your web server. The exact method to do this will depend on your web server but in Apache would look something like adding this config to your web server:

If that all works, then you should be able to browser your website at the https:// address and hopefully get a green padlock. However there are a few settings you can use to configure HTTPS and if this is not done correctly, you might be using old encryption that's actually fairly easy to break. So it's important to review your HTTPS config.

So setting up HTTPS involves a few decisions on your cert provider and perhaps spending some money, but once you get over that, that it's actually not that difficult to set up. However this will use the default configuration from the web server, and often those settings are not the ones you should be using. You might argue that web servers should change their defaults, but that's a slow process as they don't like breaking their customer's websites. The easiest way to do this is to check your HTTPS setup is to use the SSL Labs SSL Server Test tool. This will check various configurations flagging any insecure settings. They even publish a free SSL/TLS Deployment Best Practices document which will help explain any of the problems. Unless you are running old hardware or software (in which case why are you not upgrading?), it's actually quite easy to get an A rating with a bit of configuration, or an A+ if you enable HSTS, so any less should be seen as a compromise.

Some of the settings you need to consider are:

1. Turning off SSLv2 and SSLv3. These are old protocols that have been shown to be insecure and you should be using TLS instead. Additionally TLSv1.0 and TLSv1.1 are also being phased out and only TLSv1.2 and the fairly new TLSv1.3 should be used for now.
2. Set up the ciphers you want to use. Some encryption ciphers are faster than others, and some are more secure than others so you need to tell your web server which encryption ciphers you want to use.
3. Ensure the ciphers are used in the order your web server specifies. You will probably have older ciphers in there to support older browsers, but you don't want newer browsers to use them as they will be slower or less secure. So insist on using the order you specify so each browser will use the best cipher it can support.
4. Turn off SSL Compression which has a very small performance benefit but at the cost of a security issue.

Ensuring you have good HTTPS configuration is important for many reasons. Obviously it's more secure, but it also future proofs your site. Most issues with HTTPS are found on older settings and ciphers, and those are the ones that browsers then start to retire. By ensuring you have the top rated security, it is less likely your site will lose the green padlock in some browsers when the next security issue is discovered. Off course you should check your SSL configuration periodically (I recommend quarterly at least), but by having excellent configuration from the on set, you will likely have longer to make any changes that are necessary for the future.

There are performance implications with setting up HTTPS. Initially there was lots of concern with the impact on the web server of encrypting and decrypting traffic, but that has largely fallen to the wayside with the continuing improvements of computers and quicker encryption ciphers. Even the most basic smart phones can handle the performance impact of this without noticing any issues. So unless you are running a major video streaming service like Netflixs (who by the way published a very interesting piece on Optimizing TLS for High–Bandwidth Applications if you really want to get into the detail!), it is unlikely the performance costs of encryption will affect you.

What will impact you is the performance cost of setting up HTTPS initially. Setting up HTTPS involves a complicated back and forth between the web browser and web server to agree on what encryption to use. This can add up to half a second to a typical website download. With performance being key to websites and a two second best practice on loading your website, a half second delay is significant. There are ways to boast the performance of this, but fundamentally it's a problem that's difficult to solve due to the fact that it's the latency of those back and forth messages that are a problem and that is fundamentally limited by the physical world. On the plus side, there are ways of setting up your HTTPS correctly so only that first connection suffers and after that performance impact is negligible.

On a similar note, most users will use your website without the protocol (so www.tunetheweb.com instead of https://www.tunetheweb.com), and that will default to http:// so you will often want to redirect this to https:// which again costs a few milliseconds. This can be remediated with the HSTS setting.

Some of the main settings you will want to set up include for performance reasons include:

1. Set up session resumption, to allow connections to previous HTTPS settings - see also Keep-Alive page to see the impact of not allowing session resumption, however do be aware that there are some security implications of session resumption, but I still recommend turning this on despite those concerns.
2. Set up OCSP stapling so that certificate validation information is sent with your initial connection, saving the browser contacting your CA to check the validity of your certificate.
3. Set up HSTS which can prevent the initial redirect cost.

Again I have included the Apache configuration tunetheweb.com uses below (I've not included HSTS setting here as think that requires some extra thought first):

Once you have set up your HTTPS, you may wish to look at further options, such as HSTS, HPKP and/or Certificate Transparency which aim to take HTTPS to the next level, but do be aware that there are significant downsides to some of these technologies and they should not be implemented without fully understanding them and the risks associated with them.

All major web servers and web browsers support HTTPS. Later browsers support (and sometimes demand!) that your HTTPS setup is kept up to date, by not showing the green certificate if you are using old SHA1 certificates, rather than newer SHA256 certificates, or if you have a EV certificate without Certificate Transparency.

The three main downsides are costs, performance issues and the complications is setting up and maintaining your HTTPS set up.

1. Cost

   Troy Hunt has a very good post on how We’re struggling to get traction with SSL because it’s still a “premium service”, which got into the cost implications. While those running their own servers can get cheap (or even free) certificates easily, anyone using hosted servers will not have that luxury. Bloggers and the small businesses may not want to pay for their online presence at all and, while they may not really need HTTPS (at least initially) it will put them at a disadvantage to other sites. The EV certificates, while adding some much needed checks, are seen as prohibitively expensive for smaller business and many users do not see the difference and a green padlock, is a green padlock to them.

2. Performance impact

   There are performance impacts to using HTTPS as discussed above. Most of the issues with the cost of encryption and decryption are overblown in this day of faster servers and computers and will not be an issue for most sites, but the initial setup for the first HTTPS connection will impact your site performance by as much as half a second. In my view this performance hit is worth the added security that HTTPS gives you, but there is no denying there is an impact. Properly setting up your HTTPS configuration will reduce this and once your initial site is loaded, browsing around it should not any noticeable performance impact, but that all important first page load will be impacted.

3. Complexity

   Setting up HTTPS is too hard. It involves running openssl commands, buying certs, installing certs, checking your set up and hoping you don't break your website in the meantime. You need to go through the whole thing again each year. Additionally you need to keep up to speed on any changes in HTTPS technology and ensure your browser won't suddenly stop accepting your certificate or HTTPS setup. Most CAs will provide advice and help and inform you if certificates changes are something you need to know about and initiatives like LetsEncrypt aim to automate this for the less experienced but there is no doubt it currently does take some expertise. The best tool to check your HTTPS configuration is the SSL Labs SSL Server Test tool which makes checking your set up easy and quickly highlights any issues. Now if you have any issues that might take some time to understand and investigate but, once you set up to get an A grade here, and run your website through that at least once a quarter and you should be pretty confident that you'll be able to stay on top of any major changes in HTTPS configuration that you need to be aware of.

There are also a few lesser issues. Older browsers may not support the latest HTTPS technologies, so on one hand you have the browsers pushing us to use the newer technologies and on the other you might have a significant amount of traffic still using older versions of browsers that do not support the newer technologies. In most cases you can configure both old and new ciphers to support both old and new browsers but, at some point, you will want to turn off the old, insecure methods to stay secure and that will have block older users.

There are also implications involved in mixing some HTTP content and HTTPS. In the past, many websites had the main sites on HTTP, and then switched to HTTPS for secure parts of the site (e.g. in login areas, or checkout processes where personal and payment details are taken). This is generally considered bad practice nowadays (which is not to say that lots of sites don't still do this - I'm looking at you here Amazon for example!), for a number of reasons including: your customers then need to constantly check if a padlock exists any time they use your site for secure pieces, cookies by default do not differentiate by protocol so will any cookies set up over HTTPS will also be sent over HTTP if you switch back to that (though there are ways to secure your cookies), mixed content (e.g. if you load an image from another site over HTTP), causes security issues and most browsers will throw up alerts or remove the green padlock with this happens, SEO may need extra set up to have what is essentially two sites...etc. I would recommend to have the whole site on HTTPS.

And finally there are implications on moving a site from HTTP to HTTPS. Like any major site change, you do need to take care with this as, in worst case, this may result in broken links, loss of Google ranking though all of those can be avoided with a little careful planning. To me this is another reason that new sites should start with HTTPS to avoid any future work in migrating.

Adding HTTPS to your site, is one of the main ways you can secure your site. Using HTTPS is a well recognised and trusted way by most web browsers and web surfers (even if they don't always understand the technical details of why). It will add confidence to your visitors, and is starting to be taken into consideration by companies like Google as a way to rate whether to recommend your site. You may argue that your website doesn't have any private data (perhaps it's a simple blog for example), and implementing HTTPS is unnecessary. That may be the case, but it doesn't alter the fact that the internet as a whole is moving towards HTTPS and there is an expectation of HTTPS for sites nowadays. You can either embrace that trend and be ahead of the game, or fight it as long as you can. As mentioned above, putting this off, can also make any future migration to HTTPS more difficult.

If you are taking any personal details, including user name, password, name, address details or even a contact us or feedback form and particularly payment details then you must implement HTTPS. If you do not then you are putting that data at risk, and may be in breach of local regulations. Again you might argue that the data is not that important, but that is not your call to make. Despite not being what they should do, users often reuse passwords across websites and if you're little, unimportant, website leaks password data then you are letting the whole internet down by doing this and it is not just related to your website.

There are undoubtedly performance implications of moving to HTTPS, mostly for the initial connection (if your HTTPS set up is correct) each time your visitors start browsing on your site and performance is key to running a website but this is one of the few times where the performance hit is outweighed by the security benefits in my opinion.

This page was originally created on 09-Aug-2015 and last edited on 28-Jun-2022.