Encryption gets you data integrity "for free". If a bit is flipped by faulty hardware, the packet won't decrypt. TCP checksums are not good enough for catching corruption in many cases.

Interesting. When I read this I was thinking “that can’t be right, the whole internet relies on tcp being “reliable”. But it is right; https://dl.acm.org/doi/10.1145/347059.347561. It might be rare, but an unencrypted RPC packet might accidentally set that “go nuclear” bit. ECC memory is not enough people! Encrypt your traffic for data integrity!

Because any random machine in the same datacenter and network segment might be compromised and do stuff like running ARP spoofing attacks. Cisco alone has had so many vendor-provided backdoors cropping up that I wouldn't trust anything in a data center with Cisco gear.

Back in the 90s I discovered the CTO of a major telecoms company was packet sniffing EFnet traffic in one of their datacenters in order to log all the PRIVMSGs to extort a couple of people. Security is only as good as its weakest leak, and all that.

Ummm, no, The network is completely isolated. No one enters the cage and just plugs something into my switches/routers.

Any communication between the cage and the outside world is through the cross-connects.

Unless it's some state-adversary, no one taps us like this. This is not a shared hosting. No one runs serious workloads like this.

"Unserious"? Sure, everything is encrypted p2p.

> No one enters the cage and just plugs something into my switches/routers.

I'm not talking about someone plugging something in. I'm talking about someone pwning your VPN endpoint or firewall, and laterally moving from there. There's always a way to move around unless you are really, really careful (and even that is not enough if the adversary has an exploit for something really deep in the network stack).

At the very least, choose different vendors for your VPN/frontend firewall gear and the rest of your system. That way, an adversary can't just go and pwn every little piece of your network infrastructure with a single exploit.

This is a very fair point, admittedly, considering multiple vulnerabilities in Juniper and Cisco devices.

I concede my point, thanks for that

To stop or slow down the attacker who is inside your network and trying to move horizontally? Isn’t this the principle of defense in depth?

Because the NSA actively intercepts that traffic. There's a reason why encryption is non optional

To me this seems outlandish (e.g. if you're part of PRISM you know what's happening and you're forced to comply.) But to think through this threat model, you're worried that the NSA will tap intra-DC traffic but not that it will try to install software or hardware on your hosts to spy traffic at the NIC level? I guess it would be harder to intercept and untangle traffic at the NIC level than intra-DC, but I'm not sure?

> you're worried that the NSA will tap intra-DC traffic but not that it will try to install software or hardware on your hosts

It doesn't have to be one or the other. We've known for over a decade that the traffic between DCs was tapped https://www.theguardian.com/technology/2013/oct/30/google-re... Extending that to intra-DC wouldn't be surprising at all.

Meanwhile backdoored chips and firmware attacks are a constant worry and shouldn't be discounted regardless of the first point.

> (e.g. if you're part of PRISM you know what's happening and you're forced to comply.)

Only a handful of people need to know what happens in Room 641A, and they're compelled or otherwise incentivized not to let anyone else know.

> you're worried that the NSA will tap intra-DC traffic but not that it will try to install software or hardware on your hosts to spy traffic at the NIC level

It might not be able to, if you use secure boot and your server is locked in a cage.

The difference between tapping intra-DC and in computer spying is that in computer spying is much more likely to get caught and much less easily able to get data out. There's a pretty big difference between software/hardware weaknesses that require specific targeting to exploit and passive scooping everything up and scanning

If you are concerned about this, how do you think you could protect against AWS etc allowing NSA to snoop on you from the hypervisor level?

Assuming the PSP isn't backdoored, using AMD SME and SEV theoretically allow you to run VMs that are encrypted such that, even at the hypervisor level, you can't read code or data from the VM.

You cannot assume that. The solution is to have a server on your territory and use the datacenter only to forward the packets.

Its a stone cold fact that the NSA does this, it was part of the snowden revelations. Don't spread FUD about security, its important

Service meshes often encrypt traffic that may be running on the same physical host. Your security policy may simply require this.