Question. I'm a software developer. I design and write secured systems for my customer. My customer recently downward directed that all traffic to/from my server be routed through a new appliance. I have no idea what the appliance is. All I was told was that it would impact routing and client certificates. I was given the name of a person to work with and off we went. We use client certificates for authentication and all traffic to/from the server is encrypted. Here is where things get weird. Previously, my server had it's own SSL certificate issued to it's current host name. Now when I hit the site, I see a host name of the new appliance for the site's SSL certificate, not my server's host name. Also. When a client certificate arrives at my server, it is no longer reading as having been issued by who I know to be the original issuer. But there are no negotiation errors during the handshake. Everything is green in the browser.

The only thing that makes any sense is that this appliance is decrypting the traffic from the client before it gets to my server so that it can be logged and inspected, before re-encrypting it and sending it along to my server. Then, when it gets the reply from the server, it likewise decrypts, logs, inspects the data, before re-encrypting it and the forwards the data.

Is my understanding of asymmetric and symmetric cryptography serving me correctly here? Mostly I stick to the logic of my applications and have sufficient understand of cryptography to be able to do what I need to do and ensure my systems remain secure. But I am not intimately familiar with the ins and outs of how it always functions. Seems like my organization just installed an internal man in the middle device for monitoring purposes and didn't tell me what was really going on.

Is this plausible?


Yes, your understanding is correct.

This is a TLS (or any other secure transport protocol) capable proxy. What it does is that it generates site certificates on the fly. You connect to a site through the proxy with your client and it performs a man-in-the-middle, as the TLS connection is setup before anything else.

First it will connect with the remote site, and create a connection with it using the normal server certificate. Hopefully it completely verifies and validates that computer's certificate. So that's taken care of the connection with the remote server.

Now to spoof your connection the proxy must have a certificate for a specific hostname (as Common Name in the certificate). It probably first looks up the certificate in the cache and uses that together with the private key. If it cannot find the certificate it generates a key pair and signs a temporary certificate for it. Then it sets up the connection with your client.

Once it has both TLS sessions running it can act as a normal proxy. Now it can (deep) inspect any data send through the connection in either direction.

Alternatively, it can send a redirect to the client so that it connects to a different hostname. That way it can use a single, long term server / device certificate. Of course your client will have to accept this redirection for the scheme to work.

Of course it is not that easy, as a random certificate will be rejected by your client - there is no certificate chain to a trusted certificate. Basically this can be solved by injecting a trusted CA certificate in your trust store. This can be a Windows trust store, or the trust store of the client application that you're using (e.g. a firefox browser). Usually the certificate is simply pushed using the Windows group policy together with some script for the most common browsers.

The proxy will now act as its own Certificate Authority, signing any certificate it generates using the private key with it's own CA certificate. Once the certificate chain is trusted your client will lite up "green" as it cannot see the difference with any other chain.

Alternatively, the proxy could use a broken (or otherwise controlled) CA, like Iran did with the DigiNotar CA, when it requested certificates for Google.

Of course even deep packet inspection will not be capable of detecting all possible covert channels, so I'll leave it up to you to hack out of the system (with the possible repercussions that come with it).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.