Opened 20 months ago

Last modified 8 months ago

#21284 new enhancement

Add torrc option for non-anonymous SocksPort

Reported by: teor Owned by:
Priority: Very Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, single-onion, eotk-wants, wontfix?
Cc: Actual Points:
Parent ID: Points: 1
Reviewer: Sponsor:

Description

Some single onion service users want to use the running tor instance for a single onion service, and fetching files over tor. They don't care about their anonymity.

One workaround for this issue is to compile tor with --enable-tor2web-mode. Another is to run a separate tor instance for file transfers.

We could add a SocksPortNonAnonymousMode to make this easier, but that could also make it easier for users to lose their anonymity.

Child Tickets

Change History (15)

comment:1 Changed 20 months ago by dgoulet

SocksPort 9050 NonAnonymousMode maybe?

comment:2 Changed 20 months ago by asn

I'm starting to feel overwhelmed by the amount of code and torrc options we've been shoving into the RSOS feature.

Personally, I'm inclined to say that people who want this sort of weird feature should run two Tor instances at the same time. The alternative is us having to introduce yet another torrc option for use by two people worldwide.

comment:3 Changed 20 months ago by s7r

I fully agree with asn - a lot of complications for a very weird and rare use case.

Wonder why would someone really want this... This kind of like wanting to take a shower without getting wet. While there are obvious, plenty, demanded use cases for RSOS (very happy to have it), I can't see at least one for downloading files non-anonymously over Tor.

Let's think if this option would not be actually useless and/or impossible to implement before further discussing use cases. It's unclear to me:

  • a Tor instance running a single onion service is not anonymous because it only builds single hop circuits (to introduction points and rendezvous relays) except for HSDirs when uploading descriptors when normal 3 hop circuits are used. In this case, SocksPort circuits can also be regular, 3 hop, so will this truly be 100% non anonymous? It might affect anonymity in unknown ways, but we don't know for sure.
  • other way around, if the SocksPort circuits are single hop because this is the only way single hop onion services can also work on the same Tor instance, how will exiting even work since Exit relays do not allow exit traffic on single hop circuits. We have AllowSingleHopExits 0 default on relay side, so all Exit relays will not allow it. Even if there were few configured to allow it, on the client side we have ExcludeSingleHopRelays 1 default and also a AllowSingleHopCircuits 0 but I guess RSOS overwrites these in order to work.

comment:4 in reply to:  3 Changed 20 months ago by teor

Keywords: wontfix? added
Milestone: Tor: unspecifiedTor: very long term
Priority: MediumVery Low

Replying to s7r:

I fully agree with asn - a lot of complications for a very weird and rare use case.

Wonder why would someone really want this... This kind of like wanting to take a shower without getting wet. While there are obvious, plenty, demanded use cases for RSOS (very happy to have it), I can't see at least one for downloading files non-anonymously over Tor.

Let's think if this option would not be actually useless and/or impossible to implement before further discussing use cases. It's unclear to me:

  • a Tor instance running a single onion service is not anonymous because it only builds single hop circuits (to introduction points and rendezvous relays) except for HSDirs when uploading descriptors when normal 3 hop circuits are used. In this case, SocksPort circuits can also be regular, 3 hop, so will this truly be 100% non anonymous? It might affect anonymity in unknown ways, but we don't know for sure.

Yes, I agree. This is why we don't do mixed-mode anonymous and non-anonymous tor instances.
The workaround is to use --enable-tor2web-mode, which does allow single-hop SOCKSPorts.

  • other way around, if the SocksPort circuits are single hop because this is the only way single hop onion services can also work on the same Tor instance, how will exiting even work since Exit relays do not allow exit traffic on single hop circuits. We have AllowSingleHopExits 0 default on relay side, so all Exit relays will not allow it. Even if there were few configured to allow it, on the client side we have ExcludeSingleHopRelays 1 default and also a AllowSingleHopCircuits 0 but I guess RSOS overwrites these in order to work.

No, it doesn't. So single-hop SOCKSPorts might just end up failing. I should tell Alec this.

(Marked as low-priority, long-term, wontfix?)

comment:5 Changed 20 months ago by teor

Added #21294 for the single-hop exit issue.

comment:6 Changed 20 months ago by alecmuffett

In terms of use cases, the goal is to simplify OnionBalance adoption to drive scale; anyone who is running Single Hop Circuits is unlikely to care about remaining anonymous, so it seems odd to ban them from SOCKS merely to drive the point home?

It turns into administrative burden: if I am choosing to use Onions for greater integrity and disintermediation/NAT-punching, that the software inhibits me from accessing (say) Debian updates over Tor (unless I launch another daemon to overcome this handicap) seems bizarre.

Surely it took more code to deny everyone this feature, than it would take to enable it?

-a

comment:7 Changed 20 months ago by alecmuffett

tl;dr - you appear to be complaining about writing code that is necessary for this scenario to bypass code that has already been written on the presumption that my intention was/is "a bad thing" ?

Last edited 20 months ago by alecmuffett (previous) (diff)

comment:8 Changed 20 months ago by alecmuffett

pps: it's not about "downloading files non-anonymously over Tor", it's about pushing to every other member of an OnionBalance cluster.

comment:9 in reply to:  6 ; Changed 20 months ago by teor

Replying to alecmuffett:

In terms of use cases, the goal is to simplify OnionBalance adoption to drive scale; anyone who is running Single Hop Circuits is unlikely to care about remaining anonymous, so it seems odd to ban them from SOCKS merely to drive the point home?

As s7r noted, Exits already ban single-hop circuits, so if we had naïvely allowed a single-hop SOCKSPort, it might only have worked when accessing onion services as a client. Which would have been a terrible user experience.

It turns into administrative burden: if I am choosing to use Onions for greater integrity and disintermediation/NAT-punching, that the software inhibits me from accessing (say) Debian updates over Tor (unless I launch another daemon to overcome this handicap) seems bizarre.

Surely it took more code to deny everyone this feature, than it would take to enable it?

The code to deny the feature is ~10 lines of boilerplate. It's easily removed or made conditional.

Replying to alecmuffett:

tl;dr - you appear to be complaining about writing code that is necessary for this scenario to bypass code that has already been written on the presumption that my intention was/is "a bad thing" ?

No, your intention is fine. It's completely understandable that you want to connect to other onion services or internet sites through the same tor instance you have running a single onion service. We just didn't discover this use case during the proposal process, or the discussions on tor-dev about single onion service use cases. That's on me - I could have asked better questions, or asked more people.

(We've prevented or warned against combinations like this in the past because they have anonymity implications, but that's not an issue here.)

I have no issue with implementing this feature, I just want to design it so that it works (it must be multi-hop to access exits), and that it has an appropriate user interface (clearly documented torrc option(s)).

comment:10 Changed 20 months ago by teor

(I opened #21295 for the OnionShare use case wanting mixed singe onion services and hidden (double onion) services in the same tor instance.)

comment:11 in reply to:  9 Changed 20 months ago by teor

Replying to teor:

Replying to alecmuffett:

In terms of use cases, the goal is to simplify OnionBalance adoption to drive scale; anyone who is running Single Hop Circuits is unlikely to care about remaining anonymous, so it seems odd to ban them from SOCKS merely to drive the point home?

As s7r noted, Exits already ban single-hop circuits, so if we had naïvely allowed a single-hop SOCKSPort, it might only have worked when accessing onion services as a client. Which would have been a terrible user experience.

I checked the code:

  • the single onion service code only changes service intro and rend circuits, and
  • Tor2Web only changes client intro and rend circuits.

So exits remain 3-hop regardless, and would work ok if you used the --enable-tor2web-mode workaround (or any option we might add that does the same thing).

comment:12 in reply to:  7 Changed 20 months ago by s7r

Replying to alecmuffett:

tl;dr - you appear to be complaining about writing code that is necessary for this scenario to bypass code that has already been written on the presumption that my intention was/is "a bad thing" ?

Your intention is perfectly fine (downloading files non-anonymously over Tor is what was described initially). I am not complaining about writing code in any way, I am complaining that we might add code that will be useless, will not help and just make things even more confusing for users.

For example, it's false to say non-anonymous SocksPort, because it has to be 3 hops, otherwise it won't work for exit traffic. So, it might be as anonymous as in a normal Tor, it might be less anonymous in some unknown ways, or it might be totally non anonymous but to assume something would be false. This is the initial reason why the restriction to run in anonymous way and RSOS in the same instance was introduced, and I think it was our best move in this context, where we can't just assume something.

While I do understand your (maybe unique) complicated use case, there are two existent options which seam reasonable and fulfill the requirements:

  • run another instance for the SocksPort only - this will preserve anonymity as well if desired;
  • compile with --enable-tor2web-mode - since the code for this already exists, does the job just fine and will be more light on the resources in the network if anonymity is not desired (won't use a guard and just do 1 hop circuits).

comment:13 Changed 11 months ago by teor

Keywords: eotk-needs added; wontfix? removed
Milestone: Tor: very long termTor: 0.3.3.x-final

Requested by alecmuffett for EOTK.

comment:14 Changed 11 months ago by nickm

Keywords: eotk-wants wontfix? added; eotk-needs removed

I am not sure. I'll leave it in 0.3.3 for now, but I'm adjusting the keywords again.

comment:15 Changed 8 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: unspecified
Note: See TracTickets for help on using tickets.