@Negreheb - @maltfield seems to have mentioned that (how an onionsite helps against DDoS) in this thread itself, but nobody seems to be acknowledging it.
@ravidwivedi and @maltfield - thanks for contributing to the discussion and (unlike most others) understanding the importance of Tor.
Thatâs because the tor proponents have so far offered a bunch of handwaving about its benefits and an onion site pointing to a blog about how to use tor for your wordpress site as their proof of concept. And, nobodyâs actually answering the OWG questions about how this all plays during a DDoS attack. So Iâm hardly surprised at the lack of interest.
I donât have anything additional to add about using CloudFlareâs âevilnessâ in general, despite my agreement, but I see that Tor is not actually blocked as a whole on api.openstreetmap.org. I really would love to submit changesets again through JOSM even if there are sporadic time frames in which I can submit changes. I am reiterating what I wrote in the preceding thread linked in the OP. With Tor Browser I can retrieve the XML of this page just fine without any intermediate CAPTCHA checkpoints: https://api.openstreetmap.org/api/capabilities
This is what I think is happening when I use JOSM with Tor:
CloudFlare has already assigned Tor exit nodes a high threat score based on traffic history
Few or no IPs actually have a threat score high enough to be totally blocked in terms of CloudFlareâs threat level as designated by OSMâs configuration
A high threat score results in a more in-depth probe (again, still not an absolute block based on IP address alone)
Either:
a) Under the more in-depth probe, the User-Agent (HTTP header) for java.net.HttpURLConnection is simply recognized as non-human or a non-browser and rejected
And/or:
b) The more in-depth probe blocks unusual combinations of user agents and TLS fingerprint (list of ciphers and the order they are presented in the handshake) - thus, Tor Browser works fine with its extremely common User-Agent and TLS fingerprint combination which may even match certain ânormalâ Firefox ESR fingerprints - and JOSM with java.net.HttpURLConnection and whatever TLS fingerprint is extremely uncommon and blocked
I emphasize again that Tor isnât actually blocked on api.openstreetmap.org at this moment. Itâs just that using JOSM even for a GET request is blocked. I canât say if normal POST requests will behave the same way with the low IP address reputation and the Java/JOSM fingerprint. I have tried POST to /api/capabilities with body âPOST=helloâ using my Tor Browserâs developer tools and the API reports only a 404 which looks promising. If I try the same with a mimicked SQL injection I unsurprisingly get a 403: âPOST=OR%201%20=%201â (âOR 1 = 1â) - and back to 404 if I try another request with a ânormalâ payload.
Itâs upsetting about CloudFlare in general that this is apparently discrimination (outside of this specific JOSM context) against unusual browsers. Itâs just like with e-mail servers (allegedly?) being more difficult to self-host these days due to discrimination by mainstream e-mail services.
Finally, I agree that Tor and Tor Browser should be part of whatever testing pipelines just so the effect of changes on Tor users is understood, whether or not it has on any impact on firewall policy.
I have never set up an onion site nor defended against a DDoS attack, so the best I can do is link to some resources and documentation, which are all a trivial web search away.
Resolve the relevant hostnames (openstreetmap.org, api.openstreetmap.org, www.openstreetmap.org) to the original OSM server so that the traffic continues to go via Tor, but no longer via Cloudflare.
They do. Therefore, measures should usually be taken to ensure that the new IP address cannot be determined so easily.
This is explained well here:
In this case, it seems to be a less sophisticated attacker. Probably someone who has rented a botnet to make some money. The attacker is probably now looking for an easier target.