What is SSL bridging; how do I also encrypt the traffic to the backend?
Short answer
In SSL bridging, the client's TLS connection is first terminated on TR7; TR7 sees and processes the content, then forwards it to the Backend Service with a new TLS connection that it establishes itself. Both connections are encrypted, and WAF and actions continue to work. In TR7, it is not a separate option: an encrypted frontend with Certificate on the vService and SSL Service on the Backend Service are used together; the address of the Backend Service must point to the TLS port of the server. The server's certificate is not verified by default; for verification, Certificate Verification = Required and a Verification CA Profile are selected.
Background
In a load balancer working as a reverse proxy, the traffic passes through two separate connections: between the client and the load balancer, and between the load balancer and the server. Whether these two connections are encrypted is independent of each other. Bridging (re-encryption) is the termination of the TLS in the first connection on the load balancer and its re-establishment in the second connection; the load balancer sees the traffic decrypted for a short time. In passthrough, on the other hand, TLS is never terminated and the content is not seen.
Problem: The Encryption Ends on TR7 and Does Not Reach the Server
In the default configuration (offloading), the traffic arrives encrypted up to TR7 and goes unencrypted from TR7 to the Backend Service. If TR7 and the servers are in the same secure network segment, this is sufficient in most setups. However, if there is a shared network, another data center or a cloud provider's network between TR7 and the servers, if regulations require that the traffic never flows unencrypted at any point, or if the server opens only the TLS port, the TR7–server connection must also be encrypted.
| Offloading | Bridging | Passthrough | |
|---|---|---|---|
| Client ↔ TR7 | Encrypted | Encrypted | Encrypted |
| TR7 ↔ Backend Service | Unencrypted | Encrypted (TLS established by TR7) | Encrypted (the client's TLS) |
| Does TR7 see the content | Yes | Yes | No |
| Where is the certificate | TR7 | TR7 and server | Only the server |
Solution
Bridging is configured on two objects: SSL Service is turned on on the Backend Service, and TLS is terminated in the frontend row of the vService. The other TLS fields on the Backend Service are optional; they are used only if the server has a special requirement or if the server certificate will be verified.
Bridging with SSL Service
- How it works On the encrypted frontend of the vService, TLS is terminated on TR7; TR7 establishes a separate TLS connection to the Backend Service on which SSL Service is on.
- Where it is openedLoad Balancer → Backend Services → Edit → SSL Service · vService → Frontend → Protocol + Certificate
- Requirement A port listening for TLS and a certificate on the servers; a certificate for the vService on TR7
- vService type HTTP (Encrypted (HTTPS) protocols), L7 TCP (TCP + TLS)
- Area of effect SSL Service is a setting of the Backend Service; the traffic of all the vServices that use that Backend Service is forwarded encrypted.
Step-by-Step Configuration
If the certificate to be presented on the vService does not exist on TR7, Add is clicked on the Certificates & PKI → SSL/TLS Certificates screen (how to add).
The Certificate Name is entered; Type = Manual or PFX is selected and the certificate and key are entered (How do I upload my certificate to TR7; which formats are supported?).
Add at the bottom of the form is clicked.
On the Load Balancer → Backend Services screen, the Backend Service is selected and Edit is clicked.
The port in the Address field is made the port on which the server listens for TLS (e.g. 192.0.2.21 : 443). If the port stays on the plain HTTP port (e.g. 80), the TLS connection cannot be established.
The SSL Service switch is turned on (off by default). The fields that configure the TLS connection appear below it; none of them needs to be changed for bridging:
| Field | Default | When it is changed |
|---|---|---|
| Ciphers | Standard | Low only for servers that require old cipher suites |
| SNI | Empty (SNI is not sent) | If the server presents more than one certificate on the same address (I need to send SNI when connecting to the backend; how do I set it up?) |
| ALPN | Empty | HTTP 2.0 Enabled if HTTP/2 will be spoken with the server |
| Backend SSL Security Profile | None | A TLS Security Profile if the TLS version and cipher list will be restricted on the server connection |
| Certificate Verification | None | Required if the server's certificate will be verified (step 7) |
| Client Certificate Presented to Backend (mTLS) | None | If the server requests a client certificate from TR7 |
Certificate Verification = Required is selected; in the Verification CA Profile field that appears, the Certificate Authorities (CA) record of the CA that signed the server certificate is selected. If no CA profile is selected, no verification is done. For the name in the certificate to be checked as well, the name of the server is written in the SNI field; the SNI field is applied only on an HTTP vService (Can I verify the backend certificate when connecting to the backend over HTTPS?).
Edit at the bottom of the form is clicked. As soon as it is saved, TR7 starts connecting to this Backend Service with TLS; all the vServices that use the Backend Service are affected. Steps 4–8 are repeated for each Backend Service.
On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.
On an HTTP vService, Protocol = HTTP/2 or HTTP/1.1 from the Encrypted (HTTPS) group is selected in the frontend row, and on an L7 TCP vService, Protocol = TCP + TLS is selected; the certificate is selected in the Certificate field that appears. The Backend Services from steps 4–8 must be selected in the Default Backend Services table.
Save is clicked. In a cluster setup, with the default auto-sync, the changes are also sent to the peer device; if Manual Sync Mode is on, they are sent to the peer device manually.
If a Health Check profile of the HTTP type is used on the Backend Service, the Check Type value of the profile is made HTTPS, since the server now listens for TLS; otherwise, the server may appear unhealthy.
Verification
The content of the traffic coming from TR7 is captured on the server.
Command: tcpdump -A -nn -i any port 443
The request line and headers cannot be readGET /... HTTP/1.1 are seen, SSL Service has not been turned on, or the traffic is coming from another port.The health status is checked in the Load Balancer → Backend Services list; the site is opened from a browser.
The Backend Service is healthy, the page opensCommon Mistakes
SSL Service is not verification
SSL Service encrypts the connection but does not check the identity of the server. Certificate Verification is None by default; a connection is established even with a certificate that has expired or belongs to another name. If end-to-end trust is needed, a Verification CA Profile is selected together with Required; if Required is left without selecting a profile, no verification is done.
- Turning on SSL Service while the server listens for plain HTTP. SSL Service defines the language the server speaks: if the server listens for plain HTTP on 80, it is not turned on; if it listens for TLS, it must be turned on. A mismatch breaks the connection in both directions.
- Thinking that SSL Service will affect only one vService. The field is a setting of the Backend Service; all the vServices that use the same Backend Service start connecting encrypted.
- Mistaking bridging for passthrough. In bridging, TR7 decrypts the traffic, and WAF, conditions and actions work; in passthrough, TLS is never opened (What is SSL passthrough; when should I use passthrough instead of termination?).
- Expecting a performance gain from bridging. The traffic is decrypted and re-encrypted on TR7, and the server also processes TLS; the server load gain of offloading does not exist in bridging.
How it is done in the documentation
