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.
Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
21–30 of 57 posts
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#22This 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.
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#23Earlier quoted context omitted.
Are you using a proxy? If you aren't that would be concerning, since false positives are way worse than false negatives. If you are then it means the score is sometimes a bit lower and sometimes a bit higher than 0.1, which is the threshold for getting blocked. If you want to know the exact score, you can check https://aroma.global.ssl.fastly.net/score It's set at a low threshold since I want to avoid blocking regula…
I'm testing using our residential proxies. It's a super cool tool, I've been wondering about an open source tool doing this since reading about the technique in one of Nikolai Tschacher's blog posts years ago ( https://incolumitas.com/pages/about/ ). There's a few ways to work around this, but I think it's one of the best signals available to detect low-effort/common proxy providers.
Oh I haven't seen that before, it's really cool, thank you for showing me that!
I want to clarify that the approaches are a bit different, they use IP intelligence too and this approach doesn't use any kind of websockets, which is a really good idea, and I have to admit I didn't think of that, but sadly it's not really possible to do it with Fastly.
Another big difference is that this could work with any TCP application, not only HTTP, and if you do it with HTTP/S you can know if it's a proxy or not on a request basis and totally passively, without adding any delay or changing the code of the app.
But yeah, it's a really cool demo, thanks again!
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#24Very 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.
First of all, thanks! I imagine any big CDN implementing something like this could keep a database of all of this, combined with the old kind of IP intelligence and collecting not only RTT on other protocols like TLS, HTTP, IP (aka ping, and traceroutes too), TCP fingerprint, TLS fingerprint, HTTP fingerprint... And with algorithms that combine and compare all these data points, I think very accurate models of the pr…
[deleted]
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#25Just 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.
Yes, it's important to keep this in mind, thanks for your comment!
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#26Why 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?
Surveillance, on the part of those who want to do this fingerprinting.
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#27If 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
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#28If 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
Thank you! Will check it out!
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#29The 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.)
Re: Show HN: Aroma: Every TCP Proxy Is Detectable with RTT Fingerprinting
#30The 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.)
The issue is that if HTTP is an extra 50ms than TCP for example, if you increase TCP by 50ms now HTTP is 100ms more. Basically it is always more no matter how much you increase it.