Assuming a TLS connection where both the server and client perfectly adhere to the pertinent standards.

  1. Can an transparent HTTPS proxy intercept the TLS connection? (Assuming the "mock CA" certificate used by the proxy is in Trusted Root on the client)

  2. (Possibly out of scope not quite sure?) If not which (a) server and (b) browser are closest to having such an implementation?

This question is prompted by the following quote regarding the TLS protocol and the Squid proxy software "If [the TLS] security was actually being used properly bumping [aka interception as described in Q1] is not even possible. There are a growing number of transactions that do it in ways getting ever closer to that proper use."

2 Answers 2


Can an transparent HTTPS proxy intercept the TLS connection? (Assuming the "mock CA" certificate used by the proxy is in Trusted Root on the client)

HTTPS interception with a (transparent) proxy is theoretically possible if all of the following conditions apply:

  • The interceptors CA is trusted (as you expect).
  • No pinning of certificate or public keys is done. Browsers are aware of legal SSL interception, that is they switch of pinning if the certificate was signed by a CA which got manually added (and trusted). But applications like Dropbox are not aware of such situation and will fail.
  • No client certificates are used. Use of client certificates needs real end-to-end TLS, i.e. can not be intercepted even by a trusted CA. Or at least the original client certificate can not be forwarded to the original server which then makes mutual authentication fail if the server verifies the client certificate properly.

(Possibly out of scope not quite sure?) If not which (a) server and (b) browser are closest to having such an implementation?

Server implementation is not relevant. Browser implementation is only relevant for the special behavior with pinning I described above. At least Firefox and Chrome show this special behavior.

This question is prompted by the following quote...

You are taking this quote without showing its source and out of context. Googling for it shows that it just some quote from a mail on the squid mailing list and is not part of any documentation. Also it is prefixed with the sentence "Though be aware that ssl-bump is an MITM attack on a security protocol," which suggests that the author means SSL interception without consent by the application, i.e. not the case when a browser explicitly trusts the intercepting CA.


Regarding your first question: The answer hinges on the definition of "transparent". To me, transparent interception would imply that no certificates or certificate authorities have to be manually added by clients to the "trust store" of their devices. As long as this condition holds and your browser correctly checks the presented certificate for its validity, an attacker will not be able to intercept your connection, unless they manage to do one of the following:

  • compromise one of the CAs your device trusts
  • somehow get a trusted CA to sign a counterfeit certificate for a site they do not actually own
  • manipulate the trust store on your device
  • or get hold of a specific server's private key.

The reason why these are the only attack vectors (again, if the validity check is properly implemented client-side) is that the server will present a certificate (including the server's public key) that is itself signed with some CA's private key. The client checks whether the signature matches with the public key it has stored for the corresponding CA, and if it does, starts a TLS/SSL handshake with the server. It is at one point of this handshake protocol that the client encrypts some connection-specific information with the server's public key. Whoever is intercepting the message will then have to decrypt the information with the server's private key and send it back to prove they are not, in fact, someone else.

Regarding your second question, I do not know what exactly is meant in the sentence you quoted. What I know is that all popular modern browsers do correctly validate certificates. There is, however, another interesting mechanism in regards to certificate security that is not adopted by all modern browsers, at least as far as I know. Public Key Pinning is a concept related to trust on first use : When you first visit a website, you "pin" the public key you were shown to that domain and check whether it is still the same on subsequent visits to the page. This protects against attack scenarios 1 and 2 outlined above - you do no longer have to worry about fake certificates being issued if only you saw the legitimate certificate once before. Public key pinning can not only be done for specific servers but for any CA in the chain of trust. To answer your actual question, Chrome and Firefox are able to do public key pinning (and there are probably others, but I do not know every single one of them).

You must log in to answer this question.

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