Tuesday 14 May 2024

Quick glance on SSL termination

 

SSL termination, sometimes referred to as TLS termination in modern times, involves decrypting HTTPS traffic before it reaches the web or application server.

 

Let's first understand some basic terms:

 

a.   SSL: Stands for Secure Socket Layer, this is an older protocol introduced in 1995 that provided the groundwork for secure communication over networks.

b.   TLS: Transport Layer Security, the successor to SSL, addresses security flaws found in SSL and has become the standard for secure communication.

c.    HTTPS: HTTPS is an extension of the standard HTTP (Hypertext Transfer Protocol) used for communication between web browsers and servers. The "S" signifies "Secure," indicating that the connection is encrypted using TLS/SSL.

 

How SSL works?

Following step-by-step explanation helps you to understand how SSL/TLS communication works between a client and server.

 

 

1.   Client Hello:

The process begins when the client (e.g., web browser) sends a "Client Hello" message to the server during the initial connection request. This message includes information such as supported SSL/TLS versions, encryption algorithms, and other parameters.

 

2.   Server Hello:

Upon receiving the "Client Hello," the server responds with a "Server Hello" message. The server selects the highest SSL/TLS version and encryption algorithm that both the client and server support and includes this information in the response.

 

3.   Client Acknowledgement:

Client acknowledge and accept the Server Hello message.

 

4.   Certificate Exchange:

The server sends its digital certificate to the client, which contains the server's public key, along with information about the certificate issuer and expiration date. The client verifies the authenticity of the certificate by checking its digital signature against a list of trusted certificate authorities (CAs) stored in the client's browser or operating system.

 

5.   Key Exchange:

Client generates a random symmetric encryption key (session key) and encrypts it with the server's public key obtained from the certificate. The encrypted session key is sent to the server.

 

6.   Symmetric Encryption:

Both the client and server now have the session key, which they use to encrypt and decrypt data exchanged during the SSL/TLS session. This symmetric encryption provides confidentiality and ensures that only the client and server can read the data exchanged between them.

 

7.   Secure Data Transfer:

Once the SSL/TLS handshake is completed and the secure connection is established, data transfer between the client and server occurs over this secure channel. All data transmitted between the client and server, including sensitive information such as login credentials or personal data, is encrypted and protected from eavesdropping or tampering by attackers.

 

8.   Session Termination:

When the SSL/TLS session is complete (e.g., the user closes the browser or navigates away from the website), either the client or server can initiate the session termination. The session keys are discarded, and the secure connection is closed.


This process ensures that data exchanged between the client and server remains confidential, authenticated, and tamper-proof, providing a secure communication channel over the internet.



 

PlantUML code for the same

@startuml

participant Client
participant Server

Client --> Server: Client Hello
note right: Step 1: Client initiates\nSSL/TLS handshake\nby sending\nClient Hello message

Server --> Client: Server Hello
note left: Step 2: Server responds\nwith Server Hello message\nselecting SSL/TLS\nversion and encryption\nalgorithm

Client --> Server: Acknowledge Server Hello
note right: Step 3: Client acknowledges\nand accepts Server Hello\nmessage

Server --> Client: Certificate Exchange
note left: Step 4: Server sends\nits digital certificate\nto the client\ncontaining its public\nkey and certificate details

Client --> Server: Key Exchange
note right: Step 5: Client generates\na random symmetric\nencryption key and\nencrypts it with the\nserver's public key\nfrom the certificate

Client <-> Server: Symmetric Encryption
note right: Step 6: Both client and server\nuse the symmetric encryption\nkey to encrypt and decrypt\ndata exchanged during the session

Client <-> Server: Secure Data Transfer
note right: Step 7: Data transfer occurs\nover the secure channel\nestablished using SSL/TLS,\nensuring confidentiality and\nintegrity of the data

Client <-> Server: Session Termination
note right: Step 8: Either client or\nserver initiates session\ntermination when the SSL/TLS\nsession is complete,\ndiscarding session keys\nand closing the connection

@enduml

SSL termination in detail

Let’s see how SSL termination works in detail.



1.   Client sends a request: The client sends a request to the SSL/TLS termination point (it is API Gateway, Load balancer, API proxy) over a secure HTTPS protocol. This ensures that the communication between the client and the API Gateway is encrypted.

2.   SSL termination receives and decrypts: SSL/TLS termination point receives the encrypted request and decrypts it.

3.   Request forwarded to the application server: SSL/TLS termination point forwards the unencrypted request to the actual application server for processing. This communication typically occurs over HTTP and is not encrypted.

4.   Application server processes the request: The application server processes the request and generates a response.

5.   Response sent back to the SSL/TLS termination point: The application server sends the response back to the SSL/TLS termination point over HTTP, in an unencrypted form.

6.   SSL/TLS termination point encrypts the response: The SSL/TLS termination point encrypts the response before send it back to the client. This ensures that the communication between the SSL/TLS termination point and the client remains secure.

7.   Response sent to the client: Finally, the SSL/TLS termination point sends the encrypted response back to the client over HTTPS, ensuring that the communication with the client is secure.

 

What is SSL/TLS termination point here?

SSL/TLS termination point can be API Gateway, Load Balancer, or API Proxy. The choice is completely depend on your system Architecture.

 

1.   API Gateway:

Acts as a central hub for managing multiple APIs, focusing on providing a unified entry point, security, and overall API lifecycle management. It offers a wide range of features including authentication, rate limiting, monitoring, and combining data from multiple APIs.

 

2.   API Proxy:

Primarily forwards requests to backend APIs and performs basic transformations or security checks. Has a limited set of functionalities including routing requests, basic security checks, and simple request/response transformation.

 

3.   Load Balancer:

A load balancer distributes incoming network traffic across multiple servers to ensure that no single server becomes overwhelmed. While load balancers primarily focus on distributing traffic, some advanced load balancers also offer SSL termination capabilities.

 

Benefits of SSL termination

1.   Reduced Server Load: Decrypting HTTPS traffic can be hard work for servers (as it require to work with cryptographic algorithms). When we use SSL termination, we give this job to a special point, like a load balancer or API proxy. This helps our main servers focus on what they do best, making our website faster and more responsive.

2.   Centralized Decryption: With SSL termination, one point can handle decryption for many servers. This makes it easier to grow our system because we don't have to worry about each server doing decryption on its own. It makes managing everything simpler.

3.   Potential Security Inspection: When we decrypt traffic at the termination point, we have the chance to check it for malicious stuff before it reaches our servers. This adds another layer of security. However, remember that our servers won't directly see the original encrypted traffic.

4.   Simplified Certificate Management: Instead of managing SSL certificates on every server, SSL termination lets us manage them all in one place. This makes it much easier to keep everything secure and up-to-date.

 

Points to consider while using SSL termination

1.   Loss of Visibility for Web Servers: With SSL termination, the web server can't see the encrypted traffic anymore. It only gets the unencrypted data. This means the server might miss out on checking for security issues in the encrypted traffic.

2.   Monitoring Challenges: Tools that keep an eye on security might struggle to work well if the data is decrypted before it gets to the web server. This makes it harder to spot any potential security problems in the encrypted data.

3.   Single Point of Failure: If something goes wrong with SSL termination point, the secure communication for all the websites it handles will be affected. This makes it crucial for this point to be really reliable and safe.

4.   Trust Concerns: The system doing SSL termination needs to be trusted because it can see the decrypted data. If this system gets compromised, it could expose sensitive info. So, we need strong security measures to keep it safe.

5.   Extra Setup Work: Setting up and managing the SSL termination point means more things to configure. We have to make sure everything is set up right for security policies, managing certificates, and maybe checking traffic.

6.   Possible Performance Issues: Although SSL termination can make the web server work faster by taking the decryption job away, if the termination point isn't set up well, it could slow things down instead of speeding them up.

7.   Vendor Dependency: Some features of SSL termination might be tied to a specific vendor's way of doing things. This could mean you're stuck with that vendor if you rely too much on their solution.

 

In summary, while SSL termination gives some good advantages, we should also think about the possible problems it might cause. Before deciding to use SSL termination, think about how secure you need to be, how complicated your system is, and what kind of monitoring you need. If you go ahead with it, make sure you set it up right, keep it secure, and have backup plans in case something goes wrong.


 

 

 


                                                                                System Design Questions

No comments:

Post a Comment