>I ran a tor webserver for discussing geopolitics with friends on a pi for a few months before finding it had been compromised.
Not the fault of Tor. HSDir nodes could snoop on announced v1 .onion adresses. This isn't the case anymore for Onion v2 addresses.
But even if an attacker has the onion address of your webserver, he needs a way to compromise it.
Either through a vuln in your website or your webserver.
I've found the clearnet IP of some darknet markets by typing their <title> into the text input at search.censys.io. That's such poor opsec that I have to assume I identified a phishing proxy to the market rather than the actual origin server of the market itself.
It is really hard to believe that a malicious actor is throwing expensive tor 0-days at random onions.. or your website to "discuss geopolitics with friends" was a bit greater.
In both cases you could run a honeypot to catch 0-days.
the webserver was a simple nanohttp hackup on the oracle jvm, so Ill take some convincing java has an rce in its network stack, and they disguised it by spawning a process on the tor user after hacking the OS and covering that up sufficiently to leave no other evidence.
The only reason I spotted it was because I was checking for compromise by comparing any file/process changes every few weeks.
It was a few years ago, my guess back then was tor is the honeypot, given what happened recently with encrochat I wouldnt be surprised if a few years down the line it turns out it was.
Or maybe I misconfigured the server, or maybe the binary I used for tor was compromised, it was as much a test for whether I could trust tor as anything else and it failed. delete, move on.
The FBI has done this before - inject a browser exploit into a site they compromised to identify its users.