Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting

github.com

Post reply on HN
Print view View original

1–10 of 57 posts

Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting

#1

Post by Sakura-sx »

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.

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

Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting

#4

Post by Sakura-sx »

KomoD wrote: post #3

curl -x http://xxxxx:xxxxx@geo.iproyal.com:11202 -L https://aroma.global.ssl.fastly.net/ You don't seem to be using a TCP Proxy! (If you are using a VPN or any other kind of proxy that is not a TCP Proxy, this will not detect it)

That's strange, could you try with "https://aroma.global.ssl.fastly.net/score"?

Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting

#6

Post by Sakura-sx »

agentifysh wrote: post #5

so will this detect residential proxies? how is that being done, I am getting hammered and its all legitimate normal ISP traffic.

It's done by checking the difference between the initial TCP RTT and the subsequent TCP RTTs, both of which can be retrieved from the Linux Kernel easily without the need for PCAPing. There is more info about how it is done on the README

Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting

#7

Post by 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.

Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting

#8

Post by Sakura-sx »

soldthat wrote: post #7

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…

Thank you! There are other ways of detecting L3 VPNs, but I wanted to start with proxies since they do most of the damage.

Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting

#9

Post by 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.

Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting

#10

Post by Sakura-sx »

ericpauley wrote: post #9

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 type…

I think you could also compare with TLS handshake timings, delay for client hello among other things. And you could also compare it with HTTP RTT, not to mention that you can do TCP fingerprinting and compare it with the TLS and HTTP fingerprint of the browser, you can also measure the IP TTL and ping, among many other things... What I mean is that there are a ton of things that can be done on both sides, but any company with enough people working at this and enough servers will surely make something miles away from my proof of concept, and they also have a lot of traffic to know what's baseline data and what isn't.

It's a complex but fun world we live in hehe

Post reply on HN