What is a TLS certificate?

TLS stands for transport layer security and is a protocol that will allow a client and a server to communicate with each other securely. A TLS certificate or a digital certificate is a certificate to be used with the TLS protocol. One thing to note is the certificate is independent of the protocol. A digital certificate can be used with either protocol, which can be set by the server.

What’s in a digital certificate?

A digital certificate allows the server to authenticate itself to the client and would allow the client and server to communicate securely with one another. An X509 certificate would need to contain the following properties:

  • The host name
  • A public key provided by the Host
  • A digital signature to certify the certificate is valid, usually provided by a CA

These three properties at the bare minimum, would allow the server and the client to then communicate securely with one another.

TLS is a protocol that uses both asymmetric as well as symmetric keys for encryption. Asymmetric keys or public key cryptography uses one key for encryption and another for decryption. Symmetric keys will use the same key for both encryption and decryption. Asymmetric keys are used in the initial handshake to allow the client and server to send symmetric keys to share. Asymmetric keys are usually slower than symmetric keys (in the order of milliseconds) and is only used for the initial handshake request.

What’s a CA?

A CA stands for certification authority and it’s essentially an organization that’s trusted worldwide to certify digital certificates. There are a handful worldwide and they’re responsible for ensuring the TLS certificates that we use with websites are valid and can be trusted. Websites would need to register with CA’s to get a TLS certificate that would be trusted by modern browsers. A CA would need to pass stringent tests in order to be trusted by modern browsers such as Chrome, Mozilla, Safari, and Edge.

So how does it all work?

Let’s say a user is accessing a web page, https://www.example.com on their browser. How does the browser communicate to the server that it wants to connect securely? Prior to downloading the web page and executing the request, a process called a handshake is done between the browser and the server. This handshake would dictate the algorithm to be used between the server and the browser that would allow the connection to be secured.

  1. The browser sends a ClientHello message to the server in HTTP (80) telling the server that it wishes to connect to the server in a secure manner. In TLS 1.3, the client also sends the key share which will be used by the server to create a symmetric key that will be used between the two of them.
  2. The server responds with a ServerHello with the digital certificate attached to the response. The server also creates a public/private key and sends the public key along with a key share to the client. The public key and key share will be used by the client to create a symmetric key.
  3. The client then verifies that the digital certificate is correct, by checking with a CA and then uses the key share provided by the server to create a symmetric key to be used.

After the three steps above, the server would have the following:

  • The server’s private key
  • The client’s public key
  • The client’s key share
  • The server’s key share

With these 4 pieces of information, it is able to generate the symmetric key.

The clients would have similar data:

  • The client’s private key
  • The server’s public key
  • The client’s key share
  • The server’s key share

These pieces of information that the client has will allow it to generate a symmetric key which can be used to encrypt/decrypt data sent and provided by the server.

In prior versions, TLS 1.2, there would be more round trips and it would take longer for the handshake to be completed. Instead of the client sending its public key as well as the key share in the first hello, it waits for a response from the server. In addition, there were many more options in terms of cypher suites for the server/client to choose from in TLS 1.2. However, these options can be outdated and in TLS 1.3, they are mostly removed and only a few options are left.

Keypoints to focus on

TLS 1.3 is faster than TLS 1.2 as there are fewer round trips to be made when a client does a TLS1.3 handshake. Asymmetric keys take longer for encryption and decryption and is not used outside of the initial handshake protocol. Symmetric keys are favoured since it’s faster and as long as the keys are provided between the server and client in a secure fashion, would not be broken. Hence, TLS 1.3 uses both asymmetric keys to share symmetric keys between the clients and the server.

References

Cloudflare TLS 1.3 Explained Cloudflare TLS 1.3