How Proxy SSL works on BIG-IP

1. Lab Scenario

Lab test results:

Client completes 3-way handshake with BIG-IP and BIG-IP immediately opens and completes 3-way handshake with back-end server
Upon receiving Client Hello on client-side, BIG-IP immediately sends Client Hello on server-side as it is
BIG-IP copies same cipher suite list seen on client-side Client Hello to server-side Client Hello
BIG-IP ignores what is configured on both Client SSL or Server SSL profiles.
As soon as BIG-IP receives Server Hello it confirms two things:
Is RSA the chosen key exchange mechanism in Cipher Suite on Server Hello message sent from back-end server?
Does Certificate sent by back-end matches the one configured on Server SSL profile on BIG-IP?
ONLY if both conditions above match BIG-IP proceeds with handshake.
Otherwise, BIG-IP sends a Handshake Failure (Fatal Alert) to both Server and Client with reset cause of illegal_parameter
BIG-IP copies same Server SSL/Back-end Server certificate to Certificate message sent to Client on client-side
BIG-IP completely ignores certificate you configured on Client SSL. It always uses the same server-side certificate.
Assuming TLS handshake completes successfully BIG-IP is able to decrypt all client-side as well as server-side data which is the whole purpose of Proxy SSL.

2. How Proxy SSL works

When Proxy SSL is enabled, BIG-IP does its best to match client-side to server-side connection in terms of negotiation and traffic to make it as transparent as possible to both client and back-end server and at the same allowing BIG-IP to decrypt traffic.

About data transparency

BIG-IP achieves transparency by copying whatever client and server sends back and forth.

About data decryption

BIG-IP has an extra configuration requirement for Proxy SSL configuration (according to K13385) that you should add the same certificate/key present on the back-end server to Certificate/Key fields on Server SSL proxy of BIG-IP. This way BIG-IP can decrypt both client and server sides of connection.

In practical terms and to achieve this, BIG-IP completely changes the original purpose of Server SSL Certificate and Key fields. Here's my config:

Certificate/Key fields above are no longer used for the purpose described in K14806, i.e. to independently authenticate BIG-IP to back-end server through Client Authentication. Instead, when Proxy SSL is enabled it is used to validate if Certificate sent by back-end server is the same one in this field. If so, BIG-IP also copies this certificate to Certificate message sent to Client on client-side.

Notice that when Proxy SSL is NOT bypassed Certificate configured on Client SSL profile is never used.

As soon as I sent first request to Wildcard forwarding VIP BIG-IP establishes TCP connection on client-side first and then immediately on server-side:

The next step is to forward exactly the same Client Hello we receive from Client on client-side to Server on server-side:

Now server sends Server Hello:

The first thing BIG-IP checks is key exchange mechanism as Proxy SSL has to use RSA (frame 12):

Now BIG-IP checks if Certificate inside Certificate message is the same as the one configured on Server SSL.

In this case I have used Certificate's unique serial number to confirm this.

On BIG-IP:

Now on Server's message (frame 12):

Now BIG-IP sends this same certificate in Server Hello message client-side and we can confirm from Serial number that it is the same:

From this moment handshake should complete successfully and BIG-IP is maintaining 2 separate connections using the same certificate/key pair on client and server side with the ability to decrypt both.

3. Troubleshooting Proxy SSL when BIG-IP is the culprit

Typically, if BIG-IP is the culprit it either because back-end server selected non-RSA key exchange cipher or because cert/key which are not supported.

In another test I used DHE on purpose and BIG-IP resets connection immediately after Server Hello message is received from back-end server which is typical sign of validation error:

I confirmed back-end server had selected ECDHE key exchange cipher which is not supported by Proxy SSL (frame 12):

In case you don't know yet here's how you work out key exchange cipher:

Disabling non-RSA cipher on back-end server did the trick to fix the above error as Proxy SSL only supports RSA key exchange.

4. Setting Up Proxy SSL on BIG-IP

I used very minimal configuration for this lab and the only thing I did was to create a wildcard forwarding virtual server using Standard VIP:

I enabled proxy-ssl on both Client and Server SSL profiles and added back-end server certificate (ltm3.crt) and key (ltm3.key) to Server SSL profile:

I also disabled (EC)DHE and explicitly configured RSA as key exchange mechanism in my back-end server.

I also confirmed back-end server was also using ltm3.crt/ltm3.key as it must match the one configured on Server SSL profile:

And it all worked fine:

Published Sep 04, 2019

Version 1.0

Was this article helpful?

12 Comments

dragonflymr
Cirrostratus
Sep 04, 2019
Hi,
Just to be 100% sure. For Proxy SSL scenario described any key/cert can be set in Client SSL Profile - like default?
Piotr
Rodrigo_Albuque
MVP
Sep 04, 2019
Hey Piotr

In my lab test, BIG-IP completely ignored the key/cert on Client SSL profile. It forwarded the Client Hello sent from test client machine to server and the Certificate I see on Server Hello, Certificate message was the same pre-configured on Server SSL profile (Certificate) which matched exactly the one on the Back-end Server.
dragonflymr
Cirrostratus
Sep 04, 2019
Thanks, did you test with same key/cert set in Client SSL Profile as in Server SSL Profile or you used different in Client SSL Profile - from your reply I assume that different was used for Client profile? If so then it safe to just set anything in Client SSL Profile.
Rodrigo_Albuque
MVP
Sep 04, 2019
Key/cert in Client SSL profile is NEVER used in Proxy SSL. It is completely ignored.
Saravanan_M_K
Employee
Sep 05, 2019
one small typo in the line:

Assuming 3-way handshake completes successfully BIG-IP is able to decrypt all client-side as well as server-side data which is the whole purpose of Proxy SSL.

It should be:

Assuming TLS handshake completes successfully ...
Saravanan_M_K
Employee
Sep 05, 2019
One small typo in the Cipher Suite format diagram.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The hashing function in the cipher suite represents either MAC or PRF (Pseudo Random Function) depending on the cipher. For AES_GCM, it represents PRF, because AES_GCM is an AEAD cipher which has inbuilt MAC functionality called GHASH. Thus it does not need a separate MAC algorithm.
Saravanan_M_K
Employee
Sep 05, 2019
Just to be more accurate, the below sentence:

Disabling DHE cipher on back-end server did the trick to fix the above error.

can be modified to:

Disabling non-RSA key exchange on back-end server did the trick to fix the above error. (since proxy SSL only support RSA key exchange)

(non-RSA: DH, DHE, ECDH, ECDHE, PSK, etc.)
Saravanan_M_K
Employee
Sep 05, 2019
Excellent article covering all points to setup a proxy SSL on BIG-IP. Thank you very much for taking the time to write it and share with others. I thoroughly enjoyed reading this.
Rodrigo_Albuque
MVP
Sep 05, 2019
All typos have been corrected. Thank you Saravanan!
Eric_Chen
Employee
Sep 05, 2019
Typically I see Proxy SSL for cases where the BIG-IP needs to proxy a client certificate authentication (mutual TLS). You mention the requirement for RSA key exchanges; that is not ideal to not be using ECC ciphers. Hopefully we'll see a follow-up article talking about C3D and the virtues of being able to re-generate a new client certificate that is trusted by the backend server as an alternate method to achieve the same end goal. Nice article!