The nine key concepts of TLS
Introduction
TLS, MTLS, SSL, Certificates, CAs, PCKS files, PEM files, Cert chains, Ciphers, Public Keys, Session Keys, SSH,... the list goes on. If you find yourself bewildered when you encounter these words and acronyms, then this guide is for you.
You might have tried to learn TLS before, finding online articles that contain analogies that involve giving someone a key to a locked box with a message inside. These analogies are great for understanding the basic concepts, but when it comes to working with TLS things quickly gets a lot more complicated.
First concept - TLS
It's all TLS.
TLS stands for Transport Security Layer. SSL (Secure Sockets Layer) is the predecessor of TLS, but the SSL acronym is often still used instead of TLS. All the words and acronyms that are listed in the introduction above are part of TLS.
Second concept - Public/Private key encryption
This concept is the classic locked box analogy that you might already be familiar with:
You're the server, and you want to communicate privately with a client. You first send them your public key. Next, you send them your encrypted message. The client uses your public key to decrypt the message. The client then uses your public key to encrypt their message to you, but ONLY your private key can decrypt this message.
The question that I first asked myself after I encountered the above explanation was "But hang on. This means anyone with the public key who is sniffing the network can see what the server sends you, even though they can't see what you send back (unless they also have the private key), this is only one-way security." See the next section for the answer to this question.
Third concept - Handshaking and session keys (also known as symmetric keys)
The public and private keys are used only at the beginning of the communication session, in an exchange known as TLS Handshaking. The client generates a random number, which it encrypts with the server's public key and sends back to the server. Only the server can decrypt this message by using its private key, and this random number is then used to generate new keys that are used for the remainder of the communication - these new keys are known as session keys. New session keys are created when a new communication session is initiated. Session keys have an expiry, and if they do expire during a long session then TLS Handshaking is repeated to generate new keys.
Note: There are more sophisticated handshaking methods that can provide what is known as 'forward-secrecy', which prevents a hacker who has the public and private keys from being able to decrypt a capture of the communication session. Discussion of forward-secrecy is beyond the scope of this article.
Fourth concept - Cipher suites
During the TLS Handshaking, the client and server must agree on what cipher suite to use. A cipher is an encryption algorithm, and multiple ciphers are used during handshaking - hence the collective term 'cipher suite'. The client sends the server the list of cipher suites that it supports, and the server picks one to use. It is possible that the server does not support any of the cipher suites that the client supports, in which case TLS Handshaking fails. The cipher suites are used in the generation of the session keys.
What do I really need to know here?
- The client and server need to have at least one common cipher suite that they both support.
- The client and server require regular updates of their supported cipher suites. Vulnerabilities are discovered in old cipher suites, and new cipher suites are created.
Fifth concept - Certificates and Certificate Authorities (CAs)
When we talk about the server 'sending its public key to the client', what the server is actually doing is sending its certificate (which contains the public key among other things) to the client. This is why the terms certificates and keys are often mixed up. The certificate is how the server identifies itself as trustworthy.
A certificate is just your public key that has been signed by a certificate authority so that anyone who trusts the certificate authority can cryptographically validate and trust that it is really your public key.
How does an organisation get a certificate for their server? Two options are available:
1. The organisation buys one from a Certificate Authority (CA).
2. The organisation self-certifies, by using what are called self-signed certificates.
If you want to buy a certificate from a CA, then you must confirm that you are who you say you are. Some CAs are more reputable than others and some clients might trust only certificates from particular CAs. Two types of certificates can be issued: Domain Validated Certificates (DVC) or Extended Validation Certificates (EVC), the former are usually cheaper and quicker to get, but less trusted then the 'Extended Validation' ones (which as the name suggests involve extra validation of the owner)
Self-signed certificates are typically used internally. For example, when the client and server are in the same organisation.
When the client receives the server's certificate, it validates the certificate against a list of trusted CAs, and if not trusted then TLS handshaking fails and the client sees an error about an untrusted certificate.
Certificates usually contain the following information:
Subject domain name (The 'subject' basically means the certificate's owner)
Subject organisation
Additional or alternative subject domain names, including subdomains (if any).
Name of issuing CA
Issue date
Expiry date
Public key
Digital signature by the CA - the CA uses its private key to create this, proving that the certificate came from this CA.
The client checks the above properties during TLS handshaking.
Certificate types and terminology:
Sixth concept - Certificate chains
When you buy a certificate from a CA, what you actually get is a chain of certificates that go back to what is called a Root Certificate.
Root Certificate
Intermediate Certificate also known as CA certificate
My Server Certificate also known as end-entity/leaf certificate
Each certificate in the chain is signed by the private key of its parent certificate until the Root Certificate is reached. The client validates each certificate in the chain, up to and including the root. The reason for certificate chains is for added security. To sign new child certificates the root certificate's private key would need to be loaded in a running computer somewhere, and so would be vulnerable to hackers. If the root certificate private key is compromised, then all the certificates it issued are also compromised. For this reason Root Certificates are old and long-lived, and intermediate certificates are used to sign new certificates.
Intermediate certificates are also called CA certificates, since these belong to a Certificate Authority and can sign new certificates. The bottom certificate in the hierarchy is usually referred to as the end-entity certificate or leaf certificate, and unlike all its ancestor certificates, it cannot sign new certificates.
Seventh concept - Keystores and truststores
Keystore
Your keystore is the place that you store your certificate (which contains your public key). This certificate is the one that you send to any clients who want to connect. The keystore also contains your private key (which signs your certificate). Since it has your private key, your keystore must be secure!
Truststore
Your truststore is where you store the certificates from CAs that you trust. As a client, you use truststores to validate the certificates of any servers that you connect to. No private keys are stored in the truststore, so it can be kept less secure than your keystore.
Eighth concept - Mutual TLS
In the previous sections we just talked about the client validating the server's certificate, and the server then trusting the client. This one-way validation might be fine for nonsensitive information, or if the client is authenticated by other means such as a username and password. But for additional security the client can present their certificate to the server, for the server to validate in the same way as the client validates the server's certificate.
Ninth concept - File types
Working with TLS you are likely encounter various file types with different extensions (or some with no extension at all). Below are descriptions of the common ones:
- .pem - PEM files
These are container files that can wrap many of the other file types that are described here. It can be as simple as just storing a public key. They are made up of sections that always start with the line that describes what that section contains:
-----BEGIN <type>-----
Where <type> might be PRIVATE KEY, PUBLIC KEY, CERTIFICATE,...
If the PEM file contains just a certificate it might have the extension of .crt, .cert, or .cer. PEM files are Base64 encoded.
- .csr - Certificate Signing Request
This file is used to request a certificate from a CA. The csr file contains information about the requester such as their public key, domain, and address. CSRs are usually wrapped in PEM format (see above), and so might have the .pem file extension.
- .key - Private Key File
A PEM formatted file that contains just a private key.
- .pkcs12 - A password protected file, also known as .pfx, .p12
These contain a certificate and private key, and are in an encrypted binary format.
Summary
There is still far more to learn about TLS, but the basic concepts that are covered here should give the nonsecurity specialist the background understanding that is needed for configuring TLS in IBM products such as API Connect.
Thank you to my colleague and security specialist Simon Kapadia for his valuable assistance in reviewing this article.