Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 http 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..

cheers.

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

share|improve this question
    
Can you please clarify your reference to IDP. Are you referring to Intrusion Detection and Prevention? –  Bernie White Jun 14 '12 at 21:05
    
@BernieWhite yes i'm referring to Intrusion Detection and Prevention. –  fduff Jun 15 '12 at 17:25
add comment

3 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.