Understanding TLS web security protocols and certificates

You may have come across acronyms like HTTPS, TLS, SSL, SSL certificates. If you are still unsure about some of these, this guide is here to help.

What are network security protocols?

Security protocols are formal standards that define how computers should securely communicate over the network. On the web these protocols ensure that the connection is protected from illegitimate attempts to expose data that is exchanged between computers. Some of the most commonly used ones on the web are HTTPS, TLS and SSL.

Let's start with SSL.

SSL (Secure Socket Layer)

Netscape developed and released SSL in 1995 as version 2.0 (1.0 had never been publicly released). In 1996, they released version 3.0 that fixed a number of vulnerabilities. Both versions of SSL (2.0 and 3.0) have since been deprecated as more issues were discovered (some of the most famous ones are POODLE and DROWN).

TLS (Transport Layer Security)

IETF (Internet Engineering Task Force) released TLS in 1999. They based this protocol on SSL 3.0 but changed it significantly.

In 2019 TLS is the industry standard. The latest version of the protocol is 1.3 so if you are still using an older version it might be time to upgrade. Also if you are still using SSL you need to disable it on your servers and switch over to TLS.

Example (Nginx settings):

# SSL should be disabled
ssl_protocols SSLv2 SSLv3;

# should be using TLS instead
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

You can also use SSL Server Test to check what protocol your site supports.

HTTPS (Hypertext Transfer Protocol Secure)

HTTPS is just a standard HTTP protocol served over a TLS layer. Computers still communicate HTTP to each other but over a secure connection, where everything is encrypted. Whenever you see a green padlock in the address bar that means that the connection is encrypted and it is being served via HTTPS.

Certificates

As a developer, you might have purchased SSL certificates in the past to reassure the visitors that they are safe. The industry has been using this term for a while now but the real meaning behind SSL certificates is a bit different. It is important to understand that SSL/TSL certificates are not dependent on SSL/TLS settings. As a matter of fact, these are just certificates to use with SSL/TLS protocols. Protocols are determined by the server, not by the certificate.

Certificates are used to establish an encrypted connection and are stored on a server. In order to install one, you would first need to go through a process of obtaining it. Certificates are digitally signed by a third party authority - Certificate Authority (or simply CA). Some of the most known ones are Symantec, GoDaddy and GlobalSign. The CA first needs to look up and verify details of the company. Then if all is well, the CA will create a certificate, sign and send it over to you.

Example (Nginx settings):

# Configuring certificates, we will discuss these in a bit
ssl_certificate /path/to/your/certificate.crt;
ssl_certificate_key /path/to/your/private.key;

Handshake (TLS handshake)

A handshake is a process that allows parties to verify each other’s identities and establish a secure connection. The process kicks off whenever we make a request to a website or an API. There are a number of steps in this process.

1) The client sends a hello message to begin establishing a connection with a server. As part of this message, the client sends versions of TLS/SSL protocols and cipher (an algorithm that for performing encryption/decryption) that it supports. The server’s cipher suite (a set of algorithms) needs to be sorted and configured based on what the client supports. The client also generates a random string known as client random which is sent in the message. This will be used in the future to compute the master secret key which will be then used to calculate the encryption keys.

Example (Nginx settings):

# Configure ciphers
ssl_ciphers 'ciphers go here';

#  Use server's cipher suite over the client's one
# Cypher suite helps secure the connection by using a set of algorithms
ssl_prefer_server_ciphers on;

2) The server sends a hello message alongside the certificate to the client. The certificate includes valid from and to dates, serial number and most importantly the public key. Additionally, the server also creates a random string called “server random” and sends it to the client.

2a) If the server needs a digital certificate for client authentication, it also sends a request for one.

3) The client needs to verify the identity of the server. It obtains a public key from the certificate.

The client verifies the certificate’s digital signature and makes sure that it is valid. When this happens, you will see a green padlock icon in the browser. It means that the web server’s public key really belongs to the server.

4) The client creates another secret key and encrypts it in the server’s public key. The client sends the encrypted secret back to the server. Both parties work out a master secret key that uses client and server secrets to do this. This master secret key will be used from now on to ensure encrypted communication.

4a) If the server had requested the client’s digital certificate, the client creates a secret, encrypts it in the client’s private key together with the client’s digital certificate or no certificate alert.

5) The client sends a message to the server indicating that the client part of the handshake is complete and that it wants to change to the cipher spec previously agreed in steps 1 and 2.

6) If no certificate alert exists and implementation is in place, the handshake fails.

6a) If the server requested the client’s certificate it verifies it.

6b) The server uses its private key to decrypt the secret.

7) The server sends a message to the client indicating that the server part of the handshake is complete.

8) The client and the server can now use the encrypted connection to exchange messages.

Chain of trust

How do browsers know who to trust? All major CA provide certificates to web browsers. This enables them to check the authenticity of the certificates installed on the server.

The infrastructure behind CA can be quite complex. In reality, certificates do not get directly signed by the root CA. Root CA is normally made up of a number of CAs. This creates a hierarchy/chain of trust with the root CA being at the top of the pyramid. The CAs between the root and the end entity are there to define and authorise the certificates. These are called intermediate/subordinate CAs.

Root CAs do not issue end-entity certificates directly off the root certificate. Instead, root CAs issue certificates to intermediate CAs and usually are taken offline afterwards. The reason for this is that if a root certificate gets revoked all of the issued certificates will be distrusted. Intermediate CAs can then issue certificates to end entities.

Self-signed certificate

There is normally a cost associated with certificates. There are companies that offer certificates for free. These certificates are perfectly fine. However, if you are running a commercial website it is better to go with a paid option that normally contains additional support, a higher level of owner verification and warranty.

You can also easily generate a certificate on your machine. You as the issuer sign this certificate. There are tools available that can do this, for example, OpenSSL.

The downside of a self-signed certificate is that you will never see the green padlock in the address bar which is not a good experience for the end user. However, self-signed certificates are just as secure as the certificates issued by a trusted third party CA. By secure, I mean that the connection will be encrypted. If we distribute the self-signed certificate to the browsers it will be as good as the one trusted by the CA.

Formats

Finally, let’s have a look at the different certificate formats.

.pem

One of the most common certificate file formats is .pem (privacy-enhanced mail). You will normally receive this from a CA. It is supported on many different platforms and applications.

.p12 (PKCS 12 – Public Key Cryptography Standards)

.p12 format can contain many certificates inside. Also, it is often used to store private and public keys and can be password protected.

.crt

.crt is the encoded format used to store the signed certificate.

.key

.key is the private key to the certificate.

I have tried to cover some of the basics in this post to get you going and hope that this was helpful.