Big-IP: SSL Client Cert Pass Through iRule

You have to understand that an SSL "session" is (generally) between two parties, and the SSL handshake between those two parties sets up all of the cryptography that they'll use throughout that session. In other words, the handshake establishes the keys that are used to encrypt and decrypt data between the client and server. Before talking about "ProxySSL", it's necessary to establish that for an intermediary to communicate inside an SSL channel between the client and server, it must establish two separate SSL sessions: as the server to the client and client to the server. As you pointed out, the proxy can't send the client's certificate to the server because it doesn't have the client's private key. More specifically, during the SSL handshake the client sends a CertificateVerify message that is a) a hash of all previous messages (which would technically be between it and the proxy), and b) the hash is digitally signed by the client's private key. The server couldn't validate that message hash and the proxy couldn't sign it anyway. ProxySSL, if that's indeed what you meant by "proxy SSL" is a special SSL man-in-the-middle function that, with knowledge of the server's private key and an RSA-based key exchange, can silently (non-interactively) "watch" the actual key exchange between the client and server, collect the client's random number, the server's random number, and decrypt the premaster secret with the server's private key to arrive at the same shared master secret key. With that the proxy can decrypt and re-encrypt the bulk symmetric crypto between the parties without either knowing it. The most important thing to understand here is that the proxy has no control over the handshake process, and that's where certificates are exchanged. To put it more bluntly, BIG-IP SSL events (like CLIENTSSL_CLIENTCERT) do not get triggered inside of a ProxySSL session because the BIG-IP is not a party to any of the handshake. ProxySSL will certainly allow the client to pass its certificate to the server, directly. But it does not allow the proxy itself to collect the certificate.

That said, it is completely non-trivial but certainly possible to collect the client's certificate in an initial handshake using OSI layer 4 events. The client's Certificate message is sent in cleartext in an initial handshake, but encrypted in renegotiation handshakes. You'd be digging in binary data, but once you had it you could then push it out to the server in, for example, and HTTP header.

do you mean to say that this would be the default behavior with ProxySSL enabled?

That's absolutely the behavior. In all reality, not performing any SSL on the BIG-IP (no client and server SSL profiles) will allow the same thing. The client and server will negotiate the SSL session directly. ProxySSL allows you to, with caveats, look inside the SSL payload after the handshake, and potentially act on the layer 7 data (ex. inspect requests/responses, insert cookies, perform intelligent load balancing persistence, etc.). The caveats are substantial, however. As I alluded to earlier, ProxySSL (and all SSL man-in-the-middle products for that matter), rely on an RSA key exchange and knowledge of the server's private key. The master secret key derived in the RSA key exchange comes from three values: the client's random number, the server's random number (both transmitted in the clear), and a "premaster secret" created by the client, encrypted with the server's public key, and sent to the server. It's the knowledge of the server's private key that allows the SSL man-in-the-middle to decrypt that third piece of data and derive the same shared master secret. The other key exchange protocol, Diffie-Hellman (actually a key "agreement" protocol) does not send any encrypted data across the wire, so an SSL man-in-the-middle does not work. It just so happens that Diffie-Hellman (DH), or at least the ephemeral version of DH (DHE), and its derivation, Elliptic Curve Diffie-Hellman (ECDH and ECDHE) are becoming the preferred key exchange/agreement protocol. RSA generally lacks the ability to be ephemeral and thus doesn't support Perfect Forward Secrecy. In short, browser and OS vendors are now prioritizing DHE/ECDH/ECDHE over RSA, and the next version of TLS (1.3) will remove non-perfect forward secret key exchanges altogether. For any SSL man-in-the-middle to work, you must somehow force the client and server to negotiate with RSA, which is sometimes not even possible. The ProxySSL feature will, if configured to "bypass", simply ignore SSL sessions that negotiate with anything other than RSA.