Sakura-sx

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

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.

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.

Thank you! Will check it out!

Yes, it's important to keep this in mind, thanks for your comment!

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!

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 proxy could be made. And for things like credit card fraud this could be quite useful.

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 regular users at all costs, I think the detection can be improved a lot by using more data and not a single division to calculate the score, in this case it's a somewhat simple PoC.

Thanks for taking the time to test it, I really appreciate it!

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 someone is in Spain but they can't be more than 400km from Australia, something went terribly wrong somewhere hehe

In hindsight I think the issue with my explanation is that I was trying to explain the differences when fingerprinting two different protocols, but ended up going for a TCP-only approach since Fastly wouldn't expose to me the data I needed for the TLS and HTTP RTT. 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.

I think I will edit the README in the future since I don't like how it turned out too much. Thanks for the feedback!

By the way, it detects Tor, I tested it ;D

I guess for this to work best you'd build your own CDN and have as many servers as possible. I have always dreamed of an Open Source CDN managed by a nonprofit and dedicated to offering CDN services for free or for a reasonable cost.

If you did the timings by comparing to other protocols, like TLS or HTTP you could do this with a single server, but that's a bit more complex than doing it on the same protocol since you have to account for more stuff, but it could be done, at the end of the day, my idea with Aroma was mostly to prove that it's possible, thanks for the feedback btw!

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

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

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

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

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

Thanks!

I advice either monkeytype or keybr, both have a setting for code

Thanks!!!

Thanks for the idea, added to roadmap!

keybr's algorithm is flawed, getting 1 extra WPM on "q" does way less progress than getting 1 extra WPM on "e", it's better than most of the things but also I wouldn't have made typr if it was perfect.

You are right, I didn't know what it was when posting.

Thank you for the stars, just went from 1 to 27 stars! :3

Thank you!

More characters soon, thanks for the suggestion!

Not really, most DDoS attacks are made from servers, taking down those servers makes the attacker need to get new ones. And from the logs I can assure you that 90% of the time it is a server, and the rest it is either residential IPs or VPNs but residential IPs are seen more i'd say.

I have been a user of keybr.com for a long time, and I didn't really like things like for example only practicing one word at a time or the algorithm trying to force you to type each character at the same speed, that's why I made my own. It has an algorithm that selects words randomly with weights based on how long you take to type each letter, you accuracy with each letter and how common the letter is in English (you should type more-common letters faster!).

No, it is there to make money, if their free plan included perfect DDoS protection no one would get the more pricier ones.

If your goal is to decentralize the web, you can buy our offerings at Voxga Research (voxga.es). We are a direct competitior to Cloudflare on the DDoS protection space.

Yeah, many DDoS attacks get through cloudflare's lower tier plans, in fact bypassing cloudflare free is considered the bare minimum for a "stresser".

Sir, I work against Cloudflare's monopoly on Voxga Research. But for a lot of people it is practical.