My SSL/TLS Memo

In Software Architecture or Development, we always deal with TLS (formerly called SSL) for Security.

But as always, each time I have to work on that subject, I need to refresh my mind about how it works, at least from a high-level point of view.

SSL addresses these concerns:

• data encryption so no-one could intercept and read transmitted data between the data requestor and the data provider
• identification so the data requestor is sure that the data provider is the right one it claim to be (this is called one-way SSL)
• identification so the data provider is sure that the data requestor is the right one it claim to be (this is called two-ways SSL)

The main components used by SSL are the private keys and public keys.

I do not enter here into the details of these keys. The most important to keep in mind is that:

• the private key purpose is to decrypt data, and ONLY THAT
• the public key purpose is to encrypt data, and ONLY THAT

This little drawing shows that:

The above addresses the the data encryption concern.

To address the identification concerns, we need to get help from an external actor, i.e the Certificate Authority.

The role of the Certificate Authority is to guarantee that a given public key is the right one emitted by the data requestor or the data provider.

To do that, the Certificate Authority provides a Certificate containing the public key and a signature which ensures that the public key is the right one.

Little drawing illustrating that:

Now that we have all that stuff in mind, let's dive a bit into the TLS/SSL process.

See the following drawing and the explanations just below:

Here are the steps:

1. Client sends an Hello to Server
2. Server replies with its certificate (containing its public key and the signature)
3. Client verifies the certificate with the Certificate Authority
4. Client generates a session key and encrypts it using Server's public key (extracted from the Server's certificate)
5. Client sends the encrypted session key to Server
6. Server decrypts the session key using its private key
7. Server encrypts the clear data using the session key
8. Server sends the encrypted data to Client
9. Client decrypts the encrypted data using the session key

That's it! The steps above describe the one-way SSL: the Server identity (its certificate) has been controlled by the Certificate Authority at the Client level, but the Client identity has never been controlled.

That's the purpose of two-ways SSL where both Server and Client identities are verified.

See the drawing below:

Here are the steps (I highlighted the additional stuff related to two-ways SSL):

1. Client sends an Hello to Server
2. Server replies with its certificate (containing its public key and the signature)
3. Client verifies Server's certificate with the Certificate Authority
4. Client generates a session key and encrypts it using Server's public key (extracted from the Server's certificate)
5. Client sends the encrypted session key to Server and its certificate
6. Server verifies Client's certificate with the Certificate Authority
7. Server decrypts the session key using its private key
8. Server encrypts the clear data using the session key
9. Server sends the encrypted data to Client
10. Client decrypts the encrypted data using the session key

That's it! The Server identity (its certificate) has been controlled by the Certificate Authority at the Client level (step 3) AND the Client identity (its certificate) has been controlled by the Certificate Authority at the Server level (step 6).