Opened 8 weeks ago

Closed 6 weeks ago

Last modified 10 days ago

#27215 closed enhancement (implemented)

hs: Change default HiddenServiceVersion to 3

Reported by: dgoulet Owned by:
Priority: Medium Milestone: Tor: 0.3.5.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, 035-roadmap-proposed
Cc: dmr Actual Points:
Parent ID: Points:
Reviewer: teor Sponsor:

Description

The next tor release (0.3.5) is an LTS, it would mean that keeping v2 the default version forces us to support it until 2020 (minimum).

Hidden service version 3 have been merged back in 0.3.2 and have been extensively tested. Bugs remains but we are confident they can be addressed in 0.3.5 and aren't blockers to the mass adoption of v3.

By making version 3 the default version for new services, we can start working on deprecating version 2 in future tor releases.

Still, for a while, v2 will work on the network so this is *not* about removing v2 entirely but simply switching new default services to v3. An operator will still be able to specify HiddenServiceVersion 2 explicitly if they do really want a v2.

NOTE: There is a tricky issue with this. We'll have to make tor "guess" the right version when loading the configuration. Right now, we _explicitly_ ask the operator to provide HiddenServiceVersion 3 else we consider it a v2.

Considering that, we can't ask all operators to add HiddenServiceVersion 2 to their torrc so we need to make tor smart so it can learn the right version if not given.

Child Tickets

Change History (14)

comment:1 Changed 8 weeks ago by dgoulet

Keywords: 035-roadmap-proposed added; 035-proposed removed

comment:2 Changed 8 weeks ago by teor

Here's one way to make Tor smart:

  • if the HiddenServiceDirectory has an existing v2 key, use v2 for that service
  • if the HiddenServiceDirectory has an existing v3 key, use v3 for that service
  • otherwise, use HiddenServiceVersion for new services

If we apply the first found version to all other services, there are a lot of edge cases.

comment:3 in reply to:  2 Changed 8 weeks ago by dgoulet

Replying to teor:

Here's one way to make Tor smart:

  • if the HiddenServiceDirectory has an existing v2 key, use v2 for that service
  • if the HiddenServiceDirectory has an existing v3 key, use v3 for that service
  • otherwise, use HiddenServiceVersion for new services

If we apply the first found version to all other services, there are a lot of edge cases.

That is the good approach. Heads up, we'll have to add some logic/code to try to load the key when configuring the service so we can figure out the version.

Currently, loading keys happen _after_ configuration because it is the "validation" step and then loading/creating the keys is a second step which makes it from staging to production.

comment:4 Changed 8 weeks ago by dgoulet

Status: newneeds_review

Branch: ticket27215_035_01
PR: https://github.com/torproject/tor/pull/288

comment:5 Changed 8 weeks ago by dmr

Cc: dmr added

comment:6 Changed 7 weeks ago by dgoulet

Reviewer: teor

comment:7 Changed 7 weeks ago by teor

Status: needs_reviewneeds_revision

Thanks, I reviewed on the pull request.

Let's try to avoid fatal asserts. And fix a typo.

Do we need unit tests for the new functions?

comment:8 Changed 7 weeks ago by dgoulet

Status: needs_revisionneeds_review

I've pushed a fixup and reply to one of your comment.

comment:9 Changed 7 weeks ago by teor

Status: needs_reviewmerge_ready

Thanks for the typo fix and the explanation. I'm happy with the branch now.
(And I'm happy that we're one step closer to migrating to v3.)

comment:10 Changed 7 weeks ago by nickm

needs a changes file.

comment:11 in reply to:  10 Changed 7 weeks ago by dgoulet

Replying to nickm:

needs a changes file.

Done in fixup commit 4e2dcda092.

comment:12 Changed 7 weeks ago by nickm

merged!

comment:13 Changed 6 weeks ago by nickm

Resolution: implemented
Status: merge_readyclosed

hm, looks like I forgot to close this when I merged it.

comment:14 Changed 10 days ago by teor

This ticket broke chutney's single-onion-ipv6-md network, which is part of make test-network-all. See #27965.

Note: See TracTickets for help on using tickets.