SSL inspection detection

Question

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?

Answer 1

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.

Answer 2

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:

• Does an established SSL connection mean a line is really secure?

• Can Javascript/Flash verify the SSL connection to prevent "SSL Inspection"?

• How do I check that I have a direct SSL connection to a website?

• What fields in a suspicious certificate should I look at?

• Can a HTTPS connection be compromised because of a rogue DNS server

Answer 3

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.