TLS intercepting proxies create fake server public and private keys on the fly and sign them with a root CA. Depending on the software the keys might be cached or regenerated on each new connection.

What would be the security implications of having the (short lived) server key stolen (not the key for the root CA used for signing!)? In the end the key would only be used during the handshake, so it would maybe only be a problem when the key is reused/cached?

  • If you're talking about the authentication key pair (whose public key is in the certificate) the implications of stealing the private key could be serious. Just because the key is normally regenerated does not mean the old keys are necessarily invalid. As long as the certificate is valid it can be used to MiTM connections. A mitigation would be to have very short validity periods for such certificates. Oct 2, 2021 at 23:22
  • @President James K. Polk, its a cert for the domain, the type of cert you would use for cloudfront for example, thanks for info re MiTM connections and mitigations Oct 3, 2021 at 9:15
  • @PresidentJamesK.Polk But that would only be relevant in the client-proxy connection, wouldn't it? An attacker would still need to be inside the proxy, just stealing the key wouldn't be enough? You can't use the stolen server key (or even root CA private key) from some hop upstream i.e. behind the proxy because the proxy itself won't trust the custom root CA normally.
    – airodumb
    Oct 3, 2021 at 12:28
  • @airodumb: Yes, ideally that should be the case. It depends on the how thorough the intercepting proxy is, how many pieces of TLS client software on the client trust the proxy root cert (e.g. mail clients), is the insider threat an issue, and so on. It's possible that an analysis of these issues will conclude that the stolen proxy keypair scenario is not a problem at all. Oct 3, 2021 at 14:49
  • Note that, depending on the scenario, the key being stolen might only be used for a single website, which would mitigate the risk. Oct 3, 2021 at 15:32

3 Answers 3


This really depends on what you are worried about, I think it would be best to separate an internal attacker and an external attacker:

An internal attacker wouldn't have much need for the certificates, if they can pivot around they can get pretty much any information they need. I haven't come across any incident reports where the attacker go after network traffic instead of just "smash and grab" stealing information right there, and credentials from disk or memory. And i can't see much need for it either: if they had foothold in the system, they could probably do their own thing doing targeted TLS interception with something like WPAD + SSLStrip/Polarproxy.

An external attacker with access to the signer certificate could decrypt traffic assuming they have access to a full enterprise pipeline of packet captures (which is a crap load of data, i assure you) with close to zero packet drops. But unless they were capturing all network traffic earlier, they would only be able to decrypt traffic from the time of compromise.

Access to client certificate (with the public key) either installed locally on a device or sent as part of negotiation from the TLS interception proxy really does not help much, you can do trial encryption and compare outputs but that is in the realm of theoretical attacks and not something applicable that an attacker would do.

TLS intercepting proxies are quite valuable for DFIR, I'd say that they are essential today, their usefulness easily outweigh the risks, and some even allow for exceptions can be made for banking sites. But such devices also need to be locked down, not just technically but also physically, so don't place such a device in an open broom closet near the visitors entrance.

But as Angel said: if this scenario happen, you have a much bigger problem.

  • "An external attacker with access to the signer certificate could decrypt traffic" Why? At least with PFS ciphers this shouldn't be possible.
    – airodumb
    Oct 6, 2021 at 14:05

TLS intercepting proxies create fake server public and private keys on the fly and sign them with a root CA.

Actually the intercepting proxy mostly need to generate a new certificate on the fly and can keep reusing the same key pair.

This is for example what mitmproxy does. If you compare the output of these commands,

openssl s_client -connect -servername www.example.com | openssl x509 -text
openssl s_client -connect -servername www.google.com | openssl x509 -text
openssl x509 -in ~/.mitmproxy/mitmproxy-ca.pem -text

(where is the endpoint of the mitmproxy instance), you'll notice that the public key is the same for all websites and is actually the public key of the root certificate as well.

  • So is mitmproxy just using a single keypair altogether? When the public key/cert send to the client is the same as the root CA public key then the server key must be the same as the root CA key? Is this generally the same as when using a multidomain+wildcard certificate for the (proxy)server (signed by a official CA)? Would there be any difference when stealing such a key vs stealing a custom CA key?
    – airodumb
    Oct 4, 2021 at 12:04
  • For mitmproxy (currently), the CA and each intercepted server use the same public key pair (public key and private key). However, a new certificate (containing the same public key) is forged for each server.
    – ysdx
    Nov 5, 2021 at 8:29

So, you have an TLS intercepting proxy and the private key for their stackexchange.com (fake) certificate is stolen. What could happen?

For clients not trusting the intercepting proxy CA, nothing at all. They will not trust any of the fake certificates, and the stolen one is no different.

For clients trusting the intercepting proxy CA (like computers where its CA has been installed so that the proxy can protect them), the stolen key could be used to impersonate stackoverflow.com from now on on those computers (up to whatever expiry was set on the certificate it generated), even if the proxy itself would have generated a new key itself.

Note that if the proxy server reuses the private key for all certificates, as noted in ysdx answer, that would basically let the attacker impersonate any website for clients trusting that CA (simply make a request to website X get a certificate signed by the proxy CA using the private key already in their control).

Additionally, depending on the kind of ciphersuite negotiated (then it doesn't support forward security), getting hold of the private pair of the certificate would allow decrypting past communications against the proxy (for that website or -in the shared-key case- for all websites) if those had been recorded.

Moreover, I would also be concerned about how that key came to be stolen, since if that happened you might have bigger problems.

  • But where could an attacker use the stolen key? In a client-proxy-wan-server connection the proxy presumably trusts the common CAs but not the CA it generated itself for signing. So an attacker could not mitm the connection further upstream than the proxy. The attacker would need to stay somewhere in the path from client to proxy because only the client trusts the custom CA. The same would apply to a stolen CA key?
    – airodumb
    Oct 4, 2021 at 11:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .