I’m looking for a mutual TLS (2-way TLS) reference architecture document showing flows from client via Big-IP LTM to server.
I need to have defined external client connections authenticate with a Big-IP before been handed off to an internal web server. Internal client to Big-IP then onwards to an external web server would also work (I’d just reverse the logic).
K12140946 has been useful, but I need the same with a Big-IP in the middle.
TLS is normally done by certificates. So you'd need a cert on the VS and one on the client. And you can then tell the server config to enforce the trust,
The normal issue here is managing and maintaining the certificate on the client's.
It can also be done between f5 and the web servers, as there internal and fixed that's normally a little easier! Just make sure the certs are kept up to date otherwise they'll all die! Normally worth renewing each certificate at last a week a part on each web server to try to manage that.
thanks for the reply. I know I need certificates, but what I'm looking for is a reference architecture that shows flows, where the certificate is used, what type of certificate is used, etc.
K12140946 is a good place to start. The BIG-IP is a full proxy, so the client mTLS would be terminated there (client = client, BIG-IP = server), and the the BIG-IP would initiate a completely new TLS connection to the backend server (BIG-IP = client, server = server).
As for handling mutual TLS, there are a few options:
Perform mTLS on the client side to the BIG-IP, and (optionally) perform normal TLS to the backend server. Aside from the C3D option described below, it is otherwise not possible to decrypt mTLS between a client and server. During the mTLS handhshake, the server will request a client cert, the client will abide, and then shortly after send a "signature". This signature is hash made up of the TLS handshake recorded up to that point, and then encrypted with the client's private key. The server receives this, and assuming it trusts the client's public key (in the certificate), with generate it's own hash, decrypt the client's hash with the client's public key, and then compare the two hashes to verify that the client is who it says it is. It is by virtue of the signature data encrypted with the client's private key that makes it (virtually) impossible to decrypt a mTLS handshake, because no other device would have a copy of the client's private key in order to recreate the signature hash on the server side.
Perform mTLS on the client side of the BIG-IP and mTLS on the server side with a different cert/key. This server side pair would be manually installed on the BIG-IP. This doesn't do a lot for identifying individual client's, but can satisfy a simple server side mTLS requirement.
Perform "proxy ssl" with RSA handshakes. This is arguably the worst idea, but it does work. In the era of RSA handshakes, before forward secrecy and TLS 1.3, it was possible for a middle box, with access to the server's private key, to silently record and decrypt TLS handshakes out-of-band. You'd have to force an antiquated RSA handshake on all parties, but in doing so you could indeed passively decrypt the payload between the client and server without breaking the mTLS between them.
Perform client cert forging with Client Certificate Constrained Delegation (C3D). This is where you perform mTLS on the client side of the BIG-IP, pull the important pieces from that certificate, and use these to issue/sign a new client certificate on the server side. Unlike using a static cert/key, you can dynamically insert the real client cert properties (ie. CN, SAN, policy values, extensions, etc.). C3D will also let you insert arbitrary values as the BIG-IP, sort of like the Kerberos PAC data, where you could insert additional metadata about the client and/or environment that the server could use to further validate the client auth.
