← Back to context

Comment by orbital-decay

16 hours ago

Also DDoS becomes a problem, and the ways it's done are pretty specific to Tor. Double captchas are necessary when you're getting DDoSed, due to performance reasons. Oh, and captchas are also pretty specific to Tor as well.

There's also a problem of site fronting. Anyone could run a proxy pretending to be you, for arbitrary reasons (not even necessarily the obvious forging and credential stealing). Every site, even a personal blog, has dozens of parasitic fronts, either actively malicious or dormant. You need off-site ways to tell users what is the real address, and provide a smoke test for them (often a part of the address as a picture, for example in a captcha).

>avoid JS for them

Using any JS defies the point and makes your site instantly suspicious.

> There's also a problem of site fronting. Anyone could run a proxy pretending to be you, for arbitrary reasons (not even necessarily the obvious forging and credential stealing). Every site, even a personal blog, has dozens of parasitic fronts, either actively malicious or dormant. You need off-site ways to tell users what is the real address, and provide a smoke test for them (often a part of the address as a picture, for example in a captcha).

How can you do this without relying on the normal web? Let’s say you use a normal website to show the onion link, if the website gets taken down, you lost your user-trusted mean to do that.

  • >How can you do this without relying on the normal web?

    How can you trust anything you haven't experienced personally? By using chains of trust, of course. There are directories that list onion sites, and also sites that link to their peers. That way you can be sure you're still in the same bubble at least, and convert the problem into trusting the entire bubble. It's not automated and pretty ad hoc, if that's what you're wondering. Automation in Tor has a history of being circumvented or exploited with novel scams, this is an adversarial environment.

I've done some searching and can't find a description of "site fronting" that fits with my read of your comment.

I thought the whole point of Tor is that I (and only I) am able to serve traffic at a .onion URL that I have generated. How could someone else get in front of that?

  • The attacker simply proxies your site on another .onion address and advertises that fake address in a popular directory or an ad. Any visitors coming through that fake URL interact with your site through the attacker's front. Since .onion URLs aren't easy to tell apart, this kind of phishing works well. If you run a discovery bot you can observe that the .onion zone is full of these fake fronts for all kinds of sites, because even if your site aren't of any interest to an attacker but you link to any other site, then the attacker of that site needs to front yours with that link replaced with a fake, to create a separate circle of trust for the victims.

    That's why you need to very carefully choose a trusted entry point into the Torosphere and revise your choice from time to time; always remember your initial entry point because if there's any suspicious drama around it or if you notice a mismatching link on different sites, you might have been duped to enter an impersonator-controlled bubble.

    Many things can be done about it: claiming your spot in the directories, smoke test captchas, chains of trust, or you can brute force your .onion to find a valid one that starts with a memorable string (the longer the better, but also the harder). Vanity addresses like this deter non-targeted adversaries by requiring proof of work to forge the lookalike URL. None of that is bulletproof, of course.

How are captchas done?

  • A combination of different ones, sometimes close to what you know from the clearnet, i.e. click pictures that match a description. For the proxy defeating one, the server can send you a picture of the real .onion address where some letters are blanked out, and with noise added to it to prevent it from being solved by the proxy. You then have to enter the blanked out letters from the browser URL.

    This can of course still be defeated if the proxy URL receives very few requests and just have a human in the middle to solve the CAPTCHAs. But it does make the attack non-automated.