4 ms·

"...almost all of whom are running TLS internally and have significant, security-critical investments in out-of-band TLS decryption. Like many enterprises, fin

"...almost all of whom are running TLS internally and have significant, security-critical investments in out-of-band TLS decryption. Like many enterprises, financial institutions depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation. Unlike some other businesses, financial institutions also rely upon TLS traffic decryption to implement fraud monitoring and surveillance of supervised employees." And thus essentially defeating the entire purpose of TLS. Can you please help us continue doing this with the new version of TLS too. Thanks. Love. Big Banks.

rincebrain 10y ago
Only sometimes. The argument here could be whether you, as an individual working for an employer on employer-controlled hardware, have the right to communications that cannot be viewed by the employer at their discretion on those systems. Having that capability (undecryptable communication) on an exceptional basis (e.g. only a few sites or methods do it) might be grounds for blocking any instances of the protocol that negotiate that level at the border. Having every secure site do it would result in not being able to passively store and only decode the communications that, say, you have occasion to go inspect later for discovery reasons, and instead would require MITMing and downgrading all connections (and storing the traffic, at best, re-encrypted with a different key). (Note that I'm not voicing an opinion on the topic, just observing that there are legitimate reasons to desire this functionality from several perspectives, which do not necessarily imply wanting a backdoor in the protocol in the general case.)
- PeterisP 10y ago
  From a technical standpoint, the desire of <bank> to monitor all communications of a stockbroker in an easy and effective manner and being able to decrypt historical captured is identical to the desire of <evil government> to do the same for their civil rights activists. From a protocol perspective, you can't distinguish it - any new protocol either makes monitoring harder for everyone or easier for everyone, without checking if your reason is good or bad. If we choose to make communications more private, then yes, the ability to monitor stuff will suffer even if someone has a legitimate and reasonable reason to need this ability. Too bad, we've made a choice that the security of the masses is more important than this. I acknowledge that this change will hurt the banks for the reasons given above, but in this case hurting them is an unavoidable cost of helping most everyone else.
  - rincebrain 10y ago
    Sure, from a protocol perspective, arranging it so nobody, even the original owner, can decrypt the communication after the fact is beneficial, except that now, you end up with people downgrading such communications or storing the session secret keys, the latter probably by patching software crypto implementations where possible (since I doubt any of the major crypto implementations would agree to storing those keys even with an --i-am-a-developer-really-stop-bothering-me flag). I hope I'm wrong. I don't want to end up in a world where all enterprises actively MITM and negotiate down to non-PFS protocols to avoid this, or hack up the software stacks on their machines to circumvent this (with all the overhead that implies - echoes of "requires Internet Explorer 5" for how old some of this will probably get between updates). I just don't think that the people who make use of this functionality are going to let it go, no matter what it takes. (That's not to say it's not worth trying, to be clear - I just foresee it ending poorly for everyone except for private individuals, and possibly even them if ISPs start requiring you accept their MITM CA.)

rincebrain 10y ago

Only sometimes. The argument here could be whether you, as an individual working for an employer on employer-controlled hardware, have the right to communications that cannot be viewed by the employer at their discretion on those systems. Having that capability (undecryptable communication) on an exceptional basis (e.g. only a few sites or methods do it) might be grounds for blocking any instances of the protocol that negotiate that level at the border. Having every secure site do it would result in not being able to passively store and only decode the communications that, say, you have occasion to go inspect later for discovery reasons, and instead would require MITMing and downgrading all connections (and storing the traffic, at best, re-encrypted with a different key). (Note that I'm not voicing an opinion on the topic, just observing that there are legitimate reasons to desire this functionality from several perspectives, which do not necessarily imply wanting a backdoor in the protocol in the general case.)

PeterisP 10y ago
From a technical standpoint, the desire of <bank> to monitor all communications of a stockbroker in an easy and effective manner and being able to decrypt historical captured is identical to the desire of <evil government> to do the same for their civil rights activists. From a protocol perspective, you can't distinguish it - any new protocol either makes monitoring harder for everyone or easier for everyone, without checking if your reason is good or bad. If we choose to make communications more private, then yes, the ability to monitor stuff will suffer even if someone has a legitimate and reasonable reason to need this ability. Too bad, we've made a choice that the security of the masses is more important than this. I acknowledge that this change will hurt the banks for the reasons given above, but in this case hurting them is an unavoidable cost of helping most everyone else.
- rincebrain 10y ago
  Sure, from a protocol perspective, arranging it so nobody, even the original owner, can decrypt the communication after the fact is beneficial, except that now, you end up with people downgrading such communications or storing the session secret keys, the latter probably by patching software crypto implementations where possible (since I doubt any of the major crypto implementations would agree to storing those keys even with an --i-am-a-developer-really-stop-bothering-me flag). I hope I'm wrong. I don't want to end up in a world where all enterprises actively MITM and negotiate down to non-PFS protocols to avoid this, or hack up the software stacks on their machines to circumvent this (with all the overhead that implies - echoes of "requires Internet Explorer 5" for how old some of this will probably get between updates). I just don't think that the people who make use of this functionality are going to let it go, no matter what it takes. (That's not to say it's not worth trying, to be clear - I just foresee it ending poorly for everyone except for private individuals, and possibly even them if ISPs start requiring you accept their MITM CA.)