Live data from Hacker News

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

github.com

31–40 of 57 posts

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

#31

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

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.

Not if you receive the HTTP request from the client first, before any interaction with the end-host.

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

#32
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)

pardon my ignorance but it's a HTTP proxy not a TCP one. is not it? ... or is it considering that https upstream goes through "CONNECT" request?

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

#33

Earlier quoted context omitted.

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.

Not if you receive the HTTP request from the client first, before any interaction with the end-host.

If the proxy can "see" the requests, then this isnt an issue because the headers can be trivially be modified.

The problem is that the proxies which are targets of identification - think proxies for large scale web scraping which use CONNECT tunnels - dont get to "see" the request.

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

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

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

#35
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)

pardon my ignorance but it's a HTTP proxy not a TCP one. is not it? ... or is it considering that https upstream goes through "CONNECT" request?

A request to a HTTPS target through a proxy will use a CONNECT request to establish a tunnel to the target.

This tunnel operates at layer 3, where the client sends TCP segments to the proxy, the server unpacks the segments and then repacks them into new segments to send to the end target. These new TCP segments will contain the timestamp of when they were created.

The HTTP request sent through those segments is unmodified, meaning it will contain the original timestamp from the client machine.

The newer timestamp on the TCP segments means there is a mismatch between the TCP RTT and the HTTP RTT.

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

#36

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

The most common method of proxying with residential proxies is still CONNECT tunnels and from my tests it catches a resi-proxy about 50% of the time. More with tuning of the score thresholds.

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

#37

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

I think for stealth TCP proxies are more common since you can use your own TLS fingerprints and all of that, with something like an HTTP proxy you'd need to set up your requests to match with the TLS fingerprint that the proxy is using, although I guess the proxy could make the TLS look the same? There are other ways of detecting HTTP proxies like for example comparing with the RTT of websockets or something like that, the idea is that there will always be at least one thing with RTT from the proxy and at least the RTT for one thing from the client that must go trough the proxy, you measure the difference between the two and there you have it.

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

#39

Would a similar technique work for tunnels through QUIC?

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.

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

#40
post #39

Would a similar technique work for tunnels through QUIC?

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.

Post reply on HN