What Is SSL Passthrough? How does TLS Passthrough Work?

What Is SSL Passthrough?
The SSL Passthrough is a technique used in the network architecture for managing the SSL/TLS connection of the clients and back servers.
This is very different from SSL Termination or more commonly known as SSL offloading where the SSL/TLS connection is decrypted at an intermediary device (like a load balancing appliance).
In SSL Passthrough, the traffic is directed through a load balancer or proxy server without necessarily decrypting it.
This means that after the data has left the client and is on its way to the backend server, the data is encrypted and protected from being intercepted in the network in the middle.
How Does SSL Passthrough Work?
Step 1: Client wants to initiate an SSL/TLS connection
It starts when a client, for instance a web browser, establishes SSL/TLS connection with a server. In this process of a handshake, the client and the server are exchanging the cryptographic keys plus setting the encrypted session.
The client initiates communication by sending a “ClientHello” message to the server, wherein the communication version and other security parameters are listed by the client.
It involves a handshake process in which both parties determine how they will encode/decode information before transmitting it.
Step 2: Number of ‘hits’ to Load Balancer or Proxy
Traffic from a client application is encrypted and then forwarded to an intermediate device like a load balancer or a proxy. This device is usually placed at the entrance of this model between the client and the backend servers.
In this stage, the traffic remains encrypted and the intermediary device does not move to decrypt it. The load balancer or proxy server is designed to distribute the load involved in handling packets and keep the backend servers efficiently available.
Step 3: Load Balancer or Proxy then forwards the encrypted traffic.
In this case, rather than decoding the traffic, a load balancer or proxy server simply relays the encrypted traffic to the suitable backend server.
This forwarding depends on elements such as the load on the server, the server health status, and the routing policies set in the load balancer apparatus.
The intermediary device only forwards the proposal and its associated encrypted data through without decrypting, processing or inspecting them, thus preserving the integrity of the data.
Step 4: The Backend Server carries out the decryption.
The backend server that is in possession with SSL/TLS certificate as well as the corresponding private key receives the encrypted traffic.
Following the communication of the SSL/TLS handshake messages, the server utilizes its private key to generate the symmetric key in order to create a secure session with the client.
Also Read: How to Fix the SSL Handshake Failed Error Code 525?
After the session has been established, information encrypted by the backend server can be decrypted so as to attend to the client’s request and develop a response.
The server makes sure that all the data is safe during the processing stage of the data passed through the system.
Step 5: Backend Server Encrypts Response
On receiving the request, the backend server decrypts it and processes the request, then encrypts it with SSL/TLS before sending. After the handshake steps, the server employs the keys that were agreed on to encrypt the response data.
This helps to guarantee that the response data is protected before being sent back through the network. The encryption process also ensures confidentiality as well as integrity of the data as it is sent back to the client.
Step 6: Encrypted Response Forwarded by Load Balancer or Proxy
The response from the backend server is usually encrypted, and the load balancer or proxy server returns this to the client. Similarly to the previous example, the intermediary device does not decrypt the traffic and just passes it onto the client.
The load balancer or the proxy server continues to act as a middleman without interfering with the communication or timing of the encrypted response reaching the client.
Step 7: Client Receives Encrypted Response
The client gets the encrypted response and using the previously developed SSL/TLS session decrypts it. The established cryptographic keys from the handshaking process are by the client used to decrypt the response data.
This leads to the ending of the security communication cycle making sure that the information exchanged is encrypted from the sender to the receiver hence enhancing the security of the information exchanged.
Advantages of SSL Passthrough
Enhanced Security
SSL Passthrough helps to sustain the encrypted state from the client to the backend server helping to increase security.
This indicates that the data stays protected from the time it is collected, mapped, encoded, and transmitted to the data recipient without compromise from intermediaries.
In this way, organizations can ensure the decoding of data only at the backend server, which stores the SSL/TLS certificates, thus leaving little room for security cracks.
Reduced Load on Intermediary Devices
One more advantage of the SSL Passthrough method is to bring less processing load to the load balancer or proxy server as the SSL connection does not need to be decrypted and re-encrypted by these intermediary devices.
This in turn can lead to improved performance and overall decrease in latency due to relieving the computational load of the encryption and decryption of data at the backend servers.
This is due especially when there is a large number of clients and the necessity of serving all of them within a limited time is essential.
Simplified Certificate Management
With this SSL Passthrough, SSL/TLS certificates are configured only on backend web servers.
This centralization is beneficial when it comes to managing certificates since it is only necessary to update the certificates on the backend rather than near intermediate devices.
Also Read: Manual vs Automated SSL Certificate Management
This can save a lot of time and prevent fuss with certificate renewal, updates and security policies compliance.
Disadvantages
Complexity in Backend Configuration
The disadvantage of SSL Passthrough is that it requires the backend servers configuration which was a simple process when the proxies were configured.
Because the SSL/TLS certificates are hosted by backend servers, system administrators will need to review the configurations of each server that will process encrypted loads.
This can also prove cumbersome especially in large organizations that have many numbers of servers in their network since each server needs to be differentiated and maintained, a factor that incurs an administrative cost.
Limited Visibility for Intermediary Devices
When running SSL Passthrough, the intermediary devices like the load balancer or proxy do not decrypt data. Therefore, these devices have small learning capability of the content of the information being exchanged.
Such an absence of visibility can challenge the possibility of implementing techniques like deep packet inspection, application security schemes, or traffic analysis and monitoring.
This can affect the general security level or even hamper the identification and prevention of risks.
Performance Overhead on Backend Servers
SSL Passthrough merely promotes the redirection of computational responsibility from servers to backends. As this saves the amount of traffic to other devices, it can essentially add a load of overhead to the backend servers especially if it is frequently accessed.
Cryptography algorithms must be processed in backend servers and require adequate computing resources which is another pro that adds to hardware and operational expenses.
SSL Passthrough vs SSL Offloading
Aspect | SSL Passthrough | SSL Offloading |
Definition | SSL traffic is passed through to the backend server without decryption. | SSL traffic is decrypted at the load balancer, with only decrypted data sent to the backend server. |
Decryption Location | Backend server | Load balancer |
Performance | Higher load on backend servers due to SSL processing. | Reduced load on backend servers as SSL processing is handled by the load balancer. |
Configuration Complexity | Simpler, as SSL certificates are managed only on the backend server. | More complex, as SSL certificates must be managed on the load balancer. |
Security | End-to-end encryption maintained between the client and backend server. | SSL termination at the load balancer, meaning decrypted traffic between load balancer and backend server. |
Use Case | Suitable for environments requiring end-to-end encryption. | Suitable for improving performance by offloading SSL processing from backend servers. |
TLS Versions | Supports all versions of SSL/TLS that the backend server supports. | Dependent on the load balancer’s support for SSL/TLS versions. |
Certificate Management | Centralized on the backend server. | Requires certificate management on the load balancer. |
Latency | Potentially higher due to SSL processing on backend servers. | Potentially lower due to reduced SSL processing load on backend servers. |
SSL Passthrough vs SSL Termination
Aspect | SSL Passthrough | SSL Termination |
Definition | SSL traffic is passed through to the backend server without decryption. | SSL traffic is decrypted at the load balancer, and decrypted data is sent to the backend server. |
Decryption Location | Backend server | Load balancer |
Performance | Higher load on backend servers due to SSL processing. | Reduced load on backend servers as SSL processing is handled by the load balancer. |
Configuration Complexity | Simpler, as SSL certificates are managed only on the backend server. | More complex, as SSL certificates must be managed on the load balancer. |
Security | End-to-end encryption maintained between the client and backend server. | SSL termination at the load balancer, meaning decrypted traffic between load balancer and backend server. |
Use Case | Suitable for environments requiring end-to-end encryption. | Suitable for improving performance by offloading SSL processing from backend servers. |
TLS Versions | Supports all versions of SSL/TLS that the backend server supports. | Dependent on the load balancer’s support for SSL/TLS versions. |
Certificate Management | Centralized on the backend server. | Requires certificate management on the load balancer. |
Latency | Potentially higher due to SSL processing on backend servers. | Potentially lower due to reduced SSL processing load on backend servers. |
SSL Passthrough vs SSL Bridging
Aspect | SSL Passthrough | SSL Bridging |
Definition | SSL traffic is passed through to the backend server without decryption. | SSL traffic is decrypted at the load balancer and then re-encrypted before being sent to the backend server. |
Decryption Location | Backend server | Load balancer (initial decryption) and then backend server (final decryption) |
Re-encryption | No | Yes |
Performance | Higher load on backend servers due to SSL processing. | Moderate load as SSL processing is shared between load balancer and backend server. |
Configuration Complexity | Simpler, as SSL certificates are managed only on the backend server. | More complex, as SSL certificates must be managed on both the load balancer and backend server. |
Security | End-to-end encryption maintained between the client and backend server. | SSL traffic is decrypted and inspected at the load balancer, then re-encrypted, maintaining security. |
Use Case | Suitable for environments requiring end-to-end encryption. | Suitable for environments needing to inspect or manipulate traffic before it reaches the backend server. |
TLS Versions | Supports all versions of SSL/TLS that the backend server supports. | Dependent on the load balancer and backend server’s support for SSL/TLS versions. |
Certificate Management | Centralized on the backend server. | Requires certificate management on both the load balancer and backend server. |
Latency | Potentially higher due to SSL processing on backend servers. | Latency is introduced by the initial decryption and re-encryption at the load balancer. |
How to Configure SSL Passthrough?
Configure the Load Balancer in TCP Mode
When configuring your load balancer, make sure to configure it to work in TCP mode. This helps to make sure that the load balancer handles the incoming traffic strictly as a stream of TCP packets with no attempts to examine or decipher what is being transmitted.
The load balancer only relays the encrypted traffic to the proper backend server as per the routing policies governing the load balancer.
Set Up Backend Servers with SSL/TLS Certificates
Obtain the required SSL/TLS certificates for your installation and deploy these certificates on all the backend servers. These certificates will work to decipher the incoming encrypted traffic.
Make sure that every backend server is appropriately set to handle connections of SSL and the appropriate certificates are installed.
Adjust Backend Server Configurations
Ensure that your backend servers accept SSL connections properly. This includes configuring the server software (Apache, Nginx, or IIS) to accept encrypted traffic over the correct ports. Ensure that the server’s configuration conforms with the installed SSL/TLS certificates.
Verify Connectivity and Security
Perform some basic tests to determine if traffic is being encrypted then passed through to the backend servers by the load balancer. Ensure that the backend servers are decrypting the traffic in the right manner to deliver the right contents.
Also, examine for any account or service that might have a security vulnerability or misconfiguration regarding the encrypted connections.
Conclusion
Protect your website with CheapSSLweb and know that it is safe from hackers. Browse through our low cost SSL certificates catalog, designed for your unique business requirements. Enjoy the low prices, reliable protection, and professional service from our support team. Secure your data and promote your website’s reputation right now.