0

In this environment an intercepting HTTPS proxy is used for legitimate purposes and its CA root certificate is installed on all clients. Every HTTPS proxy solution I've seen so far simply signs a new certificate directly with the CA, not preserving any information on the original certification path. After the proxy has made its decision, it's impossible to see what the original certification path was, which would be helpful for further evaluation in both success and failure.

It would be possible for the proxy to recreate the whole path of fake certificates instead of the one fake certificate, as demonstrated in this matrix on row "proposal". Of course, examining these certificates in detail would be rather useless, as they have fake keys, but this would preserve information on their CN, the dates they are valid between etc.

Certification path matrix

My questions:

  1. What might be the main reason we don't see this?

    • It's assumed that users won't examine the certificate anyway.
    • The additional resources this would consume on the proxy.
  2. ...or do we? Any examples of such intercepting proxies?

  3. Would there be a better alternative, if we would like to preserve this information for the client?

2

What might be the main reason we don't see this?

There is not much added value with this in my opinion. As you already noticed these information would be fake anyway. Actually, I find it useful that if somebody has a look at the certificate (most don't care anyway) it would be obvious that this is not the original CA but a local one explicitly provided for SSL inspection.

Would there be a better alternative, if we would like to preserve this information for the client?

While most end users don't care as long as the browser does not complain, for some it would be useful to get the original certificate and chain, i.e. not a similar one but the real one. This could for example be done by providing a specific URL where the intercepting proxy simply delivers information about the original certificate as was seen by the proxy, i.e. something like https://proxy/give-me-the-original-cert?domain=.... I know of at least one product which has implemented this approach at the request of a customer.

2
  • I actually like the idea of an internal service for original certificates. Could you share which product has this, just for comparing their implementation? I was thinking of a small web server for this. – Esa Jokinen Apr 25 '20 at 10:04
  • 1
    @EsaJokinen: "Could you share which product has this,..." - The firewall "genugate" of the German company genua. – Steffen Ullrich Apr 25 '20 at 11:28
2

We can only guess "What might be the main reason".

I suppose that the main reason is delay needed for key pair generation for every certificate in the chain.

Let's look what would it mean to fake certificates:

  • Generate key pair. If you want to be consistent, you may want to have the same key length as the original one. For RSA 4096 and RSA 8192 generation of a key pair can take considerable time. Depending on CPU used (proxy may have a weak CPU) and PRNG this can take 1 to 10 minutes. Not only this costs computation resources, but also means a huge delay for browser establishing connection. Some browsers will report the host as unreachable.
  • You can use short keys (they can be generated much faster), but then you deviate from your desire to reproduce the certificate chain.
  • Generate certificate and sign it. This is pretty fast compared to generating key pair. Even for long keys it is fast.
  • Fingerprints of each certificate will be different from the original ones. Again, deviation from the original chain.
  • How about serial number? Do you want to keep the original one? Then you can have problems if you have some database where this field is used for certificate search. If you generate a new one, then you deviate one step more from your idea to reproduce the original chain.

And even if you generate all keys and certificates, you will have one more deviation from the original chain: The top most certificate in the original chain will not be the top most in the fake chain, because the top most is the proxy certificate. Thus you have one more deviation from the original chain.

Despite these efforts it is all irrelevant for TLS. TLS uses only a few fields from certificate: Information if the issuer is eligible to issue certificates (Certificate Authority: Yes, Purposes: Certificate Signing, ...), if this certificate is trusted (directly or its issuer), if validity period includes current date. Means, the original chain has no value for TLS. Why put efforts to implement it?

Would there be a better alternative ... to preserve ...? - In my opinion no. Because this would be mix of real and faked values: As I shown above, multiple fields in each certificate in the chain would need to be replaced with new values. How would distinguish what fields are the same as in the original certificate and what were changed?

If smb. really needs information about the real certificate chain, then it would make sense to only show the real certificate chain.

5
  • Regarding the key pair generation, most if not all CAs and intermediates are currently using RSA 2048. It's the actual certificate that may have RSA 4096 or RSA 8192, but most intercepting proxies still generates RSA 2048 key pairs for the client-proxy connection. – Esa Jokinen Apr 26 '20 at 5:22
  • @Esa Jokinen: I have no such data. But if it's true, this is a deviation from the goal to reproduce the original chain. – mentallurg Apr 26 '20 at 5:27
  • @Esa Jokinen: I'm curious: What usage you see in a fake chain? – mentallurg Apr 26 '20 at 5:30
  • It's more usable for debugging why a validation failed on a proxy than for valid certificates; on a valid certificate it's easy to trust the decision made by the proxy. As the proxy replaces every certificate failing the validation with a self-signed certificate, it's impossible to see whether it was e.g. just a missing intermediate certificate. This is quite easy to read from the certificate names alone, not digging deeper into the keys and details. – Esa Jokinen Apr 26 '20 at 5:42
  • But I completely agree with your reasoning that as something would be faked anyway and it's hard to draw a line on what to preserve and what to fake, it's better to keep it simple. I think that's a better reason than the key sizes. The diagnostic details should be somewhere else than on the faked chain. – Esa Jokinen Apr 26 '20 at 5:46

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.