Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Proxy SSL and ECC ciphers

So I know that currently Proxy SSL does not support anything other than RSA key exchanges. I don't know if anyone had found any other way to do certificate authentication on the web server while still maintaining ASM inspection. I have an application where we have been restricting it down to RSA key exchanges only in order to use Proxy SSL so that the client cert could still pass to the web server but we could keep ASM inspection of the content. Now we have an issue where we need to turn on ECC ciphers, which will break Proxy SSL inspection and possibly force us to completely bypass ASM inspection. I would prefer not to bypass ASM but not seeing a way around it right now. Any help would be appreciated. Thanks.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

It's not a function of ProxySSL, but of ANY SSL man-in-the-middle technology. Without getting into the details, ECC is generally deployed with the Diffie-Hellman key agreement protocol, which does not use the server's public and private keys to encrypt anything in the initial handshake. SSL MITM relies on the RSA key exchange, because the server's public key is used to encrypt the third piece of the master secret between the client and server (the other two pieces are relayed in the clear), so anyone with access to the server's private key and a copy of the message can decrypt and access the encryption keys.

0
Comments on this Answer
Comment made 26-Jul-2016 by Mike Maher 410

Kevin, Thanks for the reply, I guess what I am looking for is if there is a solution to inspection traffic and pass client authentication via certificate down to the server. In standard SSL decryption setup there does not appear to be a way to have the Big-IP include the client certificate in the hand shake down to the server.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

In standard SSL decryption setup there does not appear to be a way to have the Big-IP include the client certificate in the hand shake down to the server.

And this is a function (not a limitation) of SSL mutual authentication. The client's certificate is followed in the SSL handshake with a CertificateVerify message that is digitally signed (encrypted) with the client's private key. It is for this reason that you cannot decrypt and re-encrypt traffic between client and server in a mutually authenticated SSL session, because the proxy would not have access to the client's private key to reproduce this message. ProxySSL allows it to work because it is not an active member of the handshake. It silently watches the handshake, gathers the two cleartext random values, and decrypts the third random value with a copy of the server's private key, so that it can create the same master secret and silently decrypt and re-encrypt the bulk encrypted traffic. And since Diffie-Hellman doesn't encrypt anything in the handshake, it cannot be used with ProxySSL.

Currently, a reasonable solution would be to decrypt the traffic and pass an alternative credential to the backend server. This is something that APM (Access Policy Manager) does very well, or you could simply pass the server an HTTP header in re-encrypted traffic.

0