Key Management in Interception Proxies?

Question

I'm reading Jarmoc's Black Hat presentation on SSL/TLS Interception Proxies and Transitive Trust. I have a few questions on some of the key management practices.

In the paper, Jarmoc states:

To act as the server for the client-side SSL session, an interception proxy must have access to the private key that corresponds to the certificate it’s presenting. Because the server endpoint’s private key is unavailable, the interception proxy must generate a new certificate and key pair to use for this session.

Jarmoc does not explain the reasoning behind his statement "the interception proxy must generate a new certificate and key pair to use for the session." And he does not define a "session" per se.

---

Question: according to Jarmoc's description below, is it fair to read a "session" is the [encrypted] point-to-point connection between the user and the proxy (and conversely, the proxy and the real server)?

... interception proxies insert themselves in the flow of traffic and terminate the client’s request. The interception proxy makes a second request on behalf of the client to the server. This behavior causes what was an end-to-end session to instead be two separate, but related, point-to-point sessions. The goal is to allow access to the plain-text session contents while transferring between the two encrypted sessions.

Or should I read the "session" to have the end-to-end meaning?

Can "multiple connections from a single user" (user-to-proxy flow) and "connections from multiple users" (proxy-to-server flow) be multiplexed into a single session?

---

Question: Why must an interception proxy generate a new key pair and certificate for each session?

Here are the use cases I was running through, and I don't see the benefit of distinct keys and certificates:

• two distinct users each visit example.com.

• a single user visits example.com, closes the browser, and then visits example.com again.

Supplying the same certificate and the same public key for example.com is the way things work without an interception proxy. How does a distinct certificate and public key for each visitor and visit improve the landscape?

I've experienced the latter, and I can tell you there's nothing "stealthy" about the practice (especially when the web page has lots of external links). CertPatrol threw so many warning dialogs that the browser became unusable.

---

Question: what is wrong with certifying a single private key (for say, 7 or 30 days), and then issuing all server certificates using the single key?

Generating keys on the fly is expensive and can lead to a DoS under load. Since the practice can destroy availability, I don't see the benefit.

It does not matter if there's 1 private key or 10,000 private keys. A host compromise/key compromise at the proxy means key egress. It does not matter if there's 1 of them or 10,000 of them. Again, I don't see the benefit.

If anything more than a 1:1 relationship is bad, then why is the practice used in intermediate signing certificates and subordinate CAs?

---

Question: does Jarmoc mean that each network connection (source IP address) should receive its own private key used for all certificates? (Here "session" means the interaction between the user and the proxy).

If the proxy is going to re-use private keys per-user, then why can't a private key be re-used for all users?

How does the proxy handle NAT'd connections, where users are pooled into a single forward facing IP address?

(If there's something wrong with re-use, then intermediate signing certificates probably violate whatever rule is cited because the intermediate's signing key certifies a number of end-entity certificates.)

---

Question: what are the detriments to private key re-use across sessions?

Does private key re-use break tools like tools like HTTPS Everywhere and CertPatrol; and security diversification strategies like public key pinning and perspectives?

My concern here is a naïve implementation of public key pinning within an organization, where the implementation trusts only the {public key}, and not the {host, public key} pair. But the naïve implementation may not break in practice as long as the private key at the proxy remains secret. Its hard to say without a concrete implementation.

Answer 1

Question: Why must an interception proxy generate a new key pair and certificate for each session?

I hope they don't mean, that a new (and different) certificate should be created for each user and session. In my understanding it only says that it cannot just use the original certificate because it has no access to its private key. In my opinion it is enough to create a new proxy certificate whenever it encounters a new server certificate, e.g. same proxy certificate for all users and sessions which access the same host. This behavior is also described in the paper, although critized. If you generate a new certificate each time you need to make sure, that it is similar enough to the previous one, because the browser will complain if it gets a different certificate for the same host within the same browser session (and keeping the browser open for weeks is not uncommon anymore). And, of course you should issue a new proxy certificate if the server certificate changes.

Question: according to Jarmoc's description below, is it fair to read a "session" is the [encrypted] point-to-point connection between the user and the proxy (and conversely, the proxy and the real server)? .... Or should I read the "session" has the end-to-end meaning?

I think it should be interpreted as end-to-end relationship, e.g. the initial connection from client to server via proxy starts a new session, but further connections between these parties are just the continuation of the same session. If each connection is considered a separate session with newly created certificates (different to the last one for the same client-proxy-server connection) we only get the mentioned troubles with the verification in the client.

Question: what is wrong with certifying a single private key (for say, 7 or 30 days), and then issuing all server certificates using the single key?

Having a single key pair for all proxy certificates will work, but your idea of generating a new key pair might need refinement to make sure, that the certificate does not change too much within a browser session. And, I don't agree with the paper. In my opinion the key pair for the proxy certificate can be reused as much as the key pair for the proxy CA will be reused. And the latter one needs to be, because otherwise you would need to issue a new proxy CA all the time and put it into the browser so that your proxy certificates can be verified. Also, it is even common to reuse the same key pair when extending "real" certificates.

I don't think that the approach of the paper of generating a new key pair for each certificate and for each session will even work. Because, this would result in the browser getting different certificates for the same host within a single browser session. Browser don't like this and will complain about it. And, because the proxy is not able to detect the end and begin of browser sessions it does not know when to use a new key pair.

Question: does Jarmoc mean that each network connection (source IP address) should receive its own private key used for all certificates? (Here "session" means the interaction between the user and the proxy).

No, I don't think so. I think the main point is that he does not like the same key pair to be reused too much. Like I said, I don't agree with the paper in this point.

Question: what are the detriments to private key re-use across sessions?

Certificate Patrol, Perspectives and other forms of certificate pinning might complain anyway, because you do a man in the middle attack and the generated certificate differs from the original one. But from my experience at least the certificate pinning in Chrome does not complain, if you've added the proxy CA as trusted. But it will complain if the proxy CA is not explicitly added but instead signed by a trusted built-in CA.

Certificate pinning at least in chrome is done by fingerprinting the public key. So such techniques might fail if they get the same public key for different certificates but I doubt it. They should only complain if they get a different public key than expected. So from my experience (we use such techniques and it reuses the keys) reusing the keys does not show problems in the browsers.