Hacker News Reader

Comment by nly | Hacker News Reader

I don't understand why timings are critical to the operation of the system. Wouldn't packet filtering + transparent proxying work just as effectively? Is this a TCP sequencing attack of some kind?

View on HN

Presumably they don't have the capability to filter or modify packets passing through the exchange. So when they see target's computer opening a connection, they have to generate a reply faster that reaches the computer before LinkedIn's server replies.

But if they don't have the capability to modify packets, wouldn't the original LinkedIn packet get through as well? Perhaps the OS might ignore it, but it seems like it would show up in some cases.

I would assume the original packets get dropped as duplicates at the router level, but if they do get through to the end user's computer there would be a way of detecting that this attack is underway.

Hmmm, I wonder if there's a way to monitor for this on an OpenWRT router? I'd _guess_ since that's where the IP address for most people's home internet (and many people's work internet) terminates - that you'd be able to detect it there (and it isn't likely to be filtered/dropped by routers further up the chain in my ISP)?

No, networks are dumb. They do not detect duplicates that would require vast storage! Unless you have a tcp (eg http) proxy on the route you will be the one filtering the duplicates.

Routers operate on the Internet Protocol layer (level 3), which have no state (or anything considered a duplicate). TCP is a layer above (level 4) and that has sequence ids.

I'm skeptical that there is no infrastructure in place to prevent this, but if you're right, it really should be possible to make a home router plugin (for, say, OpenWRT) to detect this spoofing. This plugin could then be used to gather data on how prevalent this attack is, which would be quite interesting. Because as I see it, there is really no reason to believe this is just used for Tor exclusively.

It's easily detectable. You could put a firewall rule to mark it and log it to syslog as this can happen at the kernel level. You will although get lots of false positives as you get duplicate sequence ids anyway in the normal course of things as things timeout and resend connections they think are lost.

TCP packets have a sequence number and if the sequence number is less than the receiving computer is expecting, the kernel will discard the packet. In fact, since so many people are behind DHCP, the discarding is probably going to happen at that level, and the actual computer will never see the second packet.

This makes the most sense. The idea is to hijack the connection and insert packets into the stream which override the original packets, due to arriving first. That's why latency matters so much.

Yeah, I'm not sure. The linked diagram [1] shows them influencing routing, rather than some timing issue.

[1] https://www.documentcloud.org/documents/785152-166819124-mit...

Reply on news.ycombinator.com