Activity
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.
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 0default 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 haveExcludeSingleHopRelays 1default and also aAllowSingleHopCircuits 0but I guess RSOS overwrites these in order to work.
-
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 0default 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 haveExcludeSingleHopRelays 1default and also aAllowSingleHopCircuits 0but 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?)
Trac:
Milestone: Tor: unspecified to Tor: very long term
Priority: Medium to Very Low
Keywords: N/A deleted, wontfix? addedAdded #21294 (moved) for the single-hop exit issue.
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?
-aReplying 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)).
(I opened #21295 (moved) for the OnionShare use case wanting mixed singe onion services and hidden (double onion) services in the same tor instance.)
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).
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).
-
Replying to cypherpunks:
I made a patch for 0.3.4.x for this option, but sadly {{{ --enable-tor2web-mode }}} disappeared?
Yes, Tor2Web was removed, because it was unsafe for users.
