HN Explorer

Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting (github.com)

86 points by Sakura-sx ↗ HN
TL;DR explanation (go to https://github.com/Sakura-sx/Aroma?tab=readme-ov-file#tldr-e... if you want the formatted version)

This is done by measuring the minimum TCP RTT (client.socket.tcpi_min_rtt) seen and the smoothed TCP RTT (client.socket.tcpi_rtt). I am getting this data by using Fastly Custom VCL, they get this data from the Linux kernel (struct tcp_info -> tcpi_min_rtt and tcpi_rtt). I am using Fastly for the Demo since they have PoPs all around the world and they expose TCP socket data to me.

The score is calculated by doing tcpi_min_rtt/tcpi_rtt. It's simple but it's what worked best for this with the data Fastly gives me. Based on my testing, 1-0.7 is normal, 0.7-0.3 is normal if the connection is somewhat unstable (WiFi, mobile data, satellite...), 0.3-0.1 is low and may be a proxy, anything lower than 0.1 is flagged as TCP proxy by the current code.

16 comments

[ 0.24 ms ] story [ 25.0 ms ] thread
Sakura-sx
Also, something I haven't included on the README is that apart from testing with Tor, WARP and some other proxies. I did some testing with the free one-week trial of Brightdata's residential proxies, and it does detect them too!!!
agentifysh
so will this detect residential proxies? how is that being done, I am getting hammered and its all legitimate normal ISP traffic.
soldthat
Neat demo. The unsettling part is how little signal you actually need: big CDNs and fraud teams already run much richer timing models than a simple min_rtt / rtt ratio. You can’t spoof away the speed of light, only add latency or jitter, and that itself becomes a fingerprint once you have enough traffic and a few global PoPs to compare from. So this doesn’t magically break L3 VPNs, but anyone relying on “just stick a TCP proxy in front and I’m anonymous/in-region” has been living with a pretty outdated threat model.
ericpauley
Every TCP proxy (that doesn't thwart this) is detectable :)

Countermeasure: pick some min-RTT >= the actual client RTT (you can do this as a TCP proxy by measuring client ping). Measure server RTT and artificially delay responses to be >= min-RTT. This will require an added delay during the handshake and ACKs, but no added delay for the response payloads.

Counter-countermeasure: the above may lead to TCP message types that don't make sense given a traditional TCP client state machine (e.g., delayed ACK would bundle ACK and PUSH but the system shows separate/simultaneous ACK and PUSH packets. Counter-counter-countermeasure is left to the reader.

Bender
I like this. I could see this being extra useful for people not using CDN's if they could easily plug it into nginx, haproxy and such. Currently for proxies I look for the proxy headers and also use a list of known proxy IP's but that is obviously nowhere near as complete as what you built. It might also be interesting to test assorted configurations of SSH forwards and MitM TLS caching proxies such as Squid SSL Bump.
vlovich123
This feels like something that’s a neat claim and will work against simple setups, but less accurate for more complicated scenarios (eg Tor). Then you’re really just relying on how accurate your knowledge of the proxies are.

Also, the readme has slightly incorrect logic I think:

> According to Special Relativity, information cannot travel faster than the speed of light. Therefore, if the round trip time (RTT) is 4ms, it's physically impossible for them to be farther than 2 light milliseconds away, which is approximately 600 kilometers.

It calls out the 33% for fiber but ignores that there’s not a straightline path between two points on the network and there could be wireless, cable, and DSL links somewhere on that hop.

Also, the controlled variable here is latency, not distance. Thus you can always increase latency through buffering and therefor you could be made to appear further than you are. And that buffering need not even be intentional - your perceived distance estimate will vary based upon queuing delays in intermediary depending on time of day (itself a fingerprint if you incorporate time-aware measurements, but a source of error if you don’t).

Fingerprinting is hard and I dislike the framing that it’s absolutely impossible to mask or that there’s not false positive and false negative error rates with the fingerprint.

kees99
Very clever, I like it.

When deployed on a popular server, one bit of "IP intelligence" this detector itself can gather is keep database of lowest-seen RTT per given source IP, maybe with some filtering - to cut out "faster-than-light" datapoints, gracefully update when actual network topology changes, etc.

That would establish a baseline, and from there, additional end-to-end RTT should become much more visible.

moreati
Why would one want this? Are there particular situation(s) that it's desirable to detect a TCP proxy? Does presence of a TCP proxy indicate some adverserial behaviour? E.g. surveillance, censorship, a particular attack?
viraptor
Just in case someone tries to use it to make some kind of judgement about the traffic - there's a whole world behind legit or enforced proxies. Especially corporate environments will often tunnel all the traffic for compliance and audit reasons.
Rasbora
This is the core concept of how proxies are detected via services like https://layer3intel.com/tripwire or https://spur.us/monocle/

The difference in min TCP RTT and min RTT to respond to a websocket payload is a dead giveaway that there's a middlebox terminating TCP somewhere along the path. You can bypass this by sourcing your request within 30ms of wherever TCP is being terminated, anything under that threshold could be caused by regular noise and isn't a reliable fingerprint. Due to how many gateway's there are between you and a residential proxy exit node this makes fingerprinting them extremely easy.

I expect it won't be long until someone deploys the first proxy service that handles the initial CONNECT payload in the kernel before offloading packet forwarding to an eBPF script that will proxy packets between hosts at layer 3, making this fingerprinting technique obsolete. The cat and mouse game continues.

29athrowaway
If you like this then you will probably like "The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage", a 1989 book by Clifford Stoll.

Also available as audiobook, and a documentary ("The KGB, The computer and Me"). https://www.youtube.com/watch?v=Xe5AE-qYan8

userbinator
The minimal explanation is that TCP is "turned around" at a dumb proxy, but upper-layer protocols may go further before being turned around. Which is trivially avoidable by delaying the TCP response with the same timing as the upper-layer protocol (and doing so to the protocol above that, etc.)
jeroenhd
Do raw TCP proxies still get used often? I'd imagine most proxies you'd want to detect are full HTTP proxies and this formula won't detect those.

I suppose it's possible botnets ("residential proxies") may get detected this way if they're using SOCKS to forward requests?

Still, this looks like an interesting signal to add to a system like Anubis to increase the difficulty for suspicious traffic sources.

This does very reliably detect TOR traffic, though you can just download a list of exit nodes if that's what you want.

Manouchehri
Would a similar technique work for tunnels through QUIC?