SSL/TLS handshake in detail

Let’s first brush up the basics to move ahead to understand SSL/TLS handshake.

HTTP V/S HTTPS

HTTP (Hypertext Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Secure) are two basic protocols (works on layer 7 of OSI model) used for communication between web browsers and servers i.e. how data is transmitted and structured during the exchange of information.

HTTP is a stateless and light weight (as there is no TLS encryption involved) protocol, which means that each and every request made by the browser is independent and doesn’t retain any information about previous requests and moreover the communication between your browser and the server is transmitted in plain text, making it vulnerable to MITM attacks.

Then how server maintains state of user without asking asking user his/her identity each and every time?

I have discussed this in separate write-up cookies, please refer this for more details (https://pratham-08.medium.com/cookies-in-tech-world-ffb17d69814c).

HTTPS is an extension of HTTP that adds a layer of security through the use of encryption by utilising SSL (Secure Sockets Layer)/TLS (Transport Layer Security), to establish an encrypted connection between the browser and the server. This encryption ensures that data transmitted between the two parties remains confidential and cannot be easily intercepted or altered by attackers (preventing MITM attacks).

To establish an HTTPS connection, the server must have a digital certificate issued by a trusted Certificate Authority (CA). The certificate verifies the authenticity of the server and allows the browser to establish a secure connection. When you visit a website using HTTPS, your browser displays a padlock symbol in the address bar, indicating that the connection is secure.

Asymmetric Encryption V/S Symmetric Encryption:

Asymmetric encryption, also known as public-key encryption, is a cryptographic technique that uses a pair of mathematically related keys: a public key and a private key. These keys are used for encryption and decryption, and each key performs the inverse operation of the other.

1. Public Key: The public key is openly shared and can be distributed to anyone who wants to communicate securely with the owner of the key. It is used for encrypting data or verifying digital signatures.
2. Private Key: The private key is kept secret and known only to the key owner. It is used for decrypting data encrypted with the corresponding public key or generating digital signatures.

Symmetric encryption, also known as secret-key encryption or shared-key encryption, is a cryptographic technique that uses a single key for both encryption and decryption. The same secret key is used by both the sender and the recipient.

The process of symmetric encryption involves the following steps:

1. Key Generation: A secret key is generated or agreed upon by both the sender and the recipient. This key must be kept confidential and shared securely between the communicating parties.
2. Encryption: The sender uses the shared secret key to encrypt the plaintext message, transforming it into ciphertext.
3. Decryption: The recipient uses the same shared secret key to decrypt the ciphertext and recover the original plaintext message.

Let’s move forward….What happens when we try access any website (https://www.example.co.uk)

Refer to my article for the same (https://pratham-08.medium.com/how-user-reaches-intended-url-8f75f7ef8a5e)

If you have gone through my above mentioned article then you might have stopped on SSL/TLS handshake part as the same is very complex in itself and needs to be discussed separately.

After successful TCP/IP 3-way handshake, SSL/TLS handshake takes place to ensure secure connection b/w both parties. The handshake follows a specific sequence of steps:

1. Client Hello: The client initiates the handshake by sending a Client Hello message to the server. This message includes information such as the highest SSL/TLS version supported like (TLS 1.0, 1.2, 1.3, etc.), a list of supported cipher suites and a string of random bytes known as the “client random.”.
2. Server Hello: Upon receiving the Client Hello, the server responds with a Server Hello message. This message includes the SSL/TLS version chosen for the connection (supported versions shared by client), the cipher suite selected from the client’s offered options, server certificate containing its public key and the “server random,” another random string of bytes that’s generated by the server. Server uses Asymmetric encryption i.e. it will private key with itself and share public key with client so that client can use that key to encrypt messages before sending to server.

Let’s see how server requests for certificate from CA?

In the beginning, the server admin request a certificate from a certificate authority(CA) by providing CSR (Certificate Signing Request) that consist of domain details and public key of the server.

CA uses the information provided to validate the identity of the entity. The CA verifies the information and performs checks to ensure that the entity has control over the domain or resource for which the certificate is requested. Once the CA verifies the entity’s identity, it signs the CSR with the CA’s private key, creating a digital certificate with the following steps:

1. CSR is signed with hashing algorithms i.e., SHA256/md5 and generates hash(CSR)
2. Then the hashed CSR is encrypted using one of its signer private keys and generates encrypted(hash(CSR))
3. Then encrypted(hash(CSR)) is attached to CSR and we can call it a digital certificate

Digital certificate = CSR + encrypted(hash(CSR))

3. Handshake Authentication: The client validates the received certificates and perform additional checks to ensure the trustworthiness of the other party and confirming certificate is issued by CA and not self-signed and that the client is interacting with the actual owner of the domain.. This includes verifying the certificate chain, checking revocation status, and confirming that the server’s hostname matches the certificate.

How client verifies server’s certificate:

Client looks at the certificate sent by server and checks whether the certificate is from trusted CA’s.

If it is from trusted CA’s, then the client parses the certificate, where client will get CSR and encrypted(hash(CSR)) as mentioned above Digital certificate = CSR + encrypted(hash(CSR))

1. Now client will create a hash of CSR using a hashing algorithm, client generates a hash(CSR).
2. Encrypted(hash(CSR)) is decrypted using the key of CA. from this, client will also get hash(CSR).

If hash(CSR) in step 1== hash(CSR) in step 2, then certificate is verified and valid.

4. Client Key Exchange: The client generates a premaster secret (using symmetric encryption) i.e. 2 secret keys and encrypts one premaster secret key using the server’s public key from the received certificate named encrypted premaster secret. This encrypted premaster secret is sent to the server, ensuring that only the server can decrypt it with its private key and use afterwards.

IMPORTANT: Now server has its own private key to decrypt messages received from client encrypted using server’s public key and premaster key (Symmetric key) of client as well to encrypt messages before sending to client and similarly client has server’s public key to encrypt messages before sending to server and client’s own premaster key (Symmetric key) to decrypt messages received from server

5. Premaster Secret and Session Keys: Both the client and server use the exchanged secret keys for encryption and decryption during the secure communication session.

6. Handshake Completion: At this point, both the client and server have established a secure connection. They notify each other with a Finished message, confirming that the handshake was successful.

Once the handshake is completed, the client and server can begin securely exchanging encrypted data using the agreed-upon encryption parameters. The SSL/TLS handshake ensures confidentiality, integrity, and authenticity of the communication between the two parties.

But TLS/SSL (Transport Layer Security/Secure Sockets Layer) protocols have been targeted by various attacks over the years. Here are some of the attacks associated with TLS/SSL:

1. Man-in-the-Middle (MitM) Attack: In a MitM attack, an attacker intercepts the communication between the client and the server, impersonating one or both parties. The attacker can eavesdrop on the encrypted traffic, modify it, or inject malicious content. This attack can occur if the TLS/SSL handshake is compromised or if the attacker gains access to the private keys or certificates.
2. BEAST (Browser Exploit Against SSL/TLS): This attack targets a vulnerability in the SSL/TLS CBC (Cipher Block Chaining) mode. By exploiting this vulnerability, an attacker can decrypt parts of the SSL/TLS encrypted communication, potentially obtaining sensitive information such as session cookies.
3. POODLE (Padding Oracle On Downgraded Legacy Encryption): POODLE targets the SSLv3 protocol by exploiting a weakness in the way block ciphers handle padding. This attack allows an attacker to decrypt the SSLv3 encrypted data, potentially exposing sensitive information.
4. Heartbleed: Heartbleed is a critical vulnerability in the OpenSSL library used in many TLS/SSL implementations. It allows an attacker to read arbitrary data from the server’s memory, including private keys and sensitive information, potentially compromising the security of the encrypted communication.
5. CRIME (Compression Ratio Info-leak Made Easy): CRIME attacks the compression feature of TLS/SSL protocols. By exploiting the compression ratios, an attacker can deduce information about the encrypted data, including session cookies, leading to potential security breaches.
6. FREAK (Factoring RSA Export Keys): FREAK exploits a vulnerability in the SSL/TLS protocols that allowed the export of weak, 512-bit RSA keys. Attackers can force a server to use these weak keys, enabling them to decrypt the SSL/TLS encrypted communication.
7. DROWN (Decrypting RSA with Obsolete and Weakened encryption): DROWN targets servers that support SSLv2, allowing an attacker to decrypt TLS/SSL encrypted communications. This attack is possible due to a vulnerability that enables the attacker to exploit weak keys used in SSLv2.
8. Logjam: Logjam attacks the Diffie-Hellman key exchange protocol used in TLS/SSL. By exploiting weak parameters, an attacker can downgrade the security of the communication, making it vulnerable to decryption and interception.

These are some notable attacks associated with TLS/SSL. It is important to note that many of these vulnerabilities have been patched, and regular updates and proper configuration of TLS/SSL implementations are crucial to ensure secure and robust communication.

Do support this and feel free to comment in case you see any issues.