on 04-Sep-2019 04:04
Lab test results:
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.
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.
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:
Hi,
Just to be 100% sure. For Proxy SSL scenario described any key/cert can be set in Client SSL Profile - like default?
Piotr
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.
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.
Key/cert in Client SSL profile is NEVER used in Proxy SSL. It is completely ignored.
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 ...
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.
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.)
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.
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!
Hi Rodrigo, thanks for sharing detailed insight about working of Proxy SSL.
Simple n Great !!!