TLS Policy Split for Legacy Java Kiosks and Modern Clients
A retail company terminates TLS for storefront.example.com on a BIG-IP virtual server at 10.10.20.10:443. Analytics show 18% of sessions come from an internal Java 6 kiosk application that offers only TLS 1.0 with RSA ciphers (for example AES128-SHA). The other 82% are mobile and web clients that now expect TLS 1.3 and ECDSA certificates. Corporate security policy forbids TLS 1.0 on any externally reachable VIP and will audit compliance in 30 days. The kiosk fleet cannot be upgraded for 90 days, and the application team cannot change code this quarter. The application servers record the client IP for audit, so the original source address must reach them. There is one public DNS name today; network engineering can allocate a second public IP and create another VIP. The backend pool is shared and healthy. The current client SSL profile is a single default profile with TLS 1.0-1.2 and an RSA certificate.
1. Security proposes disabling TLS 1.0 on the existing client SSL profile. Explain what happens to the kiosk clients and why SNI-based profile selection alone does not solve the problem.
Read the worked answer
Disabling TLS 1.0 changes the minimum protocol version in the client SSL profile. The kiosk ClientHello advertises TLS 1.0 and does not include a supported_versions extension. The BIG-IP rejects the handshake with a protocol_version alert (alert 70); it does not fall back to TLS 1.2 because the client cannot offer it.
SNI does not rescue this by itself. SNI selects a certificate and profile by the server_name extension, but the kiosk client must actually send SNI and must still offer an acceptable protocol version. Many Java 6 stacks omit SNI or send it inconsistently. With one VIP and one default profile, a non-SNI or TLS1.0-only ClientHello lands on the default profile and fails. The split therefore has to happen at the VIP/IP boundary, not only in certificate selection.
2. Design a compliant solution using the second public IP. Include VIP, profile, certificate, DNS and client-IP preservation elements, and state the trade-offs.
Read the worked answer
Create two VIPs on two public IPs, both using the same backend pool:
- Modern VIP on 10.10.20.10 with a client SSL profile limiting TLS 1.2-1.3 and presenting an ECDSA certificate plus an RSA certificate via SNI. Publish this as storefront.example.com.
- Legacy VIP on 10.10.20.11 with a client SSL profile allowing TLS 1.0-1.2 and an RSA certificate. Publish it as a separate name such as kiosk.example.com, or distribute a hosts-file entry to the kiosk fleet. Add a source-address restriction so only kiosk subnets can reach this VIP; log any non-kiosk source for audit.
Both VIPs can use an HTTP profile and an iRule that inserts X-Forwarded-For with the client address so the application can audit the original source. Do not SNAT to a translation address if the application truly needs the original source; otherwise the backend sees the SNAT address. The trade-off is two names/certificates and an exception path that security must review, but TLS 1.0 remains off the public VIP.
3. What evidence would you collect to prove that the kiosk failure is protocol-version related rather than a cipher mismatch?
Read the worked answer
Capture the handshake on the client-facing VLAN and read the ClientHello: legacy_version 0x0301 with no supported_versions extension points to TLS 1.0. A protocol_version alert (70) confirms the server rejected the version; a handshake_failure alert (40) would point more toward cipher or certificate mismatch.
Reproduce from a test host with openssl s_client -connect <vip>:443 -tls1 and again with -tls1_2. If TLS 1.0 works only against the legacy VIP and TLS 1.2 fails from the kiosk, the version is the differentiator. Check the client SSL profile with tmsh list ltm profile client-ssl <name> and review SSL profile statistics and handshake alerts. A qkview preserves the profile and logs for the audit.