can't migrate onion services to single-hop onion services

[weasel]

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.

[nickm]

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.

[nickm]

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.

[weasel]

[best case scenario is the whole poisoning anti feature go away entirely]

[arma]

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?

[teor]

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.

[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?)

[teor]

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.

[weasel]

Either is fine, I see use-cases for both. Maybe the changing option is more in line with the current model.

[asn]

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?

[dgoulet]

I'm on asn's side here as well. Documentation teor did is good imo.

[weasel]

Requiring users to manually mess in their data directory is not a sane interface.

[dgoulet]

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.

[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.

[dgoulet]

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.

[teor]

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.

[weasel]

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.

[asn]

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.

[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.

[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. Actually, I do *not* recall us deciding to do this fix for legacy hidden service... ?

[teor]

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.

[teor]

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.

[teor]

dgoulet said he will do this, I might not get time in 0.3.2.

[dgoulet]

Move 033 ticket I own to 034

[nickm]

Per our triage process, these tickets are pending removal from 0.3.4.

[nickm]

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.