Using hidden services to replace exit nodes

[gus]

@everydayisoks

I strongly believe that using hidden services instead of exit nodes does not require the developer to modify the Tor source code, but rather just a simple configuration. I hope developers will take my suggestion seriously.

Georgetown GUSecLab implemented the concept of Exit bridges (with and without onion services):

Tor exit blocking, in which websites disallow clients arriving from Tor, is a growing and potentially existential threat to the anonymity network. We introduce two architectures that provide ephemeral exit bridges for Tor which are difficult to enumerate and block. Our techniques employ a micropayment system that compensates exit bridge operators for their services, and a privacy-preserving reputation scheme that prevents freeloading. We show that our exit bridge architectures effectively thwart server-side blocking of Tor with little performance overhead.

Website: Bypassing Tor Exit Blocking

Video presentation: https://dl.acm.org/doi/10.1145/3372297.3417245

Code: GitHub - GUSecLab/tor-exit-relays

Papers:

• Ephemeral Exit Bridges for Tor | IEEE Conference Publication | IEEE Xplore
• https://dl.acm.org/doi/10.1145/3372297.3417245

Tor forum link:

Why not add the ability to add a proxy in the circuit after the exit node in case a website is blocking Tor?

I think that’s just a palliative solution that wouldn’t help Tor users in the medium term. For regular Tor users, that would not scale well. But, if you’re trying to solve the Captcha issue and/or websites blocking Tor users, there are more interesting projects and approaches. For example: Monitoring Exit nodes IP reputation and Captchas. We could work with exit nodes operators to rotate their IP addresses more frequently. A ‘Privacy-pass’ like solution. A project that would require more engi…