cancel
Showing results for 
Search instead for 
Did you mean: 

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

0151T000003d7eRQAQ.png

 

0151T000003d7eUQAQ.png

 

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: 

0151T000003d7eVQAQ.png

 

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:

0151T000003d7eWQAQ.png

 

We can see there are 2 Certificates:

0151T000003d7eXQAQ.png

 

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:

0151T000003d7eYQAQ.png

 

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):

0151T000003d7eZQAQ.png

 

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:

0151T000003d7eaQAA.png

 

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:

0151T000003d7ebQAA.png

 

Subject fields, which shows information about the current certificate, is copied and identical to information on server1.crt:

0151T000003d7eSQAQ.png

 

And finally, the public key is copied from cert field (ltm2CA.crt).
Notice they are the same:

0151T000003d7eTQAQ.png

That's enough information for now.

Comments
Nicol4s
Nimbostratus
Nimbostratus

Hello,

According to F5 TAC, the SSL Forward Proxy module is soon to be deprecated.

TAC will not accept any case regarding this feature.

 

Any tips for your customers regarding this statement ?

 

Thanks.

LiefZimmerman
Community Manager
Community Manager

  - I asked around and the only touch-point I was referred to was this F5 Support article - https://support.f5.com/csp/article/K81031320

 

I scanned it and don't see any proper 'tips' per your request.

I do see details around how long Support will continue in the "Technical Support" section there.

 

What sort of tips or advice are you interested in?

Version history
Last update:
‎16-Apr-2019 07:07
Updated by:
Contributors