Anyone who has deployed SSL/TLS without using the newly launched Let’s Encrypt knows what a tedious process that was. Roughly, the steps to follow are:
- generate keys
- generate a Certificate Signing Request (CSR)
- submit it to a Certificate Authority (CA)
- shovel some cash their way
- download the certificate
- complete the certificate chain
- install the certificate into your service and enable SSL/TLS
And yet we wonder why so little services actually use SSL/TLS to protect their content in transit?
Fortunately, with the launch of Let’s Encrypt, all of this hassle goes away. Let’s Encrypt is an open CA, run by a public benefit organization, backed by numerous important industry players. More importantly, Let’s Encrypt offers free certificates for everyone, and has automated the process of issuing, revoking and renewing certificates. Once you have cloned the git repository containing the Let’s Encrypt tools, you can replace the 7 steps above by a single step if you’re running an Apache Web server, or two steps if you’re running something else. I have tried it out, and have only one word to say: awesome!
This post is not going into further detail on how to deploy Let’s Encrypt, which is already covered by the documentation, the excellent guides by Digital Ocean for Apache or Nginx, or by Scott Helme who describes a more elaborate setup with an ACME client.
We will however take a look at what you actually get from Let’s Encrypt, and if these freebie certificates can actually measure themselves with their expensive counterparts from other CAs. Is Let’s Encrypt’s free lunch for real?
Why do you need a certificate at all?
Under the hood, the SSL and TLS protocols depend on cryptographic primitives to ensure three important security properties: (1) data confidentiality, (2) data integrity and (3) entity authentication. Essentially, what this boils down to is that the data will be encrypted before it’s transmitted (confidentiality), and that an HMAC will be added to the data to verify its integrity once received (integrity). These two properties rely on cryptographic algorithms (e.g. the AES cipher for encryption and the SHA256 HMAC function for integrity), which in turn depend on a shared secret known by both parties. Negotiating these algorithms and secrets is done during the establishment of an SSL/TLS connection, which is actually a straightforward process.
The third security property, entity authentication, allows one party to verify the identity of the other party, which is actually a bit more tricky. For example, when you establish an HTTPS connection to
websec.be, how do you know that you’re talking to this server, and not to an attacker intercepting the traffic? The browser would have to know the server’s public key in advance to be able to verify the key used to establish the connection. While this is viable in a closed environment, it is highly impractical on the Web, with millions of servers and billions of clients. This is where certificates come into play.
When deploying SSL/TLS, for example on
https://websec.be, the server administrator asks a Certificate Authority to vouch that a specific public key (and its corresponding private key) are associated with a specific domain. This information is encoded in a certificate signed by the CA, which is installed on the server, and sent to the browser when a new connection is established. Of course, now the browser needs to find a way to verify the validity of the certificate. If the browser would know the public key of the CA, verification of the certificate would be easy, but again, this is still too impractical. In reality, there is a hierarchy of CAs, where the intermediate CAs have a certificate signed by a higher-level CA, all the way up to the highest level, also known as a root CA (see image below). The number of root CAs is rather limited, so here it becomes manageable to actually hardcode their keys in various systems, such as operating systems and browsers.
The relation between Root CAs, Intermediate CAs and Web servers. Note that browsers and operating systems come with about 150 to 200 CAs.
So, whenever an HTTPS connection is established, the browser verifies whether the domain name and key used by the server actually match those in the certificate, signed by the CA. Additionally, the browser also checks the validity of the keys of every intermediate CA, until it reaches one of the root CAs, which are trusted by default. If any of these steps fail, the browser will abort the connection and show a scary warning, such as the one shown below, because the security properties of the SSL/TLS connection can no longer be guaranteed.
Since certificates are really important for establishing an SSL/TLS connection, we surely cannot trust free certificates, right? Let’s see …
An SSL/TLS error message, caused by an invalid certificate
The secret lies in the validation process
The whole certificate system used by SSL/TLS depends on the assumption that only the administrator of
websec.be can obtain a valid certificate, and nobody else. That’s why a CA is expected to perform certain identity checks before issuing a certificate. In general, this assumption still holds today. There have been unfortunate cases where certificates have been issued to the wrong people, but these instances are fairly uncommon. For more information on the history and disadvantages of the whole CA system, check out this entertaining talk by Moxie Marlinspike.
So, what does this validation process entail? Do you have to jump through various hoops to prove that you control a domain, before you can get a certificate? Well, that depends on how much you want to pay for that … In general, we can observe three levels of validation:
- Domain Validation: the simplest form of validation, where you have to show that you control certain properties of the domain. Most common is having control over a restricted email address, such as
email@example.com. If you can access these addresses, one can assume that you actually have full control over the domain, and that you are allowed to request a domain-validated certificate as well.
- Organization Validation: some CAs offer a more elaborate validation process, where they will look into your organization, for example to see whether it actually exists. This level of validation is not so common, and there are no guidelines about how far this validation needs to go.
- Extended Validation: the extended validation process is offered to businesses by almost every CA, and the checks that need to be done are fairly extensive. The list of checks includes the name of your business, the location, its registration information, the right to use the domain name you’re requesting a certificate for, … If you pass these validation checks, you receive an EV Certificate, also known as an Extended Validation Certificate.
- Self-Signed Certificates: technically, there’s a fourth level, which is no validation at all, as seen in self-signed certificates. You can generate these yourself, sign them yourself, without the involvement of a CA. Of course, this implies that unless you install your key in the browser, the certificate will not be validated correctly.
Most common are domain validation and extended validation, so let’s focus on these two. If you deploy HTTPS with a domain-validated certificate, the browser will be quite happy. Depending on which browser you have, it decorates the address bar with a nice lock icon, maybe some green colors here and there (shown below on the left). With an EV certificate however, you get the full package, including the name of your organization in the address bar (shown below on the right). The price for a simple lock lies somewhere between € 0 and € 350, while the fancy UI of an EV certificate sets you back € 900.
The browser UI for a domain-validated certificate (left) and an Extended Validation certificate (right)
This brings me to a rather inconvenient truth about the validation process: the only differences between domain validation and extended validation are the price and the browser UI. Extended validation tells the browser, and thus your users, that someone has really made sure that the certificate is issued to the right organization. Extended validation gives more confidence in the identity of the server, but it has absolutely no influence on the cryptographic strength of the SSL/TLS connection. On the technical level, the connection will not be more secure because you have obtained an EV certificate. Psychologically however, if you’re a bank, your users may appreciate the fact that the name of the bank is shown in the address bar, and they can be taught to be cautious when it’s not there.
So, how about Let’s Encrypt certificates?
Let’s Encrypt applies a domain validation process before issuing certificates. By default, Let’s Encrypt verifies whether the person requesting the certificate has administrative control over the Web server, which enables the full automation of the process. However, email-based domain validation is also available if desired. Therefore, it is safe to say that the certificates offered by Let’s Encrypt can be considered equally good as other domain-validated certificates, for which CAs charge up to € 350 per year (This implies that you have some spare money to buy the Let’s Encrypt folks a Belgian beer!).
From a personal perspective, I think it’s great that SSL/TLS certificates are now widely available for free (even though you could already get free certificates at for example StartCom). However, the true game changer is the automation of the entire process, eliminating the need to manually go through the steps listed at the start of this post.
So to conclude, the Let’s Encrypt initiative is a very welcome ally in the push for HTTPS everywhere. Let’s Encrypt takes away a lot of the hassle that comes with manually requesting a certificate, and the issued certificates offer the same guarantees as domain-validated certificates issued by any other CA.