Encryption only one aspect of security
There’s much more to security than encryption - we’re going to be talking in this post most about encryption but don’t forget that there are lots of other technical issues that have a massive bearing on how secure your website is. For example, if you’re not up-to-date with security patches hackers can take advantage of known vulnerabilities to cause problems or steal information. Encrypting traffic to and from your website doesn’t really affect vulnerabilities like this – hackers would still be able to take advantage of any known vulnerabilities.
So why bother with encryption?
Encryption is really designed to tackle a different piece of the security jigsaw – it’s not designed to protect your server, it’s designed to tackle two other security problems:
- Privacy: How to stop a hacker from monitoring the communication between the server and the legitimate user?
- Identity: How does the user know that they are connected to the correct server rather than a site that might look identical but is in fact being controlled by a hacker?
But in additional to this, Google has stated that security is now treated as a ranking factor – the suggestion being that if your site is https:// it will rank more highly than it would otherwise. Real world experience suggests that the ranking factor is currently weak but that might change in the future [see Google article].
The primary technical components
Encryption and authentication used to be achieved with a technology called Secure Sockets Layer (SSL) but this is now entirely obsolete and has been replaced by Transport Layer Security (TLS). However, it’s perhaps worth noting that old browsers such as IE6 only support SSL and so won't work with modern secure sites.
TLS relies on an encryption technology known as RSA - an asymmetric encryption algorithm with two encryption keys, known as the “public key” and “private key”. If a message is encrypted using the public key it can only be decrypted back to the original message using the private key (and vice versa). The public key is therefore not secret and can be disclosed to anyone who needs to communicate securely with its owner. Obviously the private key needs to be kept secret.
Public Key Infrastructure (PKI) is the collection of technology, policies and procedures needed to prove the identity of a server (otherwise known as “authentication”).
Authentication is provided by organisations known as Certificate Authorities (CA). They use a technology known as a cryptographic message digest (sometimes known as a cryptographic hash) to create a digital signature for the public key used on a web site. This signature provides proof of ownership of a public key allowing you to confirm that the key user (the web site you are connecting to) belongs to the expected owner and not somebody attempting fraud.
The cryptographic message digests of choice is the SHA2 family (eg; SHA256). Other digests such as MD5 and SHA1 used to be very common but have since been found to have unfixable vulnerabilities so are not supported any more. Some old browser software (eg; old versions of IE on old versions of Microsoft Windows) don't support more modern digests such as SHA2 and don't work with modern secure sites.
What is a Certificate Authority and why you need one?
Every secure website needs to have a certificate. Generally this is unique to the site and has a limited lifetime, needing periodic renewal.
There are essentially three types of certificate. They are technically identical and vary only in the amount of checking the CA did before issuing them.
- Domain validated (DV): These are cheap or sometimes even free (although often with some limitations). They are the least trusted and all the CA will have done is use a simple, probably automated, process to confirm that the applicant has control of the domain in use. This is usually done in much the same way as Google does for Google Analytics, by requiring a specified file to be added to the root level of your website – your ability to do this proves to the CA that you should be trusted because you have control over the site.
- Organisation Validated (OV): These cost money - often quite a lot of money. The CA will require the applicant to provide details about themselves and the business they represent. The CA will then confirm these details by independent means and will usually make contact with at least one publicly identifiable person in the business to check that the application is legitimate. OV is probably the most common type of certificate used by businesses (eg; Amazon UK has one). Certificate Authorities issuing OV certificates often have some form of validation system (usually a logo that can be used on the site) which links back to them to provide confirmation of the certificate details (eg; Symantec Verisign have one known as 'site seal'). Where these are widely used and familiar with users - they can increase the perceived trustworthiness of the site.
- Extended Validation (EV): These tend to cost hundreds of pounds. The application process is similar to OV certificates, but the CA will perform more stringent checking and the CA itself has to pass an audit before it's allowed to issue them. Some businesses who want to make a point about trust and security use them (eg; Paypal) although some big players don't (eg; Amazon UK). The only obvious difference that somebody visiting your site will see if you have an EV certificate, is the URL bar turning green and displaying your business name next to the URL.
A certificate consists of a website's public key, some information about the site and the certificate, and a digital signature provided by the Certificate Authority (CA) that checked it was all legitimate. This is packaged up into a standard format known as X.509.
What does a certificate cost?
There are many Certificate Authorities but we work with Trustwave. Trustwave is a globally trusted brand for Internet security and compliance. Prices from $157.49 a year for Organisation Validation package, $233.10 a year for an Extended Validation package or $449.99 a year for Wildcard package that will validate many subdomains.
Implementation details
The steps we take for sites that are already hosted with us are shown below but you’d need to do something similar regardless of who was hositng your site.
- Convert the test site to TLS. The certificate used will be signed by our own in-house CA to avoid having to buy one just for testing.
- Check that the test site is still working correctly and that any tools/toys/widgets installed on the site have a working TLS version. For example, the site has to be converted to use the secure version of the code needed for Google Analytics.
- Apply for an OV certificate for the live site. The application is obviously in your name but includes technical details about the server so is something done by us.
- Since the certificate is Organisation Validated (OV) the Certificate Authority (CA) will verify the identity of the organisation (you may receive a phone call) - it normally takes a few days to complete the process.
- Once the OV certificate has been received by us:
- We set up the live TLS environment for the site
- Change the site status in the CMS from 'shared' to 'transition'. It will not be possible to login or edit the site on the standard platform from this point.
- We then update DNS your domain so that the A-record points to our secure TLS environment rather than the normal environment. It normally takes a few hours for this DNS change to propagate.
- Once DNS has propagated fully, we change our CMS so that the TLS status of the site becomes 'force'. From then on only the new TLS site will work - any requests made to the standard platform will get an error message (there shouldn't be any requests because the A-record has been changed).
- Once we're sure everything is OK and that the site is never going back, we turn on HSTS (Hypertext Strict Transport Security) on the live site [Wiki] - this is a security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking.
- Finally - we consider the use of HTTP public key pinning which is a mechanism designed to prevent impersonation [Wiki] - but this can only really be used if the owner of the website is technically sophisticated enough to appreciate the advantages and risks. It's very easy to 'shoot yourself in the foot' if you get this wrong.
PS:
If you are asked by one of our staff to access a site hosted on our test server you will need to import our CA certificate into your browser, otherwise they'll get error messages about the CA not being known. Our certificate is here: /conscious-ca.crt