On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote:

I'd like to hear from the people who are doing full-take network capture
within their datacenters about how they protect the security of the
internal decryption systems.

Firstly, they generally aren't storing everything, forever. Most of the time, they feed into collection/analysis systems, and most if not all of the actual packets are discarded.

In many cases, they're only enabled on a situational basis - say, a security incident or a troubleshooting session. Most if not all of the packets are discarded afterwards, in most cases.

In most cases, they're running on completely out-of-band management networks, using transparent taps or SPAN ports or equivalent. In some cases, they can be used to intervene in the cryptostream - but even in that in-band case, all the management functions are still isolated on out-of-band management networks which are not interconnected with the production network, and are further isolated as necessary by implementing situationally-appropriate network access policies.

It certainly sounds like a tempting target for any adversary interested in datacenter operations.

I guarantee you that your bank, your hospital, your insurance provider, your credit card processor, your retailer, and/or your government welfare agency are doing this, and have been doing it for a long time.

It's quite common in the national security space, as well as other governmental bureaux.

I'm not saying everyone has implemented this perfectly, or optimally - but it is a common practice which has been going on for many years, and the loss of the ability to perform these functions would result in a net security loss for these organizations and for their customers and constituents - i.e., proles like you and me.

It isn't new, it isn't unique, it isn't a case of a small group engaging in special pleading. What's amazing is that very few engaged in this discussion seems to understand all this.

-----------------------------------
Roland Dobbins <rdobb...@arbor.net>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to