How does Secure Socket Layer(SSL) work?

Why use HTTPS?

When a user connects to a website like Facebook or Google by HTTP, the data packets travel through multiple devices, such as routers and proxies. These devices can be compromised, leading to a Man-in-the-Middle Attack (MITM). To address this, we must solve it by SSL or TLS.

What is SSL?

SSL (Secure Socket Layer) is a security protocol that encrypts data transmitted between two systems, ensuring secure communication.

A common example of two systems using SSL is the communication between a web browser and a web server. If you visit a website using the HTTP protocol, the communication between the browser and the server is insecure, and the data will send in plain text.

On the other hand, if the website uses HTTPS, SSL is in place. Here, the data transmitted between the browser and the server will encrypt, providing an additional layer of security.

TLS (Transport Layer Security) is the newer version of SSL. Today, most HTTPS protocols are implemented using TLS. However, people often still refer to it as SSL.

How does SSL work?

Before understanding how SSL works. Firstly, it’s important to learn about two key concepts: Asymmetric Cryptography and Symmetric Cryptography. These are the two encryption methods.

Asymmetric Cryptography

Asymmetric Cryptography, also known as Public Key Cryptography, is a method of encrypting data using a pair of keys: a Public Key and a Private Key.

• The Public Key is shared openly and can be used by anyone who wants to communicate.
• The Private Key is kept secure on the server and is not shared.

During communication, the sender uses the Public Key to encrypt the data. When the encrypted data is received, the receiver uses the Private Key to decrypt it.

Symmetric Cryptography

Symmetric Cryptography is another method of encrypting data, similar to Asymmetric Cryptography. But with one key difference: instead of using a pair of keys, it uses a single key to encrypt and decrypt the data.

Handle data in SSL

SSL uses both Asymmetric and Symmetric encryption to secure data communication. When two systems communicate using SSL, the process consists of two main steps: SSL Handshake and Data Transfer, Certificate Authority.

1. SSL Handshake:
   • Asymmetric Cryptography is used during this step. It establishes a secure connection by exchanging keys between the client and the server.
2. Data Transfer:
   • Once the handshake is complete, Symmetric Cryptography is used for encrypting and transferring data efficiently.

The Certificate Authority (CA) plays a critical role in verifying the identities of the systems involved, ensuring trust and authenticity in the connection.

Certificate Authority (CA)

The Certificate Authority (CA) plays a crucial role at the start of the process.

1. Certificate Issuance:
   • The CA issues the SSL certificate to the web server. This certificate includes the server’s Public Key and additional metadata, such as the server’s domain name and information about the CA itself. The certificate is digitally signed by the CA to verify its authenticity.
2. Certificate Validation during the SSL Handshake:
   • When the server sends its SSL certificate to the browser (as part of the “server hello” message), the browser checks:
     • The certificate is issued by a trusted CA.
     • That the certificate matches the domain being accessed.
     • That the certificate has not expired or been revoked.

SSL Handshake

When establishing an SSL connection, the process starts with an SSL handshake that uses Asymmetric Cryptography. This handshake allows the browser to authenticate the SSL certificate with the web server. Here’s how it works when you enter an HTTPS address in your browser:

1. Client Hello:
   • The browser sends a message called “client hello” to the web server, indicating the initiation of an SSL handshake. This message includes supported encryption methods and SSL/TLS versions.
2. Server Hello:
   • The server responds with a “server hello” message, which includes:
     • Information about the chosen encryption method.
     • The server’s SSL certificate and its Public Key.
3. Certificate Verification(Detail above):
   • The browser validates the SSL certificate to ensure it is legitimate and issued by a trusted Certificate Authority (CA). If the validation is successful, the handshake continues. Otherwise, the browser displays a warning.
4. Session Key Generation:
   • The browser generates a Session Key, which will encrypt data during the session.
5. Encrypting and Sending the Session Key:
   • The browser encrypts the Session Key using the server’s Public Key (asymmetric encryption) and sends it to the server.
6. Decrypting the Session Key:
   • The server receives the encrypted Session Key and uses its Private Key to decrypt it. Once decrypted, the server stores the Session Key.
7. Acknowledgment:
   • The server sends a signal back to the browser, confirming it has successfully received and stored the Session Key.

At the end of the SSL handshake, both the browser and the server have the Session Key. This key is used for encrypting and decrypting data during subsequent communication between the two systems.

Key Points:

• The Session Key is a shared key generated during the handshake.
• It is used in Symmetric Encryption, which is much faster than asymmetric encryption, making it suitable for encrypting large amounts of data.
• Both parties (browser and server) use the same Session Key to:
  • Encrypt outgoing messages.
  • Decrypt incoming messages.

Data Transfer

This is the phase where data is exchanged securely between the two systems after the SSL handshake. During this process:

• Symmetric Cryptography is used to encrypt and decrypt the data.
• Both the browser and the server use the previously established Session Key for:
  • Encrypting outgoing data.
  • Decrypting incoming data.

Summary

This is how SSL works. When setting up a server, SSL is a crucial component, but it is also prone to errors. Understanding how SSL operates can make it much easier to troubleshoot and manage issues effectively during implementation.

A solid grasp of the SSL handshake, encryption methods, and the role of the Certificate Authority (CA) ensures secure communication and helps address common pitfalls in SSL configuration.

QA

Question: Why not use asymmetric keys for all encryption, instead of exchanging a symmetric key?

Answer:

Using asymmetric keys for encryption and decryption is computationally more complex and requires significantly more resources than symmetric keys. If asymmetric encryption were used for all communication, it would result in much slower performance.

Question: Before communicating using asymmetric encryption, Alice must receive Bob’s public key through an SSL Certificate sent by Bob. Can Eve intercept and fake the public key?

Answer:

Eve cannot successfully fake the public key, because Alice will verify the authenticity of the SSL Certificate. Here’s why:

1. Certificate Verification:
   • The SSL Certificate sent by Bob is issued and signed by a trusted Certificate Authority (CA).
   • Alice’s system uses a pre-installed list of trusted CAs to verify the certificate. If the certificate is tampered with or fake, the verification will fail.
2. Authenticity of Public Key:
   • The certificate includes Bob’s public key, which is signed by the CA.
   • If Eve tries to replace the certificate or public key, the signature check will fail, and Alice will reject the connection.
3. Refusal to Connect:
   • If Alice detects that the certificate or the public key inside it is fake, she will terminate the connection and notify the user that the site is untrusted.

This process ensures that man-in-the-middle attacks (MITM), where Eve tries to impersonate Bob, are effectively prevented in SSL communication.

References

https://www.tutorialsteacher.com/https