An interesting question was recently asked about SSL inspection, and that got me wondering if it is actually possible, from the end user (or even server side), to detect if the SSL link is being monitored or not?

One method for an IDP to decode SSL traffic and decode HTTPS packets is to use a root certificate in SSL forward proxy mode.
How are these root certificates issued to companies? As I understand it, such certificate could be used to decode any SSL traffic.

EDIT: Ok for the root certs, but what about detecting SSL packet inspection, is that feasible at all?

  • Can you please clarify your reference to IDP. Are you referring to Intrusion Detection and Prevention? Jun 14, 2012 at 21:05
  • @BernieWhite yes i'm referring to Intrusion Detection and Prevention.
    – fduff
    Jun 15, 2012 at 17:25

3 Answers 3


From the outside, eavesdropper can passively access everything that is sent "in the clear" as part of the initial steps of a SSL/TLS connection. This includes the fact that SSL is used, the protocol version, the agreed-upon set of cryptographic algorithms, the server certificate, often the intended server name... Once the initial "handshake" is complete, outsiders only see encrypted data, which they cannot decrypt; note that the target URL is part of that encrypted data (the target server name may be visible in the handshake, not the rest of the URL). It must be said that while encrypted data is opaque to eavesdroppers, the length of such data is not; depending on the cipher suite, the length may be known to external spies with single byte accuracy.

Such passive-only recording of packets in transit cannot be detected from either the client or the server (by definition).

To access the contents of the SSL tunnel, inspectors must somehow hack into either the client or the server. There are products meant for deployment by administrators of big (corporate) networks, where this "hack" is embodied by an additional "root CA" inserted in the store of trusted roots of the client system. This extra root CA is controlled by the proxy, which generates on the fly a fake certificate for the server you try to reach, and basically runs a man-in-the-middle attack. This can be detected on the client side by asking your browser to display the server's certificate, and see to which root CA this certificate attaches to.

However, inserting an extra root CA in the trust store requires privileged access to the machine (i.e. as Administrator) and whoever could do that, could have just as well installed less conspicuous spying software such as key loggers and screenshot grabbers. Therefore, if SSL contents inspection is at all possible, then undetectable inspection is also possible. The extra root CA is for SSL contents inspectors who act on an official basis and do not feel the urge to hide their eavesdropping.

Conversely, if your machine is "clean" (untouched by would-be spies), then SSL (HTTPS) will protect you against external inspection of your data. This is one of the core features of SSL.


I've been very interested in an automated SSL Inspection detector for quite some time. As far as that goes some Security.SE links that may help you:


Roots certificates of CAs are freely downloadable from CA issuers. Thawte, Verisign. Roots certs of all major CA issuers - here. If this is what you are looking for.

  • You are not responding the main question: how can the end user detect that the TLS/SSL link is being monitored (traffic inspected)? Dec 23, 2015 at 18:29

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.