Related articles: SSL Legacy Renegotiation vs Secure Renegotiation Explained using Wireshark
Summary
The idea behind this feature is to allow BIG-IP to sniff into SSL connections to any Internet destination that goes through it whilst preserving client's trust of the destination. When this feature is enabled, BIG-IP uses a pre-installed CA set under proxy-ca-cert (CA Certificate in the GUI) that is also trusted by client's browser and BIG-IP pretends to be the Internet destination by re-signing SSL certificates on the fly with the aforementioned CA and using public key from CA configured under cert on BIG-IP. The client trusts the connection and is unaware of BIG-IP's presence. The most common use case is Secure Web Gateway (SWG), although neither APM nor SWG are needed to deploy SSL Forward Proxy functionality. LTM is enough.
Lab Scenario
Lab test results:
- Client opens connection with BIG-IP and sends Client Hello.
- BIG-IP immediately opens connection with web server and completes SSL handshake.
- BIG-IP creates unique certificate with following information and sends it over via Server Hello:
- Serial number: random
- Issuer: copied from default.crt
- Validity: notBefore (copied from server1.crt), notAfter: 30 days counting from time it was generated (configurable via cert-lifespan or Certificate Lifespan in the GUI)
- Subject: copied from server1.crt
- Public Key: copied from ltm2.CA.crt
- All X.509 extensions allowed in cert-extensions-include are also copied from server1.crt to unique custom certificate
- Client-side handshake completes successfully using above dynamically generated custom certificate just created by BIG-IP and data exchange works as expected.
How SSL Forward Proxy works on Wireshark
Actual capture used for below explanation is attached to this article below (and here ssl-forward-sample-3.pcap )
Upon Client Hello sent by Client BIG-IP rushes to open new connection and completes server-side SSL handshake:
Server-side handshake completes on frames 17-18 and and BIG-IP immediately resumes and completes Client-side handshake. Note: The reason why BIG-IP waits for server-side handshake to complete first is because BIG-IP uses server-side certificate information to generate a custom certificate that will be sent to Client on client-side.
The most interesting bit here is BIG-IP's Certificate message sent on frame 20 to Client as it contains the custom Certificate generated by BIG-IP:
We can see there are 2 Certificates:
CA Certificate (proxy-ca-cert) is the Certificate Authority (CA) that signs the newly created custom certificate and is supposed to be trusted by Client to confirm BIG-IP's custom (dynamically generated) certificate can be trusted too.
We can immediately work out that the 2nd certificate is default.crt just by matching its serial number which is unique for each issuer:
However, the first certificate looked a mystery to me until I found where all the pieces came from. The serial number looks randomly generated to me as it doesn't match (not even close to any of the certificates above):
The Issuer field, which shows information about who signed the certificate, shows that default.crt was the one who signed BIG-IP's custom certificate:
Certificate generation date (notBefore) is copied from server1.crt but expiry date (notAfter) is calculated based on cert-lifespan (Certificate Lifespan in the GUI) which by default is 30 days added to time custom certificate was generated:
Subject fields, which shows information about the current certificate, is copied and identical to information on server1.crt:
And finally, the public key is copied from cert field (ltm2CA.crt).
Notice they are the same:
That's enough information for now.
