SSL Intercepting Proxys

Question

I have a customer that wants to use intercepting proxy to decrypt all out going traffic. They do not want to use a transparent proxy as a security policy states all out going traffic must be decrypted/intercepted. But my problem is my client verifies who the server and the server verifies who the client is. We do not want to add the customers CA to the server. So is it possible for a proxy going to a specific server to use a client key? By this I mean copy the client key to the proxy so after the intercept happens and the proxy does the encryption to the server with the client key so the server does not know it is talking to the proxy at all.

With SSL intercepting proxies is it possible to re-encrypt traffic after the intercept if you provided the client private key to an intercepting proxy server so the connecting server still thinks the traffic is from the source client cert?

A is the client B is the proxy doing intercept C is the server A -> B -> C

1) Client talks to proxy A -> B

2) B -> B Proxy intercepts and decrypts and then re encrypts with its own cert and then talks to the server

Question Can this re-encryption be done with the client's private key so the Server C things it is talking to the client and not an intercepting proxy?

Answer 1

Yes this is possible. Neither the client nor the server need to explicitly talk to a proxy respectively send packets to the IP address of the proxy.

You just need to place the proxy on network level "between" server and client.

In that situation intercepting proxies operate as "transparent proxy" (see for example mitmproxy ). In this mode you only have to redirect traffic through the proxy, eg by iptables rules.

Of course the client have to trust the certificate used by the intercepting proxy (or as some vulnerable clients do just accepts any server certificate).