Opened 3 years ago
Last modified 6 months ago
#21117 assigned defect
can't migrate onion services to single-hop onion services
Reported by: | weasel | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | Tor: unspecified |
Component: | Core Tor/Tor | Version: | Tor: 0.2.9.8 |
Severity: | Normal | Keywords: | tor-hs, single-onion, 034-triage-20180328, 034-removed-20180328 |
Cc: | asn | Actual Points: | 0.1 |
Parent ID: | Points: | 1 | |
Reviewer: | Sponsor: |
Description
The documentation says that it's not possible to use onion services that were once single-hope as non-single-hop anymore.
However, Tor won't let you transition in either direction, which is surprising from reading the manpage.
Tor should let you transition. Certainly in one direction, probably in both. Maybe - if you insist - by adding a new option.
Child Tickets
Change History (32)
comment:1 Changed 3 years ago by
comment:2 follow-up: 5 Changed 3 years ago by
To be clear, the anonymous->nonanonymous transition is dangerous for obvious reasons.
But the nonanonymous->anonymous transition is dangerous for the subtle reason that you are likely to think that it's giving you privacy, when it isn't: you've already exposed the link between you and the hidden service if you've *ever* run it in a nonanonymous mode.
comment:3 Changed 3 years ago by
Parent ID: | → #21049 |
---|
comment:4 Changed 3 years ago by
[best case scenario is the whole poisoning anti feature go away entirely]
comment:5 Changed 3 years ago by
Replying to nickm:
To be clear, the anonymous->nonanonymous transition is dangerous for obvious reasons.
I think this direction is the one that this ticket is about.
If the user goes through the steps of trying to transition their double onion service to a single onion service, including the extra "no really I mean it" torrc lines, doesn't that imply that they have considered and accepted the obvious reasons?
comment:6 Changed 3 years ago by
Actual Points: | → 0.1 |
---|---|
Keywords: | tor-hs single-onion added |
Points: | → 1 |
Status: | new → needs_review |
My branch bug21117 updates the documentation to describe the current implementation, including both transitions being prevented by tor.
It also describes a workaround to enable transitions for individual keys.
I am happy to implement yet another option that ignores the poisoning state if that's the way we want to go.
comment:7 follow-up: 8 Changed 3 years ago by
(Or do we want an option that's a once-off "fix the poisoning state", so that users can use it during the transition, but have future transitions prevented?)
comment:8 Changed 3 years ago by
Replying to teor:
(Or do we want an option that's a once-off "fix the poisoning state", so that users can use it during the transition, but have future transitions prevented?)
weasel asked me to clarify this on IRC:
How should the new single onion transition torrc option work?
- disable the poisoning check, but not change the poisoning state
- change the poisoning state to match the current HiddenServiceNonAnonymousMode setting (a "sticky" option)
This only makes a difference if the transition torrc option is turned off afterwards.
comment:9 Changed 3 years ago by
Either is fine, I see use-cases for both. Maybe the changing option is more in line with the current model.
comment:10 Changed 3 years ago by
Cc: | asn added |
---|
comment:11 Changed 3 years ago by
I'm not gonna argue hard here if people think this is the way to go, but I feel like adding yet another torrc option for this sub-sub-sub-feature is a trap. The same sort of mind trap that has forced us into maintaining hundreds of torrc options in every release.
Personally, I feel like the documentation added by teor is a good step forward here (but maybe the man page is not the best place for it). Adding a file to the DataDirectory does not seem like that big of a deal, for that one time you want to switch your HS to RSOS (you shouldn't be doing this every day). Or am I being clueless here?
comment:12 Changed 3 years ago by
I'm on asn's side here as well. Documentation teor did is good imo.
comment:13 follow-up: 14 Changed 3 years ago by
Requiring users to manually mess in their data directory is not a sane interface.
comment:14 Changed 3 years ago by
Replying to weasel:
Requiring users to manually mess in their data directory is not a sane interface.
Well there is an argument here that we DO NOT want users to mess with single onion because it has security consequences if you do thus the "Ok, you want to do it, you'll have to poke the dragon" instead of giving a nice interface in the torrc that we know in the first place is not safe.
I personally don't want to provide options for users to "un-single onion" because it is very false that tor will go back in anonymity mode after that.
comment:15 follow-ups: 16 17 19 Changed 3 years ago by
This wasn't even about unsignling onions to begin with. I want to move *to* single onion things.
All this poisoning stuff just makes it a HUGE PITA. The poisoning code should just go away completely, then we wouldn't need more options too.
comment:16 Changed 3 years ago by
Replying to weasel:
This wasn't even about unsignling onions to begin with. I want to move *to* single onion things.
Woa my mistake... I should have read more carefully. Sorry.
comment:17 Changed 3 years ago by
Replying to weasel:
This wasn't even about unsignling onions to begin with. I want to move *to* single onion things.
Ok, so I think we can make a torrc option, or a script, or something, that takes an existing hidden service and turns it into a single onion service. Once. And then it's always a single onion service. (I can't see a use case for the single onion to double onion transition, the correct advice here is "create a new key, you burnt the old one".)
weasel, would you be happy with a once-off script?
Or does it need to be a torrc option?
All this poisoning stuff just makes it a HUGE PITA. The poisoning code should just go away completely, then we wouldn't need more options too.
That's the other alternative. Happy to do that too. But I think nickm wants to keep it for user safety.
comment:18 Changed 3 years ago by
No, a script would not meet my needs at all. I ship torrcs to a lot of machines. I don't want to have to keep logic on whether or not I also need to run scripts.
Also, I find this prescriptive behavior unbecoming for a piece of free software. I should be able to use Tor as I want. If I want to move from one means of offering my onion service to another, then Tor should not go out of its way to stop me from doing that. In either direction. I already have set HiddenServiceNonAnonymousMode *and* HiddenServiceSingleHopMode. I have read the caveats.
comment:19 Changed 3 years ago by
Replying to weasel:
This wasn't even about unsignling onions to begin with. I want to move *to* single onion things.
All this poisoning stuff just makes it a HUGE PITA. The poisoning code should just go away completely, then we wouldn't need more options too.
FWIW, I'm also amenable to removing the poisoning code. I find weasel's points reasonable and feel like this poisoning feature is buckling our users with too many seatbelts.
comment:20 Changed 3 years ago by
Parent ID: | #21049 |
---|
comment:21 follow-up: 22 Changed 3 years ago by
Keywords: | 029-backport 030-backport added |
---|---|
Owner: | set to teor |
Status: | needs_review → assigned |
We spoke with nickm earlier in the week, and decided to add another option. It will allow transitions in both directions, and set the poisoning state to match.
I will do the fix for legacy hidden services, and dgoulet will change the next-generation implementation to match.
Since 0.2.9 is a LTS release, I hope we can backport this fix there.
comment:22 follow-up: 23 Changed 3 years ago by
Replying to teor:
We spoke with nickm earlier in the week, and decided to add another option. It will allow transitions in both directions, and set the poisoning state to match.
I will do the fix for legacy hidden services, and dgoulet will change the next-generation implementation to match.
Since 0.2.9 is a LTS release, I hope we can backport this fix there.
We can't and shouldn't backport this. Adding a new torrc option to a stable version can't be backport, it's an ABI change basically. Actually, I do *not* recall us deciding to do this fix for legacy hidden service... ?
comment:23 Changed 3 years ago by
Keywords: | 029-backport 030-backport removed |
---|
Replying to dgoulet:
Replying to teor:
We spoke with nickm earlier in the week, and decided to add another option. It will allow transitions in both directions, and set the poisoning state to match.
I will do the fix for legacy hidden services, and dgoulet will change the next-generation implementation to match.
Since 0.2.9 is a LTS release, I hope we can backport this fix there.
We can't and shouldn't backport this. Adding a new torrc option to a stable version can't be backport, it's an ABI change basically.
Ok, fair enough.
Actually, I do *not* recall us deciding to do this fix for legacy hidden service... ?
I spoke to dgoulet and we both remembered that we wanted to fix this for legacy hidden services.
comment:24 Changed 3 years ago by
Milestone: | Tor: 0.2.9.x-final → Tor: 0.3.1.x-final |
---|---|
Owner: | teor deleted |
I would really like to fix this by the code freeze, but I just don't have the time with my other work.
Please reassign it to me if you defer it to 0.3.2.
comment:25 Changed 3 years ago by
Milestone: | Tor: 0.3.1.x-final → Tor: 0.3.2.x-final |
---|---|
Owner: | set to teor |
comment:26 Changed 3 years ago by
Owner: | changed from teor to dgoulet |
---|
dgoulet said he will do this, I might not get time in 0.3.2.
comment:27 Changed 2 years ago by
Milestone: | Tor: 0.3.2.x-final → Tor: 0.3.3.x-final |
---|
comment:28 Changed 23 months ago by
Milestone: | Tor: 0.3.3.x-final → Tor: 0.3.4.x-final |
---|
Move 033 ticket I own to 034
comment:29 Changed 21 months ago by
Keywords: | 034-triage-20180328 added |
---|
comment:30 Changed 21 months ago by
Keywords: | 034-removed-20180328 added |
---|
Per our triage process, these tickets are pending removal from 0.3.4.
comment:31 Changed 20 months ago by
Milestone: | Tor: 0.3.4.x-final → Tor: unspecified |
---|
These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.
Both transitions are disallowed by default, as a safety feature. There's an undocumented way to migrate. We should document it. The documentation should also make it really clear that this is often an extremely bad idea.