This post is to explain the need for SSL and how it works. Let's dive directly into it.
Why the need for security?
Imagine you are a developer or an infrastructure engineer. You may have to heavily rely on other systems in your environment for you.
For example, you have an application written in Java. It needs to connect to a database for its operations, and your Java program runs on a different server. Another scenario: you have an app server that hosts your application. It needs to connect to other systems like database servers or message queuing servers, constantly.
These are some example scenarios in which one server may have to constantly connect to other servers/clients in an infrastructure for its operations. In such cases, the data between various servers flows continuously. The flow may be inside the organization's infrastructure, or, depending on the need, it may have to connect to external systems or organizations.
In such cases, how do you make sure that your data is safely transmitted over multiple systems? If we don't have any security setup, the data may be compromised, and it may be available to all who can intercept the data.
To avoid these vulnerabilities, we use encryption to safeguard our data from intruders or even within the organization to prevent unwanted data revelation.
There are two types of encryption available: symmetric and asymmetric key.
In symmetric key, both the sender and receiver use the same key to encrypt and decrypt the data. This can be enabled between systems that are trusted by each other.
Asymmetric key means the receiver should have a private key; it creates a public key based on its private key and shares it with all systems that want to connect with it. The sender encrypts the data with the received public key and sends it to the receiver. Having the private key, only the receiver can decrypt the data, which ensures a more secure environment than symmetric key-based encryption.
But how does it get implemented in real time?
In real time, we use SSL keys to establish communication between two systems; we usually call it a client/server connection. It means a server system is a system that provides some data to a client, and a client system (even though it may be a server ) initiates a connection with a server for some query or data.
We call the established connection an SSL handshake. It may be one-way or two-way. We will see about them later.
To implement SSL in a server, we need to create a private key for the server. Using the key, we create a CSR with the needed CN values and send it to any CA authority. CA authority will acknowledge the CSR and provide us the certificate matching it. The cert provided by the CA authority is being used as a public key by the clients.
The server will send this cert to the clients that request connections. The clients verify the cert by their trust store data, and once it's done with the validation, it starts the server communication using the cert.
Below are the simplified steps when a client initiates a connection to a server.
1. Client send Client Hello to server (it includes supported encryption algorithms details and a client random)
2. Server responds with a Hello Server message (it has the chosen encryption algorithm and a server random and also its certificate, which is known as public key)
3. The client verifies the certificate sent by the server with its trust store entries. It verifies its expiry and its root and intermediate certs for its authenticity.
4. If all looks good, the client generates a pre-master secret to be used further in the transaction. Then the pre-master key is encrypted using the public key (certificate) sent by the server. Then the encrypted data is sent to the server.
5. The encrypted data sent by the client is decrypted by the server using its private key.
6. Now the pre-master secret, client random, and server random are available to both server and client for further operations. Separately, they create a session key using these values (using a cryptographic algorithm KDF), and they both should obtain the same session keys since they use the same values.
7. Further transactions in that session will be encrypted by the session key (here on it is a symmetric key since both sender and receiver use the same key to encrypt and decrypt).
The important point is that the client random and server random are transmitted as plain text, but the premaster key is transmitted from client to server as encrypted data. Since all three are needed to create the session key, it's not possible to decrypt the data in the middle without all these details.
This is just a generic explanation of how one-way SSL works. In case of two-way SSL, an extra layer of client cert is introduced.
So what is one-way and two-way SSL?
One-way SSL - In this, only the server presents the certificate to the client. This means the client does not need to authenticate itself to the server that it is a valid client. The client will just verify the authenticity of the server, and if the server is a valid system, the connection will be established.
Two-way SSL - In this, the client will verify the authenticity of the server, but the server will request the client to share its certificate to validate the client's authenticity.
In simple terms, if only the server is authenticated in an SSL handshake, it is one-way SSL, and if both the server and the client are authenticated, it is called a two-way SSL handshake.
1. Client sends Client Hello to server (it includes supported encryption algorithms details and a client random)
2. Server responds with a Hello Server message (it has the chosen encryption algorithm and a server random and also its certificate, which is known as a public key).
3. The server also requests the client cert using a certificate request message, and the client responds to it with its cert.
4. The client verifies the certificate sent by the server with its trust store entries, and the server verifies the certificate sent by the client with its trust store entries. Both verify the cert expiry and its root and intermediate certs for its authenticity.
5. If all looks good, the client generates a pre-master secret to be used further in the transaction. Then the pre-master key is encrypted using the public key (certificate) sent by the server. Then the encrypted data is sent to the server.
6. The encrypted data sent by the client is decrypted by the server using its private key.
7. Now the pre-master secret, client random, and server random are available to both server and client for further operations. Separately, they create a session key using these values (using a cryptographic algorithm KDF), and they both should obtain the same session keys since they use the same values.
8. Further transactions in that session will be encrypted by the session key (here on it is a symmetric key since both sender and receiver use the same key to encrypt and decrypt).
I hope I clarified both one-way and two-way SSLs as simply as possible.
Some questions you have regarding the SSL:
1. If both client and server, or at least the client, have the cert, why not use it to encrypt the data throughout the session? Why create a session key for further encryptions in a session? (This is one of the questions I had, so I'm adding it to clarify.)
The reason is, the resources utilized to do the encryption and decryption using a symmetric key are lower than to do it with an asymmetric key. So it is designed to authenticate using an asymmetric key, but agrees to use the same key to encrypt and decrypt throughout the session to avoid excessive usage of resources in the system.
2. What is a trust store? Why does the client or server refer to it while verifying the cert?
Trust store is a local cert repository for the systems to store the CA's certs and its trusted system's certs to validate the certs shared in a connection.
3. What is a CA's cert?
CA - Certificate Authority. CAs are organizations that can sign the certificates. The CAs are trusted by all the corporations and systems, so the certificates issued by CAs are considered genuine and trustworthy. However, the CAs will issue root and intermediate certs for the system certs if requested, and so keeping the root and intermediate certs in the truststore of remote servers will make sure that the authentication will happen without any hassle.
SSL, as explained so far, only does system-level authentication, which means the client can authenticate whether the server system is a valid one or not, and vice versa in two-way SSL. But do you know that by enabling mTLS, we can also do user-level authentication, which depends on the CN? That is for another post.
If you have any questions or feedback, feel free to comment—I’d love to hear from you as I refine this post!
Comments
Post a Comment