You said you need to look at packets to see unauthorized access. How do you that access is unauthorized unless the authorization system is doing the monitoring?
Over the years I've met with businesses who have these kinds of set ups. The way it usually works is that the analysis is secondary and based on a suspicion of some kind. For example: if an employee is suspected of insider trading, or stealing proprietary data, then the administrators may take the extreme measure of inspecting all of their traffic. This is why many corporate environments have those "No expectation of privacy" disclaimers. Another example is where traffic to a set of suspicious destinations is subject to a higher level of scrutiny. For example, maybe traffic bound for well known file sharing services. This all is fairly obvious. The question is when do you start recording (and therefore examining) the traffic. I've never seen an environment with pervasive always-on monitoring; creating a trove of plaintext would be a net security negative, and organizations rarely have the resources it would take to keep or analyze all of it anyway. Same question. At some point in time you need to decide to start examining all the traffic. At that point you can start capturing its plaintext. The proposed alternative seems to be capturing the ciphertext and the key so the ciphertext can be decrypted later – which makes no sense to me. They are, though it's a big change. I think we can do better than logs; a mechanism that's in TLS itself could be opt-in and user-aware, and so less likely to be abused in other situations. There's also some basic security model advantages to encrypting the PMS under a public-private key pair, and one that isn't using the private key that the servers themselves hold. To use the key you need to have the corresponding ciphertext stored. It is worse time- and space-wise than storing the plaintext (encrypted under the authorities’ key). You seem to have proved that capturing the plaintext from the originating (or receiving – whatever end you own) end-point and encrypting/storing it is much better option than sending ciphertext and leaking its keys (or reusing static keys for the same purpose).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
