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

41–50 of 57 posts

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

#41

Post by Manouchehri »

JDye wrote: post #19
Sakura-sx wrote: post #17

Earlier 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.

Would you be open to offering MASQUE proxying? I started to as support to GOST, been testing with Bright Data (only for UDP sadly, not TCP), but would love to see others add support so I could test with more than just 1 vendor.

https://github.com/go-gost/x/pull/75

https://github.com/go-gost/x/pull/76

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

#42

Post by AnthonyMouse »

Sakura-sx wrote: post #15
vlovich123 wrote: post #13

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

About the straightline path I did think of that but apparently I forgot to address it when writing the README :p The point I was trying to make is that if the RTT is low enough you can know the connection is being made from close, it's an upper bound, and making some assumptions you can get it lower, so it's not a way of knowing the exact distance but rather the max distance the connection can be made from. If someon…

> But in theory fingerprinting with protocol RTT difference where one protocol is proxied and the other is impossible to bypass, but this is only the theory.

Alice wants you to think she's in New York when she's really in Taipei, so she gets a VM in New York and runs a browser in it via RDP. How are you detecting this?

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

#43

Post by Sakura-sx »

AnthonyMouse wrote: post #42
Sakura-sx wrote: post #15

Earlier quoted context omitted.

About the straightline path I did think of that but apparently I forgot to address it when writing the README :p The point I was trying to make is that if the RTT is low enough you can know the connection is being made from close, it's an upper bound, and making some assumptions you can get it lower, so it's not a way of knowing the exact distance but rather the max distance the connection can be made from. If someon…

> But in theory fingerprinting with protocol RTT difference where one protocol is proxied and the other is impossible to bypass, but this is only the theory. Alice wants you to think she's in New York when she's really in Taipei, so she gets a VM in New York and runs a browser in it via RDP. How are you detecting this?

I am not detecting that, I am just detecting L4 proxies for now sob

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

#44

Post by JDye »

Manouchehri wrote: post #40
JDye wrote: post #39

Earlier quoted context omitted.

I mentioned this in a podcast recently; fingerprinting of proxy servers using QUIC is a lot harder as UDP doesnt have enough headers to allow for unique characteristics like a TCP does. Theres no way to include a timestamp in a UDP datagram so all timestamps received would be from the client machine.

Interesting! So far I've only seen Bright Data (among the large players) offer UDP proxying over QUIC/HTTP3, but that's pretty limiting since less than half of sites have HTTP/3 enabled to begin with.

BrighData offer H3/QUIC but only in beta and you have to contact their sales team as far as I'm aware.

We (PingProxies) might be the only company to offer H3 to the proxy/QUIC to the target using the CONNECT-UDP method publicly. Although, it is in beta/unstable until I merge my changes into Rust's H3 library.

If you wanna play around with it, email me and I'll get you some credit. I think theres potential for stealth since outdated proxy clients/servers mean automated actors never use H3.

The proxy industry is full of another 100 companies saying they offer H3/QUIC, when they mean UDP proxying using SOCKS. I suppose the knowledge gap and what customers care about (protocol to end target) is very different to what I care about (being right/protocol to the proxy server).

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

#45

Post by JDye »

Manouchehri wrote: post #41
JDye wrote: post #19

Earlier quoted context omitted.

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.

Would you be open to offering MASQUE proxying? I started to as support to GOST, been testing with Bright Data (only for UDP sadly, not TCP), but would love to see others add support so I could test with more than just 1 vendor. https://github.com/go-gost/x/pull/75 https://github.com/go-gost/x/pull/76

[dead]

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

#46

Post by dlenski »

moreati wrote: post #20

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?

Came here to ask the same thing. Why do I _care_ if connections to my server come from a TCP proxy? Particularly when a VPN is _not_ observable in a similar way?

Is there some class of bad actors who extensively use TCP proxies and not only _don't_ use VPNs, but would incur large costs in switching to them?

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

#47

Post by JDye »

dlenski wrote: post #46
moreati wrote: post #20

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?

Came here to ask the same thing. Why do I _care_ if connections to my server come from a TCP proxy? Particularly when a VPN is _not_ observable in a similar way? Is there some class of bad actors who extensively use TCP proxies and not only _don't_ use VPNs, but would incur large costs in switching to them?

Web scrapers maybe aren't "bad actors", but many sites dont want them. They'll use tons of TCP proxies which route them through a rotating pool of end user devices (mobiles, routers, etc...). Its not really possible to block these IPs as you'd also be blocking legitimate customers so other ways to detect and block are required.

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

#48

Post by dlenski »

Rasbora wrote: post #22

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

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

https://github.com/sshuttle/sshuttle basically works like this. I've used it for many years. I don't think it'll be possible to detect using this technique.

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

#49

Post by Manouchehri »

JDye wrote: post #44
Manouchehri wrote: post #40

Earlier quoted context omitted.

Interesting! So far I've only seen Bright Data (among the large players) offer UDP proxying over QUIC/HTTP3, but that's pretty limiting since less than half of sites have HTTP/3 enabled to begin with.

BrighData offer H3/QUIC but only in beta and you have to contact their sales team as far as I'm aware. We (PingProxies) might be the only company to offer H3 to the proxy/QUIC to the target using the CONNECT-UDP method publicly. Although, it is in beta/unstable until I merge my changes into Rust's H3 library. If you wanna play around with it, email me and I'll get you some credit. I think theres potential for stealth…

> BrighData offer H3/QUIC but only in beta and you have to contact their sales team as far as I'm aware.

That's what I thought too, but it's working for me. (I've sent a lot of tickets, maybe they've put our account as something special without telling me, but doubt it.)

> If you wanna play around with it, email me and I'll get you some credit.

Done, emailed! :) Thanks!

> The proxy industry is full of another 100 companies saying they offer H3/QUIC, when they mean UDP proxying using SOCKS.

Out of the large players I've tested, none actually seem to even support SOCKS5's UDP ASSOCIATE. (I have not tested PingProxies yet.)

> I suppose the knowledge gap and what customers care about (protocol to end target) is very different to what I care about (being right/protocol to the proxy server).

I think there's a knowledge gap between the people making the sales landing pages, and the folks who actually run/maintain the proxy servers. There's some large vendors that advertise UDP support (for residential and/or mobile proxies) that I have yet to actually see working.

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

#50

Post by ranger_danger »

Sakura-sx wrote: post #4
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 "?

I got 0.295 with a mptcp'd proxy
Post reply on HN