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 feeling bewildered when encountering these words and acronyms, then this guide is for you.
You may have tried to get your head round it all before, finding nicely written wiki pages online that contain analogies involving giving someone a key to a locked box with a message inside, and these are great for understanding the basic concepts, but when it comes to actually working with TLS it quickly gets a lot more complicated.
First concept - TLS
It's all TLS.
TLS stands for Transport Security Layer. SSL (Secure Sockets Layer) was its predecessor and this acronym is unfortunately still often used where TLS should be. All the other words and acronyms listed at the start of the above introduction are part of TLS.
Second concept - Public/Private key encryption
This is the classic locked box analogy you may already be familiar with, but here it is again and as concise as possible:
You're the server, and you want to communicate privately with a client. You first send them your public key, you then send them your encrypted message, which they need the public key to decrypt. They use this same public key to encrypt the data they send you, but ONLY your private key can decrypt this.
Hang on! This means anyone with the public key sniffing the network can see what the server sends you, even though they can't see what you send back unless they have also got hold of the private key, this is only one-way security! See the next section for the answer to this.
Third concept - Handshaking and Session Keys aka Symmetric Keys
The public and private keys are just used 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 using its private key, and this random number is then used to generate new keys that will be used for the remainder of the communication - these are known as session keys, and new ones are created when a new communication session is initiated. Session keys also have an expiry, and if they do expire during a long session then TLS Handshaking is repeated to generate new ones.
Note that 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 session. Discussion of these is beyond the scope of this article.
Fourth concept - Cipher Suites
During the TLS Handshaking, the client and server have to 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 it supports, and the server picks one to use. It's possible that the server does not support any of the cipher suites that the client does, in which case TLS Handshaking will fail. The cipher suites are used in the generation of the session keys.
What do I really need to know here?
- Client and server need to have at least one common cipher suite that they both support.
- Supported Cipher Suites at client and server do need updating. Vulnerabilities are discovered in old ones, and new more secure ones are invented.
Fifth concept - Certificates and Certificate Authorities (CA)
When we talk about the server sending its public key to the client, what its 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 which has been signed by a certificate authority, so anyone trusting that certificate authority can cryptographically validate and trust that it's really your public key.
How does a server get a Certificate?
1. The organisation will buy one from a Certificate Authority.
2. The organisation will self-certify, using what are called self-signed certificates.
If buying a certificate from a CA, you need to confirm that you are who you say you are. Some CAs are more reputable than others, some clients may only trust 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 in non-public facing scenarios, where the client and server are in the same organisation for example.
When the client receives the server's certificate, it validates it against a list of trusted CAs, and if not trusted then handshaking will fail and the client will see an error about an untrusted cert.
Certificates usually contain the following:
Subject domain name (The 'subject' basically means the certificate's owner)
Subject organization
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 the certificate came from this CA.
The client will check these during handshaking.
Wildcard Certificates
This is where the Subject Domain Name of the certificate includes an * so it can be used to secure multiple sub-domains, e.g. *.acme.com
SAN - Subject Alternative Name Certificates
These certificates contain multiple names, allowing them to be used for multiple domains e.g. acme.com and example.com.
x.509
You may see the term x509 or x.509 used when referring to certificates. X.509 is the standard used to define TLS public certificates.
Sixth concept - Certificate Chains
When you buy a certificate from a CA, what you actually get is a chain of certificates going back to what is called a Root Certificate.
Root Certificate
Intermediate Certificate a.k.a CA certificate
My Server Certificate a.k.a. end-entity/leaf certificate
Each certificate in the chain is signed by the private key of the one above it, until you get to the Root Certificate. The client will validate 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 vulnerable to hackers. If the root certificate private key is compromised then all the certs it has issued are 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 is usually referred to as the end-entity certificate or leaf certificate, and unlike all those above it, it can't sign new certificates.
Seventh concept - Keystores and Truststores
Keystore
Your keystore is the place you store your Certificate (which contains your public key). This is the certificate you would 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 should be secure!
Truststore
Your truststore is where you store the Certificates from Certificate Authorities that you trust. As a client you will use these to validate the certificates of any servers you try to connect to. There are no private keys kept here, so less need to be kept secure.
Eighth concept - Mutual TLS
In the previous sections we just talked about the client validating the server's certificate, and the server just trusting the client. This might be ok for non-sensitive information or if the client is authenticated by other means such as username/password. But for additional security the client can present their certificate to the server and the server will validate it in the same way as the client validates the server's certificate.
Ninth concept - File Types
Working with TLS you will 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 described below. It can be as simple as just storing a public key. They are made up of sections that always start with the line describing what that section contains:
-----BEGIN <type>-----
Where <type> could 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, it contains information about the requester such as their public key, domain, address. These are usually wrapped in PEM format (see above), 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, aka .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 covered here should give the non-security specialist the background understanding 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 reviewing the above.