SKUDONET Enterprise Edition 10.3.0 is now available and brings a new farm type: TCP SSL. It extends SSL/TLS termination to TCP-based services, not just web applications. Clients open an encrypted connection to SKUDONET, which handles the TLS session and passes the traffic on to the backend servers without parsing the Layer 7 protocol.
What TCP SSL Adds
SKUDONET already offered HTTP/HTTPS farms and L4xNAT. The HTTPS farm terminates TLS and also understands HTTP, which is what makes HTTP inspection, cookie management and WAF rules possible. L4xNAT is the lightweight Layer 4 option. TCP SSL adds a new one: TLS termination for non-HTTP services, without any application-layer processing.
Why Terminate TLS at the Load Balancer?
Plenty of applications already support TLS. Supporting encryption is one thing, though, and running it consistently across a production environment is another. Certificates have to be deployed and renewed, TLS settings kept up to date, and application servers may run different software versions or need different procedures to change their security settings. Legacy infrastructure adds one more problem: an older application may have no native TLS support, or may depend on software that is hard to upgrade.
Terminating TLS at the load balancer gives you a single place to manage encrypted client connections. Clients connect to the certificate SKUDONET presents, and the backend keeps receiving the application protocol it already understands. How far that protection reaches depends on whether you use offload or bridge.
How TCP SSL Works
A TCP SSL farm accepts a TCP connection and performs the TLS handshake with the client. Once the encrypted session is up, SKUDONET decrypts the incoming traffic and forwards the application data to the backend. Responses travel the other way: SKUDONET receives the data from the backend and encrypts it before sending it back to the client.
SKUDONET treats the payload as a TCP byte stream. To forward it, TCP SSL doesn’t need to interpret HTTP requests, database queries, mail commands or directory operations. That is what sets it apart from an HTTPS farm: both can terminate TLS, but only the HTTPS farm understands HTTP and can apply features based on what it carries.
“TCP SSL” is just the familiar name for the farm type. Deployments should use supported TLS versions and avoid obsolete SSL protocols.
Offload or Bridge
The connection between SKUDONET and the backend can be set up in two ways.
TLS offload
With TLS offload, SKUDONET presents the client-facing certificate, does the cryptographic work for that connection and talks to the backend over plaintext TCP. It suits backends that can’t handle TLS themselves: an application that exposes a plaintext TCP service can stay as it is while compatible clients connect through an encrypted endpoint on the load balancer.
Since the last segment is unencrypted, plaintext traffic there has to be acceptable in your architecture, and access to the backend should be limited to the intended network paths so clients can’t bypass the encrypted endpoint. In other words, offload protects the connection up to SKUDONET, not the one behind it. It also moves the TLS processing for client connections onto the load balancer, although any performance gain depends on the application, the traffic pattern and the resources available.
TLS bridge
In bridge mode, SKUDONET terminates the incoming TLS session and opens a separate TLS session with the selected backend. The client validates the certificate SKUDONET presents, while on the backend side SKUDONET acts as a TLS client. Traffic is decrypted inside the load balancer and encrypted again, and the two connections have their own handshakes, certificates and negotiated parameters.
So encryption covers both segments, with SKUDONET acting as a trusted termination point between them. It is not one uninterrupted session between client and application. The backend has to support a compatible TLS connection and still does TLS processing for its link to SKUDONET, which means bridge doesn’t fit a legacy service that only works in plaintext. Where the configuration allows it, the backend connection should also authenticate the intended server through certificate and hostname verification.
Bridge Is Not Passthrough
When L4xNAT carries TLS traffic, SKUDONET forwards the encrypted traffic without terminating the session: the backend presents its certificate directly to the client and handles the encryption and decryption itself. In bridge mode, the client establishes TLS with SKUDONET, and SKUDONET opens a second connection to the backend. The difference decides where certificates are managed, where the cryptographic processing happens and which components can see the decrypted application data.
Which Services Fit
TCP SSL suits services that start TLS as soon as the TCP connection opens, known as implicit or direct TLS. Examples include LDAP clients using LDAPS, mail clients using implicit TLS for IMAP, POP3 or message submission, and custom applications whose clients support direct TLS.
Protocols that start in plaintext and negotiate encryption later, such as SMTP with STARTTLS, need extra care: because TCP SSL doesn’t parse the protocol, it can’t carry out that negotiation. Databases need a case-by-case check too. PostgreSQL, for example, traditionally sends a request before the TLS handshake, although newer implementations can support direct TLS negotiation, so you should confirm the client, the connection mode and the backend’s behavior first.
TCP SSL can also serve HTTP services that need TLS termination and TCP load balancing but no HTTP inspection. If your decisions depend on HTTP content, the HTTPS farm is still the right profile.
TCP SSL vs HTTPS vs L4xNAT
A Practical Step for Legacy Infrastructure
Replacing an application and improving the security of its transport don’t have to happen at the same time.
A business-critical service can be hard to modify because of vendor dependencies, operating system constraints or integration requirements. If its client connection model is compatible, TCP SSL offload lets administrators add encrypted access while keeping the existing backend application.
That protects against interception and modification of traffic on the client-facing connection. Application authentication and authorization, patching and backend network controls remainnecessary parts of the design necessary parts of the design.
