Moving past TCP in the data center, part 1

Posted Nov 2, 2022 20:36 UTC (Wed) by MatejLach (guest, #84942)
In reply to: Moving past TCP in the data center, part 1 by Cyberax
Parent article: Moving past TCP in the data center, part 1

> it mandates encryption which is not really needed in a DC.

Is this still the general consensus even after Snowden? I am not saying it's a silver bullet against a dedicated attacker like the NSA, but I'd think that every additional obstacle in the way is going to raise the bar for dragnets just a tiny bit, no?

Moving past TCP in the data center, part 1

Posted Nov 2, 2022 21:58 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (3 responses)

You at least want encryption over any line you don't physically control (i.e. it is not inside a building you own), regardless of ownership/leasing rights, which in practice means you encrypt all inter-DC traffic. You also probably want integrity (signatures, certificates, etc.) for most if not all traffic, to make it more difficult for malware and other adversaries to move laterally within your systems and/or escalate their privileges. Encryption within the DC may not be strictly necessary if you have good physical security and you trust the networking equipment, but those are both big ifs.

Moving past TCP in the data center, part 1

Posted Nov 2, 2022 22:40 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

My company - along with many others I suspect - is moving away from "trusted core". My works laptop now needs 2fa to authenticate to works servers - even when in the office and connecting over corporate infrastructure.

Given the breakins and stuff businesses have suffered, yes it's an absolute pain, but it means that if anybody does manage to break in to my laptop, it's now rather harder for them to jump to someone else and break into their laptop, moving up the chain ...

Cheers,
Wol

Moving past TCP in the data center, part 1

Posted Nov 2, 2022 23:09 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

> My company - along with many others I suspect - is moving away from "trusted core". My works laptop now needs 2fa to authenticate to works servers - even when in the office and connecting over corporate infrastructure.

1. 2FA has nothing to do with encryption. 2FA is primarily about stopping phishing, and only used by humans (I was talking about machine-to-machine communication).
2. Unless your laptop is in the same physical building as all of the servers you will be interacting with, and your company has complete autonomy over that building (i.e. you're not leasing it out from someone who might have physical access), you're not using "trusted" lines in the sense I was referencing. I explicitly said this isn't about who owns or leases the lines. It's about who is able to physically touch and interact with the lines.

Moving past TCP in the data center, part 1

Posted Nov 3, 2022 7:56 UTC (Thu) by Wol (subscriber, #4433) [Link]

Yup. Might not be quite what you were talking about, but it's a general trend to restrict the trusted zone, even in a trusted network, such that there's minimal trust between any actors, even if you would assume that they are trusted actors.

Cheers,
Wol

Moving past TCP in the data center, part 1

Posted Nov 2, 2022 23:58 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

NSA is not going to install spy boxes in your DC network switches. There's simply way too much traffic to analyze and the network complexity makes it infeasible to even do independently of AWS.

So NSA would simply officially ask Amazon to provide them with a covert way to access the data for a specific customer directly using the AWS services.

Moving past TCP in the data center, part 1

Posted Nov 3, 2022 9:48 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

The NSA may however have its employees go and work for your company under cover. It's pretty much a certainty that /multiple/ state intelligence agencies have agents working at the various large tech companies.

Minimising the trust and scope of access of what employees can access, to what they need to access for their immediate role, is a good thing, security wise.

Moving past TCP in the data center, part 1

Posted Nov 3, 2022 17:31 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Sure. But the complexity of AWS is so overwhelming that you won't really be able to do much unless you want a very targeted attack and have access through many layers of security (physical and virtual).

Moving past TCP in the data center, part 1

Posted Nov 23, 2022 22:27 UTC (Wed) by Rudd-O (guest, #61155) [Link] (3 responses)

Counterpoint: NSA absolutely does install spyware into network switches.

Snowden already revealed this. There are extensive talks on the subject presented by Jacob Applebaum at CCC.

Moving past TCP in the data center, part 1

Posted Nov 23, 2022 23:43 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Sure. So you installed spyware into a TOR switch. Then what? The data plane is too fast for any meaningful analysis with the puny switch CPU.

You maybe can mirror one port to another, but in an Amazon DC this means nothing. You'll just confuse some random EC2 hardware instance. You won't even be able to do much if you redirect the traffic to an instance that you control, because it's encrypted.

Moving past TCP in the data center, part 1

Posted Nov 24, 2022 9:54 UTC (Thu) by paulj (subscriber, #341) [Link]

"The data plane is too fast for any meaningful analysis with the puny switch CPU."

Except the L3 switch ASIC can be programmed to redirect only certain flows to said CPU. They can also be programmed to encap and redirect certain flows to other hosts. Indeed, they can be programmed to mirror packets (but I can't remember if the L3 ASICs commonly used at the super-large DCs can /both/ mirror and encap the same flow - if not, it's just a matter of time till they do).

So:

1. You don't need to analyse the entire data flow on the puny switch CPU, cause the /powerful/ switching ASIC can be programmed to do hardware tcpdumping (basically). Given the CPUs on these switches aren't /that/ puny (low to mid end Xeons), further analysis on host is quite feasible.
2. Even better, you can just redirect the flow you're interested in to a bigger server by encapping it (the server can resend the flow's packets out again so they're not missed).

Moving past TCP in the data center, part 1

Posted Nov 24, 2022 9:56 UTC (Thu) by paulj (subscriber, #341) [Link]

"You won't even be able to do much if you redirect the traffic to an instance that you control, because it's encrypted."

I note this is a good counter-argument to your own argument in another sub-thread that intra-DC traffic doesn't need to be encrypted. ;)

Moving past TCP in the data center, part 1

Posted Nov 23, 2022 22:26 UTC (Wed) by Rudd-O (guest, #61155) [Link]

No it is not the consensus *at all*.

Google encrypt all its traffic at the Stubby layer.