Multipath TCP: Breaking Today’s networks with Tomorrow’s Protocols. is being presented at Blackhat USA this year by Me (Catherine Pearce @secvalve) as well as Patrick Thomas @coffeetocode. Here is a bit of a tease, it’s a couple of weeks out yet, but we’re really looking forward to it.
Come see us at Black Hat Briefings in South Seas AB, on Wednesday at 3:30pm.
What is multipath TCP?
Multipath TCP is a backwards-compatible modification that allows a core networking protocol, TCP to talk over multiple paths at the same time. In short, Multipath TCP decouples TCP from a specific IP address, and it also allows you to add and remove network addresses on the fly.
Why do I care?
MPTCP Changes things for security in a few key ways:
- Breaks Traffic Inspection – If you’re inspecting traffic you need to be able to correlate and reassemble it. We haven’t found a single security technology which does so currently.
- Changes network Trust models – Multipath TCP allows you to spread traffic around, and also remove the inherent trust you place in any single network provider. With MPTCP it becomes much harder for a single network provider to undetectably alter or sniff your traffic unless they collaborate with the other ones you are using for that connection.
- Creates ambiguity about incoming and outgoing connections – The protocol allows a client to tell a server that it has another address which the server may connect back to. To a firewall that doesn’t understand MPTCP it looks like an outgoing connection.
Did I mention that MPTCP is designed to be backwards compatible and runs on >= 85% of existing network infrastructure [How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP ]
Like IPv6, this is a technology that will slowly appear in network devices and can cause serious security side effects if not understood and properly managed. MPTCP affects far more than addressing though, it also fundamentally changes how TCP traffic flows over networks.
MPTCP confuses your existing approaches and tools
If you don’t understand MPTCP, things get really confusing. Take this wireshark “follow TCP stream” where I follow an http connection. Why does the server reply to an invalid request this way?
Network flows can also become a lot more complicated. Why talk over a single network path when you can talk through all possible paths?
That’s what your non MPTCP-aware flows look like.
But, if we are able to understand it then it makes a lot more sense:
What are the implications?
Technologies are changing, and multipath technologies look like a sure thing in a decade or two. But, security isn’t keeping up with the new challenges, let alone the new technologies.
- I can use MPTCP to break your IDS, DLP, and many application-layer security devices today.
- There are security implications in multipath communications that we cannot patch our existing tools to cope with, we need to change how we do things. Right now tools can correlate flows from different points on the network, but they are incapable of handling data when part of it flows down one path and part of it flows down another.
To illustrate point 2:
What if you saw this across two subflows… Can you work out what they should be?
- Thquicown fox jps ov the az og
- E k brumerlyd.
Highlight the text below to see what that reassembles to
[The quick brown fox jumps over the lazy dog.]
Follow up with our Black Hat session as we discuss MPTCP and the effect on security in yet more detail. We ma not be ready for the future, but it is fast approach, just ask Siri.
How does your security decide what to do with a random fragment of a communication?