|
|
== v2->v3 onions
|
|
|
|
|
|
Facilitator(s): Will, Jen
|
|
|
|
|
|
Duration: 1h
|
|
|
|
|
|
Audience: Anyone interested in migrating user traffic from v2 to v3 onions
|
|
|
|
|
|
This session is about moving from v2 to v3 onions primarily from the perspective of site operators (e.g. Facebook, SecureDrop). Note that this discussion was primarily focused on the transitioning of web traffic.
|
|
|
|
|
|
=== Motivations
|
|
|
|
|
|
==== Targeted/active attacks
|
|
|
|
|
|
The idea here is a killswitch to render your v2 onion address unusable. The concern prompting this is that as v2 ages, attackers may try to generate a [16 character].onion collision. This is especially a concern for high profile sites. If this occurs, there will be a fight for control as the attacker and the legitimate site owner republish descriptors. Options for implementing the functionality for site owners to permanently disable v2:
|
|
|
|
|
|
1. Blacklist on the HSDir layer so site operators can permanently disable their v2 onions.
|
|
|
2. HTTPS Everywhere ruleset that redirects disabled v2 onions (v2 operators would need to sign a challenge to assert they control the v2 onion) to a null address such that site owners can disable their v2 onions once all user traffic has been migrated to the v3 onion - before this attack occurs.
|
|
|
|
|
|
If this were implemented, one of the ideas that was discussed is that the browser should ideally display something like “This onion service has been removed”.
|
|
|
|
|
|
==== Get rid of tech debt of v2 code
|
|
|
|
|
|
Consider some method to make v2 work using v3 infrastructure. For a while allow v2 addresses to be made using v3 (making a v2 address generate a v3 under the hood). Engineering effort likely prohibitive. Another suggestion that was discussed in order to transition v2 services (such that they can be deprecated by Tor more rapidly) would be when you add a descriptor for a v2 onion, you get a message in the Tor logs warning you that v2 will be deprecated.
|
|
|
|
|
|
==== Site operators transition traffic from v2 -> v3 using Alt-Srv header or HTTP 301 redirect
|
|
|
|
|
|
Alt-Srv effectively transparent to the user, so user messaging would need to be in each site's UI to indicate that users should in the future use the v3 (and to update their bookmarks).
|
|
|
|
|
|
Without additional messaging, HTTP redirect may appear very confusing to the user as they are redirected from [16 character].onion to [56 character].onion.
|
|
|
|
|
|
Site operators need to run both v2 and v3 onion addresses for some time. Currently it’s basically up to site operators to message via their website that v2 is going away, when the v2 onion will no longer work, and that they should use the v3 onion address.
|
|
|
|
|
|
Some possible ideas on the Tor Browser side to help with this migration are to include some messaging in the browser itself:
|
|
|
* e.g. after some date, v2 onions trigger a notice in Tor Browser “v2 onions are going away, please use the new onion address or let the site operator know that they need to upgrade”. Since many site operators are also consumers of their own services, this might be pretty effective.
|
|
|
* v2 -> v3 redirects includes some message explaining what has happened.
|
|
|
|
|
|
==== “Seed” v2 -> v3 redirect.
|
|
|
|
|
|
There could be some automated service for demonstrating ownership of the v2 and v3 onion keys (e.g. you need to sign a challenge) and you get added into an HTTPS Everywhere ruleset rewrite list distributed by Tor.
|
|
|
|