Opened 18 months ago

Last modified 2 months ago

#21117 assigned defect

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

Reported by: weasel Owned by: dgoulet
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 (31)

comment:1 Changed 18 months ago by 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.

comment:2 Changed 18 months ago by 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.

comment:3 Changed 17 months ago by weasel

Parent ID: #21049

comment:4 Changed 17 months ago by weasel

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

comment:5 in reply to:  2 Changed 17 months ago by 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?

comment:6 Changed 17 months ago by teor

Actual Points: 0.1
Keywords: tor-hs single-onion added
Points: 1
Status: newneeds_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 Changed 17 months ago by 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?)

comment:8 in reply to:  7 Changed 17 months ago by 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.

comment:9 Changed 17 months ago by weasel

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

comment:10 Changed 17 months ago by asn

Cc: asn added

comment:11 Changed 17 months ago by 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?

comment:12 Changed 17 months ago by dgoulet

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

comment:13 Changed 17 months ago by weasel

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

Last edited 17 months ago by weasel (previous) (diff)

comment:14 in reply to:  13 Changed 17 months ago by 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.

comment:15 Changed 17 months ago by 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.

comment:16 in reply to:  15 Changed 17 months ago by 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.

comment:17 in reply to:  15 Changed 17 months ago by 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.

comment:18 Changed 17 months ago by 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.

comment:19 in reply to:  15 Changed 17 months ago by 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.

comment:20 Changed 17 months ago by weasel

Parent ID: #21049

comment:21 Changed 15 months ago by teor

Keywords: 029-backport 030-backport added
Owner: set to teor
Status: needs_reviewassigned

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 in reply to:  21 ; Changed 15 months ago by 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... ?

comment:23 in reply to:  22 Changed 15 months ago by teor

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 14 months ago by teor

Milestone: Tor: 0.2.9.x-finalTor: 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 13 months ago by nickm

Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final
Owner: set to teor

comment:26 Changed 13 months ago by teor

Owner: changed from teor to dgoulet

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

comment:27 Changed 9 months ago by dgoulet

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

comment:28 Changed 5 months ago by dgoulet

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

Move 033 ticket I own to 034

comment:29 Changed 3 months ago by nickm

Keywords: 034-triage-20180328 added

comment:30 Changed 3 months ago by nickm

Keywords: 034-removed-20180328 added

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

comment:31 Changed 2 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: 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.

Note: See TracTickets for help on using tickets.