The security implications are that Cloudflare can read everything you send to or receive from the server, including your cleartext password and any PMs you send or look at.
Is there an official .onion proxy of BitcoinTalk that bypass Cloudflare? We do sometimes get support request PMs.
How about BitcoinTalk Pro accounts with monthly payments, private proxy without Cloudflare and captchas, bot access?
Thank you. A Bitcointalk .onion was on my mind all week, together with other anti-DDoS mitigation ideas about which I hope to write up suggestions. It is also something I may perhaps, maybe, perhaps be willing to not only
talk about (hint, hint).
.onion sites already have less exposure to DDoS than sites on the open Internet. Connections to .onion have no access to a full network stack—only to streams through Tor’s circuit protocol, a custom stream transport layer. No TCP handshake tricks, no amplified UDP floods to clog the pipes, etc. I suppose theymos’ “homebrew” anti-DDoS had already stopped those. But also, the capacity limitations and cell queuing mechanisms of the Tor network and its nodes provide some upper bounds on any type of DDoS which uses high bandwidth. That leaves (1) specialized attacks against the Tor onion proxy, (2) DDoS against introduction points, and (3) any relatively moderate-/low-bandwidth application-layer attacks. (“Relatively” compared to DDoS which uses tens or hundreds of gigabits per second.)
For (1), lock down that onion proxy tight and isolate it from the web backend—which you should do anyway. At least it can’t take down the site itself, or affect reachability from clearnet. Better still, use
onionbalance with multiple onion proxies; that gives load-balancing and failover, and also permits isolating v2 .onion private keys from the machines handling visitor traffic. (2) is really a Tor network issue, though maxing out your intro points with onionbalance will help. For (3), well, as always—don’t run poorly designed software. nginx is already robust against HTTP-level DDoS; I have no idea about the vulnerability profile of SMF, other than that it’s database-intensive forum software written in PHP. I guess, start by disabling the search function through .onion...
I don’t see why a monthly paid subscription should be required. If that was intended as an idea for .onion, it would effectually restrict .onion use to people who directly make money off the forum—signature campaigners, etc. Instead, to prevent abuse, I’d suggest that full posting privileges through .onion be restricted to full Members or paid Copper Members. (I am
guessing that Junior Member accounts may be too cheap on the account sale market, especially for hacked accounts.) .onion posters without those ranks should be restricted through a “newbie jail”-like system. Those who could not afford paid membership, could spend a few months ranking up in the .onion jail—or through clearnet exits, just like now. For spammers and scammers, throwaway accounts would be prohibitively expensive.
Perhaps also add a “.onion” tag below the username and rank for posts made through .onion. I am reluctant to suggest that, given the level of prejudice some people have against Tor users; but I don’t think the moderators here have such a bias, which is the important part to me, personally. I myself would be proud to wear a “.onion” tag. I would explicitly add it, if it were offered as an option.
For a non-location-hidden .onion, as I presume this would be, single-onion mode should be snappy for users. Projects such as
Debian and
Tor Project successfully run high-bandwidth services such as public apt repositories through .onions, using onionbalance. Debian users can do all their OS updates without ever touching clearnet! Use of .onion also helps the Tor network, by shifting load off the bottleneck of exit nodes. Any relay can serve as as a rendezvous point, including the far more numerous “middle nodes”.
Note that any .onion version of the forum must be verified to work with Javascript disabled. Excepting signup and login functions, basic functionality seems to work fine that way.
Anything that diminishes spam and pernicious assaults is great as I would like to think.
Cloudflare’s effect on spam should be somewhere between negligible and nil. It’s an anti-DDoS reverse proxy network and caching CDN; it also filters out attacks against braindead applications which can’t handle Bobby Tables. I don’t see how it could help much against spam; how could the HTTP requests involved in spam posts be distinguished from legitimate network traffic? Especially the spam posts made by nominal humans? Though I suppose that forum spam is a wetware-layer DDoS. It does “deny service” when the forum is unreadable.
Anyone registering through tor has to pay a small bitcoin fee, so all those users have bitcoin addresses associated with their accounts.
that's only if the exit node ip has points of evil associated with it though, i could imagine some new nodes might not have any points linked to them.
I wonder whether theymos’ “evil IP” system uses the publicly known IPs of Tor exits, as published in the consensus. It would make sense to charge a set price to all Tor users, rather than varying the fee by measurements taken on a particular exit IP. But
n.b., not all exits actually exit through the same IP as they use for their ORPort. I recall some research finding that as many as 10% of exits did otherwise. This is useful for avoiding blocks, but risky for node operators since the IP is not listed in the “exonerator”.
