Understanding SSL/TLS: The Key to Secure Online Communication

Introduction

With the increasing use of internet for various activities such as online shopping, banking, social networking, etc; security has become crucial for users.

When a client is communicating with a server, there can be a transfer of sensitive information such as login credentials, credit card information or others information that are supposed to be private ! In that case, the communication must be secure.

One of the critical components of online security is SSL. In this article, We are going to learn how does SSL work, and in the next article we will see how it can be compromised by hackers and how to protect it against stripping attacks.

What is SSL / TLS

SSL stands for Secure Socket Layer, a security protocol that establish a secure and safe connection between two systems.

It makes sure that any information transferred between two systems is not readable by using encryption algorithms to scramble it.

💡 TLS stands for Transport Layer Security. It is just an update of SSL. It is more secure. So as much as we will discuss SSL and continuously refer to it throughout this article, we will also discuss TLS.

In this article, we are going to focus on Client - Server system. A communication between a web browser (chrome, Firefox, ...) as a client and a web server.

The basic of Client - Server Communication*

The communication between web browsers and web servers is the foundation of the internet.

It is just a simple request-response process in which the browser requests information from the server and the server responds with the requested information. This communication is facilitated by a set of protocols.

💡 Protocols are the rules and standards that govern the communication between two systems.

The most commonly protocol used for web browser and web server communication is the Hyper Text Transfer Protocol (HTTP).

This communication is essential for the functioning of the internet, but it also presents some **challenges.* As this communication is done over the internet, it is vulnerable to malicious attacks. One of the biggest challenges is ensuring that the communication between those two systems is secure.*

How does the SSL / TLS work ?

As discussed, the primary purpose of SSL is to provide a secure transport-layer connection between two endpoints. In our case, between a website server and the client browser.

When the browser is trying to interact with a secured web server via the SSL protocol, an SSL certificate is needed to ensure that a secure connection is established. If the certificate is valid, the browser said to be “SSL enabled”, it will have a padlock icon just before the URL and will begin with “HTTPS” rather than “HTTP”.

What is an SSL certificate ?

An SSL certificate is a file hosted in the website’s server, it contains :

• The domain name that the certificate was issued for
• Which person, organization, or device it was issued to
• Which certificate authority issued it (CA)
• The certificate authority's digital signature
• Associated subdomains
• Issue and expiration date of the certificate
• The public key

To view an SSL certificate's details, you can click on the padlock symbol located within the browser bar.

If a device tries to communicate with this server (secured), the device will use this file to obtain the information listed out above.

Now, we know what is an SSL certificate and its content; let’s see how a secure connection take place:

The process works like this:

1. A browser attempts to connect to a server (secured with SSL).
2. The browser requests that the server identifies itself (request the SSL certificate).
3. The server sends the browser a copy of its SSL certificate in response.
4. The browser checks to see whether it trusts the SSL certificate. If it does, it signals this to the server.
5. The server then returns a digitally signed acknowledgment to start an SSL encrypted session.

💡 This process is called “SSL handshake” and it takes place in milliseconds.

The SSL/TLS Handshake

Let’s understand some SSL/TLS terminologies before delve into the specifics of SSL/TLS handshake :

• Cipher suite

A cipher is a cryptographic algorithm, a procedure used to encrypt and decrypt data.

Ciphers operate by encrypting the original message (plaintext) via the algorithm’s rules (i.e., the encryption key) to produce what’s known as ciphertext. The ciphertext contains all the information of the original plaintext message but appears as a random string of data. It cannot be read by anyone who doesn’t have the key.

The cipher use a symmetric encryption (when the same key is used for both encryption and decryption), or an asymmetric encryption (when different keys are used for encryption and decryption).

A cipher suite is just a suite of cipher 🙃, in our case:

• Key exchange algorithms, such as RSA, DH, ECDH, DHE, ECDHE, or PSK : to exchange keys securely.
• Authentication/Digital Signature algorithm, like RSA, ECDSA, or DSA : to ensure that a message was sent by an entity that claims to have sent it, to ensure that the message has not been modified.
• Bulk encryption algorithms, like AES, CHACHA20, Camellia, or ARIA : to encrypt messages *exchanged *between *clients *and ****servers, it is a more secured way to encrypt a large amount of data.
• Message Authentication Code algorithms, such as SHA-256, and POLY1305 : to authenticate a message, to confirm that the message came from the stated sender and has not been changed.

During the handshake, the browser and the server will agree about a cipher suite to use (set of algorithms) to establish a secure connection. If the client and server do not agree on a cipher suite, no connection will be made. Once the cipher suite is agreed upon, they will proceed with the key exchange.

• *Authentication*

Authentication lets each party in a communication verify that the other party is who they say they are.

The client uses the server’s certificate to authenticate the identity the certificate claims to represent.

To authenticate the server, the client must receive a YES answer to these questions:

• Is today’s date within the validity period?
• Is the issuing CA a trusted CA?
• Does the issuing CA’s public key validate the issuer’s digital signature?
• Does the domain name in the server’s certificate match the domain name of the server itself?

💡 A CA is an outside organization, a trusted third party, that generates and gives out SSL certificates. The CA will also digitally sign the certificate with their own private key, allowing client devices to verify it.

We've got a grasp on what a cipher is and how the client authenticates the server, so let's have a look at the process of SSL/TLS handshake.

The procedure for establishing an SSL/TLS connection depends on the encryption method employed, but the fundamental procedure is as follows:

1. The SSL client will send the server a “Client Hello” message that details the client’s configuration settings, including the SSL/TLS version, the cipher suites it supports, and a string of random data referred to as “client random.”
2.  The SSL server sends back a “Server Hello” message containing its own public key, digital certificate, the cryptographic algorithm agreement (selected by the server from the client-supplied list of algorithms), and the “server random”.
3. The client performs authentication by contacting the server’s certificate authority (CA) to validate the web server’s digital certificate. This confirms the authenticity of the web server, thus, establishing trust.
4. The client uses the extracted public key from the verified certificate and generates a 48-bit string called the premaster secret. The premaster secret is then encrypted using the extracted public key and is sent to the server. The premaster secret will be used for both client and server to generate the symmetric keys used for the secured session.
5. The SSL/TLS server decrypts the premaster secret using its private key.
6. Both client and server generate session keys from the client random, the server random, and the premaster secret. They should arrive at the same results (a shared key).
7. Next, the client sends an encrypted “finished” message using the shared secret key. This message says that the client’s part of the handshake is complete.
8. Finally, an encrypted “finished” message is sent back to the client from the server using the previously agreed shared secret key, which indicates the end of the server’s side of the handshake.
9. Once the SSL/TLS handshake and negotiation is done, the server and the client communication continues, i.e., they begin to share files and messages using the session keys (symmetric encryption).

Conclusion

SSL/TLS plays a crucial role in securing online communication and protecting sensitive data. It is important for websites and applications to implement SSL/TLS protocols to ensure the trust and confidence of users. As technology advances, it is also important to stay up-to-date with the latest SSL/TLS versions and best practices to maintain a secure online environment.

I hope that the information I have shared has been informative, helpful and thought-provoking. I always strive to provide the best content possible.

Once again, thank you so much for reading. Your presence and support mean a lot to me!

See you soon!

Best regards,