Multipath TCP Introduces Security Blind Spot 60
msm1267 (2804139) writes If multipath TCP is the next big thing to bring resilience and efficiency to networking, then there are some serious security issues to address before it goes mainstream. An expert at next week's Black Hat conference is expected to explain how the TCP extension leaves network security gear blind to traffic moving over multiple network streams. Today's IDS and IPS, for example, cannot correlate and re-assemble traffic as it's split over multiple paths. While such attacks are not entirely practical today, as multipath TCP becomes a fixture on popular networking gear and mobile devices, the risks will escalate. "[Multipath TCP] solves big problems we have today in an elegant fashion," said Catherine Pearce, security consultant and one of the presenters, along with Patrick Thomas. "You don't have to replace hardware or software; it handles all that stuff behind the scenes. But security tools are naïve [to MPTCP], and make assumptions that are no longer valid that were valid in the past."
News to be filed under "duh..." (Score:5, Insightful)
Seriously, the second somebody proposed this it should have been (and surely was) clear what the authentication and security implications were. This doesn't mean multi-path is a bad thing, it just means it will likely be used in the appropriate places as opposed to 'everywhere in the tubes.'
Re: (Score:2, Interesting)
It's not like multi-homed protocols based on IP are new. SCTP [ietf.org] has been around about a decade (half a decade as a real Internet standard).
Re: (Score:2)
It's not like multi-homed protocols based on IP are new. SCTP has been around about a decade (half a decade as a real Internet standard).
SCTP does not do what a lot of people think it does. Additional paths are used only for redundancy.
Re:News to be filed under "duh..." (Score:5, Insightful)
For me, some extra resiliency against snooping is a bonus rather than a "critical vulnerability".
Re: (Score:2)
I certainly understand the sentiment, but multi-path just changes the chokepoints.
Three duh's from the article: (Score:2)
Three duh's from the article:
They lost me at "Trust models users .... have fostered with Internet providers".... Duh.
Re: (Score:2)
Re: (Score:2)
Christ, it was one of the first lessons I learned that one could not simply sniff incoming packets and assume there was any order to them. People have been writing UDP protocols for decades now that require reassembly of packets into proper order.
I get that multipath TCP means a lot more traffic will be sent in odd fashion, but really, if the recipient TCP stack can grab and reorder them, then that's what counts.
Re: (Score:3)
The biggest issue is you went from firewalls that didn't need to know about each other's state to not only sharing state, but every packet. Essentially you went from a lock-free design to a giant lock.
I assume this would be way too much load for the firewalls, so you'd be better off mirroring all edge traffic to a central server to demultiplex the streams. Imagi
Re: (Score:2)
it will likely be used in the appropriate places as opposed to 'everywhere in the tubes.'
Appropriate meaning, in practical terms, any place it might save the operator of a given network segment a couple of bucks.
Which are the appropiate places? (Score:2)
Of course, this technology is just begging the Tor network to adopt it!
Re: (Score:2)
The irony is that the article mentions that mptcp makes surveillance harder, as if that's a bad thing. Really tells you where the author(s) are coming from...
Great! (Score:3, Insightful)
What you're saying is that Multipath-TCP will make deep packet inspection less useful? That's a win in my book. The net shouldn't be looking at packet contents anyway.
Re: (Score:2)
Not really.
'The bad guys' have multiple options. Comcast will do DPI at the edge where you have only one path, so multipathing won't effect them and throttling your torrents will still be trivial. The NSA/CIA will just recombine the streams in their data center from the multiple taps they have. Its not really difficult if you have enough CPU and they have the budget to ensure they have enough CPU ... and if they don't have the budget, they have enough dirty on congress to get their budget upped until the
Re:Great! (Score:4, Informative)
I'm not sure what you mean, but MultiPath-TCP is about combining different technologies.
So one part of the stream will run over Comcast, sure. But an other part will be transfered of 3G/LTE/whatever...
In that case Comcast isn't going to get the whole stream. Good luck with your IDS and deep packet inspection.
Al though most deep packet inspection problem looks for port-numbers, HTTP Host-headers, HTTPS SNI names and destination IP-addresses anyway. So impact in that case might not be that bad.
An other use case for MultiPath-TCP is roaming without dropping a connection. So for example, going from one WiFi to an other Wifi network without interruption.
If that is a different provider again Comcast won't see the whole stream.
Re: (Score:2)
Al though most deep packet inspection problem looks for port-numbers
IPv6+IPSEC. Port numbers are also encrypted.
Design Issue (Score:4, Insightful)
It's a design issue.
IDS and IPS can still intercept traffic taking muliple paths so long as those paths converge at the security device somewhere along the way.
i.e. traffic can be split across a WAN (MPLS / Internet IPSec paths for example) and be reassembled on the DMZ incoming to the destination site or hub site of a regional network.
Re: (Score:1)
But that's the point: it doesn't have to.
Say you have a phone on corporate WiFi and 4G. The phone handles MPTCP, but the corporate firewall only sees the part of traffic that goes over WiFi.
Re: (Score:2)
But that's the point: it doesn't have to.
Say you have a phone on corporate WiFi and 4G. The phone handles MPTCP, but the corporate firewall only sees the part of traffic that goes over WiFi.
First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall) and in the second it will not cross the firewall anyway.
Second, if the firewall sees traffic it doesn't understand it's just going to drop it. Security is not compromised.
Re: (Score:2)
First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall)
What stops a BYOD from using multipath? It will have to use the 4G connection when it isn't on the corporate wifi, so what keeps it from using both?
Re: (Score:2)
Corporate policies can be pushed to a non BYOD device. Obviously (as you point out) the BYOD device - if it's using both paths - could be blocked on the corporate WiFi environment due to the IPS policy but continue chugging along on 4G and effectively negating the bonus of multipath.
There's never a clear solution for BYOD unless it can be centrally managed, which is the security concern for most (all?) companies, I'd think.
Re: (Score:2)
What's to stop it from using only the 4G connection and being completely undetectable by the firewall/IDS/IPS? That scenario is already broken.
Re: (Score:2)
First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall)
What stops a BYOD from using multipath? It will have to use the 4G connection when it isn't on the corporate wifi, so what keeps it from using both?
It's the destination that comes into play. If it's a personal destination it's not going to use the corporate network. If it's a corporate destination then it will.
If it tries to do both - ie to a personal destination across the corporate network + 4G then the firewall will drop the packets and either it won't work at all or the upper level protocol will have to realize that one path is down and not use it.
In any case, the security model is not broken.
Cap (Score:2)
What stops a BYOD from using multipath?
The 4G carrier's monthly cap.
Re: (Score:1)
The firewall sees another TCP connection. Everything looks great.
Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.
This is definitely a game changer. The old security inspections are successfully evaded. Add on the ability to open a stream in the opposite direction.
The countermeasure is to enable deep protocol inspection (and HTTPS inspection!) and your NG firewall and have it try and understand MPTCP
Re: (Score:2)
Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.
Mind you the same applies if someone downloads a malware binary across an encrypted protocol
The countermeasure is to enable deep protocol inspection (and HTTPS inspection!)
To inspect https traffic you have to force proxy it. Force proxying should be an effective measure to prevent multipath TCP as well.
Re: (Score:2)
The firewall sees another TCP connection. Everything looks great.
Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.
This is definitely a game changer. The old security inspections are successfully evaded. Add on the ability to open a stream in the opposite direction.
The countermeasure is to enable deep protocol inspection (and HTTPS inspection!) and your NG firewall and have it try and understand MPTCP and correlate multiple streams. Try doing that with an active/active firewall cluster.
As another poster commented, we are definitely moving towards per-host IPS, hopefully in the hypervisor for your VMs.
So I worked on a file transfer product some years ago that basically did the same thing - it transferred using multiple TCP connections to reliably overcome certain network conditions (e.g satcom, network drops, etc). Our clients built IDS/IPS rules to handle the whole thing without any issue, and we didn't have to provide documentation of our network protocol for them to do it. Of course, it was helped by the fact that we used the same port to open all the connections.
So ultimately I don't see this as
Re: (Score:2)
if the firewall sees traffic it doesn't understand it's just going to drop it.
MPTCP is backwards compatible with stateful firewalls, so unless your firewall knows about MPTCP, it will think it's just another TCP stream for an unknown Layer7 protocol and nothing will look wrong.
Re: (Score:2)
if the firewall sees traffic it doesn't understand it's just going to drop it.
MPTCP is backwards compatible with stateful firewalls, so unless your firewall knows about MPTCP, it will think it's just another TCP stream for an unknown Layer7 protocol and nothing will look wrong.
Sure, but if (due to MPTCP) the firewall only sees part of the flow (sequence number problem) or does not see the first packet of the flow as some packets are taking a path that does not flow through the firewall, it will drop the traffic.
This is why I said this whole topic is a design issue. All paths must go through the firewall or traffic will be dropped.
Not a design issue, it's a game changer (Score:1)
You seem to have missed the ability to open a connection in the reverse direction.
This is a game changer that breaks existing stream engines.
Network-based IPS and IDS are obsolete (Score:5, Insightful)
Security is not meant to be, and now can't be a bolt-on feature without disrupting performance of the network. Nor is security what dictates the design of your protocols --- IP traffic is not meant to be intercepted, and more and more of it is becoming encrypted. Your IDS/IPS cannot look inside SSL traffic, either, which could contain exploit code (conveniently packed and encrypted by the SSL container).
You now need to move and have multiple IDS or IPS security agents on the end devices themselves; perhaps on the NIC, where you most certainly could have access to disparate MP-TCP sessions, with some software engineering.
I'm so sorry, it seems hard that you will now need to manage 1000 IPSes on all your endpoints which is less convenient than one centralized IPS, but the centralized IPS was always a hack and likely to be compromised or circumvented, for example, by tunneling, or leveraging a secondary WiFi network, as it's a ripe target.
In principle, the only sound thing to do is going to be to move your detectors.
Re: (Score:3)
Your IDS/IPS cannot look inside SSL traffic
Sure it can. You just push a new root certificate to your devices and intercept away.
Re: (Score:2)
Sure it can. You just push a new root certificate to your devices and intercept away.
Issuance of a bogus certificate to fool one of the parties to a SSL conversation is called a Man-in-The-Middle attack which is fraudulent conduct; pushing a fraudulently issued a certificate document claiming to be the other party and that this false thing was the other party's key.
This is nothing to base a security model on, as the attack actually compromises encrypted data --- the parties to a legitimate conversat
Re: (Score:2)
"Your IDS/IPS cannot look inside SSL traffic, either, which could contain exploit code (conveniently packed and encrypted by the SSL container)."
You might want to go read up on SSLStrip before you make that assertion. There are a bunch of other utilities that do basically the same thing, but their names escape me at the moment.
Admittedly, SSLStrip relies (generally) on the target ignoring the bad cert warning, but if you've compromised the target and inserted your root CA into the "trusted" list, well... n
Really??? (Score:5, Insightful)
Re: (Score:2)
It's different because the agencies with security as their middle name don't have a backdoor for this.
For actual security purposes, making sensitive data more difficult to spy on is a feature.
Re: (Score:2)
... Right, because they can't just recombine the data from their multiple taps back in their data center.
Because ... they don't do this already to correlate data from different single path streams or anything ...
Those agencies will have no problem for dealing with this particular issue.
Re: (Score:2)
It's different because the agencies with security as their middle name don't have a backdoor for this.
That's why I was careful to say "end-to-end encryption" instead of "https". If you aren't using the public CA infrastructure, your data may be private.
Already an issue (Score:1)
Async routing happens all the time and is already an issue. This shouldn't hold up the benefits that multipath tcp would give us. /sigh
These assumptions were never valid actually (Score:2)
Vendors need to get a clue (Score:2)
I am sick of IDS/firewall vendor corner cutting and laziness being wielded as an excuse to impede progress or otherwise nerf IP.
This is the same cast of characters who get caught naively mishandling IP layer fragmentation, option headers and hell even nested 802.1q.
Instead of owning up to it sit there like a bunch of two year olds and either complain their jobs are too hard or have the audacity to throw their weight at nerfing protocols themselves.
If people think multipath TCP is useful then they will deplo
Endpoint security FTW! (Score:2)
Hopefully this will lead to an increased emphasis on endpoint security, rather than the current "we have firewalls" attitude that's far too pervasive.
(For people who actually care about real security, that is. I've got no sympathy for those who just want to control/censor/monitor Internet traffic.)
Security Trying To Hold Back Progress, Again (Score:2)
So here we have security vendors trying YET AGAIN to hold back progress in Internet protocols. They did it with window scaling, ECN and IPv6. Each new invention doesn't work with their snake oil so they either disable it or tell people not to use it.
They like to lock down HTTP too, preventing anything that doesn't "look right." As if a server would respond to PUT or OPTION if it didn't intend to support that.
Breaks Traffic Inspection ? (Score:2)
One good reason to use it !