3 ms·
Why don't you spell it out? Spying on clients is already done via MITM proxies after installing a CA on the client. That'll still work just fine. I've written
by MichaelGG 9y ago
Why don't you spell it out? Spying on clients is already done via MITM proxies after installing a CA on the client. That'll still work just fine.
I've written network monitoring systems (for voice). Needing to decrypt is a big deal, and the easiest way to do so (apart from just turning off TLS) is just to load your servers' private keys into the monitoring box. Nothing is needed on the client, at all. Nothing is needed on the server, either (not everyone supports the same ways of dumping plaintext traffic).
- jsmthrowaway 9y agoremoved
- openasocket 9y agoIt sounds like you're implying you are aware of a vulnerability in the TLS 1.2 protocol or in a major TLS 1.2 implementation. If you do, please responsibly disclose this to the maintainers immediately so it can be fixed. Moreover, you seem to be implying that major enterprises and/or governments are aware of this vulnerability, and will use/are using it to identify leakers. Generally forward security doesn't give you a lot in a data exfiltration scenario. In this scenario a user is in a hostile network and their machine may be partially compromised and they need to upload data to a friendly server. If the friendly server uses non-PFS cryptography, like static DH, anyone with the server's private key can decrypt the traffic. But if the adversary has the secret keys of your friendly server it's already game over. The advantage forward security gives you is that each individual connection will have a different ephemeral key, so you can't steal the server's keys to decrypt the traffic offline, and if you can break the ciphersuite you have to do so for each and every connection. I personally think we should keep non-PFS ciphersuites out of TLS 1.3, but I don't think it's at all fair to assume malice on the part of those arguing to allow it