SSL-pass-through and redirect to different pool based on URL

Hypothetically speaking, you want a client to access an SSL VIP with a client SSL profile that sends traffic decrypted to an application. At some point a user will request a special URI, at which point you want to remove the client SSL profile and have the client talk SSL directly to another node/pool, which will coincidentally request a client certificate.

 

 

So, the first issue is that SSL comes before HTTP. You can't just drop the client SSL profile in the middle of an HTTP request because by then it's too late. You'd necessarily have to close the connection and have the user come back and start a new one. This is easy enough to do with the HTTP::respond command and a Connection: Close header; but then you run into the biggest problem of all: state. Unless you're on a network where you can absolutely guarantee the uniqueness of client source IP addresses, your primary means of maintaining state with a web client is via layer 7 methods. So at the point the user makes a new TCP connection with the VIP, long before layer 7, how do you know whether to terminate SSL or pass it through? Again, unless you can rely on that client IP address, you can't really know.

 

 

Your second option, redirecting to another VIP, is actually more achievable, but because you're requesting the client certificate at the server, you still have to worry about state. Assuming you want the user to come back to the first VIP after successfully authenticating through the SSL tunnel VIP, you need a way for the application to be able to communicate (through the client) to the first VIP. They'll necessarily be two different DNS names, so you'll have to think about methods like domain cookies, encrypted query strings (or POST data), or unique tokens and some reach-back mechanism to validate the token. This last one is similar to the way SAML service providers (SP) validate the responses from SAML identity providers (IdP) by way of validating digital signatures.

 

 

Another option entirely would be to let BIG-IP do the heavy lifting. You're already terminating the SSL, and can certainly at any point force renegotiation and require a client certificate (as in at the request of a special URI). And once you have the client certificate you have all of that cool X509 data that you can do anything you want with - like pass to the server as HTTP headers. If you add the Access Policy Manager module to the mix, then that process gets even easier, and you can do things like check certificate revocation (OCSP,CRLDP), and pre-authenticate the client against a directory service.