5

I'm facing an unusual situation, I hope you can clarify this for me.

We manage some applications that are accessible through HTTPS requests on port 443 of our server X.

We have a new client that is also supposed to reach us through our 443 port on server X. However the client is going to use some kind of Load Balancer (proxy + snat according to them) to do that.

So that the Load Balancer can connect to us, the client is requiring our pair of Public Certificate + Private key, otherwise the Load Balancer would reset connections with us due to key pairs mismatch.

This is completely nonsense for me as the private should be simply private, I can't share it. It is against every security policy I know.

Curious part is that they provided some documentation that seems to state exactly this. This is the link:

https://support.f5.com/csp/article/K13393

It seems they use some technology called Big IP and it requires the private key according to this statement on the above link:

Recommended Actions You can rectify this error by configuring the affected SSL profiles with the certificate key pair that is presented by the destination server. To do this, perform the following procedures ...

Has any one you faced any similar situation to this?

Even their technology really requires it, I'm not aware about any 'API' provided by HTTPS that would handle traffic previously ciphered by a Load Balancer, so I'm pretty confuse.

Every kind of clarification is useful. Thanks everyone.

vinicius.olifer
  • 53
  • 3
  • Big IP is usually implemented by the server operator, and in that case would need private keys - it's generally configured as an SSL terminator. I'm not sure why a client would load balance their traffic to you though... – Matthew Jul 21 '17 at 14:14
  • This is the flow: Client --> Load Balancer --> Our Server X. So the Load Balancer is server for the Client and, at the same time, client for our server. – vinicius.olifer Jul 21 '17 at 14:17
  • @Matthew They're most likely proxying so they can inspect and cache. – Xander Jul 21 '17 at 14:17
  • 1
    @Xander But in that case, they could MitM the traffic with their own cert, and it can re-encrypt at that point. – Matthew Jul 21 '17 at 14:19
  • 1
    @Matthew I'm fairly certain the Big-IP does not offer that capability, as it's not designed for that particular use case. Or even the option to take advantage of say, a Bluecoat on the Internet-side, as I believe each site has to be manually set up in the F5. – Xander Jul 21 '17 at 14:27
  • @Xander. F5 bigip are capable of MitM for load balancing and even presenting different certificates based on the client's ip address. What Matthew suggest can be achieved pretty easily with F5 and is the only acceptable solution in this case. – NuTTyX Jul 28 '17 at 16:13
  • @NuTTyX Do you have a link toy he documentation for that? I couldn't find it, at least not as far as this feature is concerned. – Xander Jul 28 '17 at 16:31
  • https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_http_ssl.html Basically they should change the proxyssl setting for a full interception configuration: a client profile using their own "forged" certificate and a server profile trusting your certificate's CA. – NuTTyX Jul 28 '17 at 17:50

1 Answers1

5

It appears they're using the F5s SSL Proxy capability, which means that the F5 appliance isn't your application's client (they're not terminating at the appliance, but passing through) but instead gives them the ability to decrypt the the traffic to determine if if can be cached and re-used to improve performance. E.G., if they can cache some things at their edge, they can serve it back to their users without having to make additional full round trips back to your origin servers. If they can't decrypt the traffic, they can't cache it.

This, as you clearly know, has security implications. If they insist on this architecture, and the data and risk are theirs and theirs alone, then you need a certificate specific for their application that is not shared to protect the data of any of your other customers. You can then install the cert on the application servers you host for them, and they can install it on their F5, and as long as their is no opportunity for the cert to accidentally be used for your other customers, then there's very little risk to you.

IF, however, your application is not designed to allow for them to be separated in such a way, and the certificate cannot be isolated for their use only, then in my opinion, you must decline. You cannot give them a key that would allow them to potentially access other customers data under any circumstances.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • Thanks for your clear explanation Xander. Just one piece is missing for me. Once they do the re-encrypt using OUR pair of certificates and send the data for us, how the request would come to our 443 port? Would it be some kind of ciphered request? The main question is: would our private key be used some how in the handshake if our own server? Sorry if it is a naive one, but I'm not much experienced with Load Balancers. – vinicius.olifer Jul 21 '17 at 14:49
  • @vinicius.olifer No worries, and yes, they're not terminating the handshake at the F5, simply taking a peek at the data as it passes back and forth to see if any of it is cachable or can be served out of cache. So, from the perspective of your servers, you're still creating a TLS session with the real client on the other side of the F5, using your keys. – Xander Jul 21 '17 at 14:55
  • Now I got it. The most correct way to do that is by implementing a MITM described by above by Matthew. But as you said, the BigIP does not have this feature, that is why it require this crazy thing (In Brazil we call it gambiarra ;D). In our current design, all the APPs shares the same Certificate, so it is really impractical to share the key with them. Thanks Xander and @Matthew. – vinicius.olifer Jul 21 '17 at 15:07