For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

grilledcheez_21's avatar
grilledcheez_21
Icon for Nimbostratus rankNimbostratus
Sep 15, 2015

Maintain client data after SSL Handshakes

Hello,

Wondering if someone can help me out. Running some pretty old apps that we are now load balancing. Trying to implement some SSL security. It looks like the handshakes are working just fine, data is going through and coming back, but server side is only returning errors.

It seems that when F5 sends the packets to the server side, from client, it changes the certs Common Name, CN. Our application requires the CN name to be maintained when passing the traffic through F5 to the servers as the name also tells the application what function to perform.

So when the client sends traffic, it's certs have these names (example: ACE, CASH, and FORM). So when the client authenticates on the front end of the F5, that works, but the VIP cert we have on the F5 uses the Common Name from it's cert, which is GEO.WIP.MRE, which the server on the back end does not recognize as a function.

The server sees this:

$$$ Received from the client: geo.wip.mre at XXX.XXX.XXX.XXX:61407; Data: 1234

But what it needs to see if this:

$$$ Received from the client: ACE at XXX.XXX.XXX.XXX:62962; Data: 1234

The app doesn't care what IP address it sees, just as long as that Common Name is maintained.

So my question is, is there anyway to maintain that Common Name through the F5 while using client and server certs?

Thanks.

application delivery
availability
BIG-IP Access Policy Manager (APM)
monitor
performance
security

2 Replies

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Sep 15, 2015

    So to clarify, your clients are passing client certificates to the F5, and those client certificates have key words in the CN values? And you're terminating the SSL at the F5 and re-encrypting to the server? Where is certificate that has the geo.wip.mre certificate?

    How are you collecting this information?

    > Received from the client: geo.wip.mre at XXX.XXX.XXX.XXX:61407
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Sep 16, 2015

    Ah, so what I believe you're doing is what's called PKI "mutual authentication" - essentially an SSL handshake that includes server AND client certificates. You're prompting the user on the client side of the F5 for a certificate, and the server also requires a client certificate on the server side of the F5. The server cert and key that you have in the server SSL profile is what the server is getting.

     

    In short, as long as you're terminating the client side SSL at the proxy, it is not possible to get that client certificate to the server side. Basically, when a client sends its certificate, it also sends a piece of data that is digitally signed with its private key. And so even if you had the client's cert at the proxy, the proxy couldn't send it in the server side SSL because it doesn't have the client's private key.

     

    Another potentially simpler option is to simply send information in HTTP headers from the proxy. You can (and should) still encrypt the server side communications, but modify the server to look in HTTP headers for information, which could very easily contain the user's certificate CN values.