Onion Service version 2 deprecation timeline

From today (July 2nd, 2020), the Internet has around 16 months to migrate from onion services v2 to v3 once and for all.
 
Nostalgia
 
More than 15 years ago, Onion Service (at the time named Hidden Service) saw the light of day. It was initially an experiment in order to learn more on what the Tor Network could offer. The protocol reached its version 2 soon after deployment.
 
Over the years, onion services evolved and version 2 developed into a strong stable product that has been used for over a decade now. During all those years, onion service adoption increased drastically. From the .onion tld being standarized by ICANN, to SSL certificates being issued to .onion addresses. Onion services these days support a whole ecosystem of client applications: from web browsing to file sharing and private messaging.
 
As humankind's understanding of math and cryptography evolved, the foundation of version 2 became fragile and at this point in time, unsafe. If you want to read more about the technical problems that version 2 faces, please read this post and don't hesitate to ask questions if any.
 
Which lead us to 2015: a large scale development effort spanning over 3 years resulted in version 3. On January 9th 2018, Tor version 0.3.2.9 was released which was the first tor supporting onion service version 3. And I bet you've encountered them, they have 56 characters and end in .onion ;).
 
Every single relay on the Tor Network now supports version 3. It is also today's default version when creating an onion service.
 
With onions v3 standing strong, we are at a good position to retire version 2: Version 2 has completed its course. Run its circle it has provided security and privacy to countless people around the world. But more importantly, it has created and propulsed a new era of private and secure communication.
 
Retirement
 
Here is our planned deprecation timeline:
 
1. September 15th, 2020
0.4.4.x: Tor will start warning onion service operators and clients that v2 is deprecated and will be obsolete in version 0.4.6.
 
2. July 15th, 2021
0.4.6.x: Tor will no longer support v2 and support will be removed from the code base.
 
3. October 15th, 2021
We will release new Tor client stable versions for all supported series that will disable v2.
 
This effectively means that from today (July 2nd, 2020), the Internet has around 16 months to migrate from v2 to v3 once and for all.
 
We'll probably run into some difficulties here; no matter how prepared we think we are, we find that there are always more surprises. Nonetheless, we'll do our best to fix problems as they come up, and try to make this process as smooth as possible. 
 
Transition from v2 to v3
 
This section details how to setup a v3 service from your existing v2 service. Unfortunately, there is no mechanism to cross-certify the two addresses.
 
In torrc, to create a version 3 address, you simply need to add these two lines. The default version is now set to 3 so you don't need to explicitly set it.
 
   HiddenServiceDir /full/path/to/your/hs/v3/directory/
   HiddenServicePort <virtual port> <target-address>:<target-port>
 
Finally, if you wish to keep running your version 2 service until it is deprecated to provide a transition path to your users, add this line to the configuration block of your version 2 service:
 
   HiddenServiceVersion 2
 
This will allow you to identify in your configuration file which one is which version.
 
Good Luck with the migration. Let us know if you have any problems in the comments below or post on the tor-talk mailing list.
k239

July 07, 2020

Permalink

Removing v2 will destroy lots of OnionLand applications and their userbases that are necessarily entirely dependant upon OnionCat.
Much P2P file/data sharing apps, all the OnionLand Bittorrent clouds, depends on v2 + OnionCat.
So do a variety of VoIP / streaming and non-onion-ifiable apps.
You cannot remove v2 until you provide OnionCat feature parity (UDP and IPv6 transport within OnionLand).

k239

July 07, 2020

Permalink

We need to use the OnionCat for UDP between onion-to-onion P2P Bittorrent clients protocols. We do NOT care about the crypto or discovery, it is strong enough for us. Do NOT remove v2 onion support. We serve fast between oppressive firewall regimes with the bittorrent and onioncat.

Why does Tor Project Inc think they can just dictate for everyone. Tor project was never like that till they ran people out.

v2's problems DO NOT affect us.
We spend money to serve data to oppressed regions over v2.

ATTN TOR PROJECT... make v2 a module and quit working on it if you want to chump out, but DO NOT remove v2 functionality.

Not everything can use v3. Tor project is LYING TO YOU when they claim v3 does everything v2 does, and that v2 is broke for everybody.

k239

July 07, 2020

Permalink

Unfortunately, there is no mechanism to cross-certify the two addresses.

  1. Couldn't the optional HTTP header, "Onion-Location", normally configured by webmasters on webservers on clearnet hostnames, be set up on onion v2 hostnames to redirect from v2 to its authentic v3 hostname?
  2. Couldn't such a system, if designed solely for onion v2, be built into the tor daemon's protocols to read a v3 name from a v2 torrc and tell client tor daemons to redirect to the v3?
  3. Couldn't Tor Browser be patched to display a full-tab warning if it doesn't redirect to a v3 after a chosen date when v2 is deprecated but not disabled, like Firefox's security warnings outlined by a yellow border?

Screenshots of Firefox's security warnings:
https://blog.mozilla.org/ux/2019/03/designing-better-security-warnings/
https://www.ghacks.net/2018/08/24/expect-an-increase-in-browser-privacy…

For reference to webmasters, other methods include:

  • Publishing a message on your encrypted (to mitigate MITM alteration) HTTPS or onion hostname announcing the transition and listing authentic alternate hostnames. A link to the message could be placed in the footer of every page. On hostnames that will expire soon such as onion v2, a link to the message could be placed in a header at the top of every page.
  • Publishing a PGP-signed message announcing the transition and listing authentic alternate hostnames. Sign the message by a key that your users trust, and publish the message anywhere on your sites and/or other sites. (A PGP-signed message maintains its authenticity anywhere.) Place a link on your site to the message.
  • Suggestions in We Support Tor in the paragraph, "Links to "Proof of (Onion / Relay / Policy)" statements..."
k239

July 07, 2020

Permalink

[Moderator: invaluable information about an onion previously publicized by an official post in this blog, so not grossly "off topic"]

Over the past year users including myself have complained that onion mirrors for the Debian software repository were becoming unusable, until finally the all important debian-security onion stopped responding. I recently discovered by accident that the sources.list given in the original post in this blog is no longer correct; apparently Debian updated the directory structure of debian-security but Tor users were not warned of this.

Further, I recently discovered by accident an obscure Tor Project page which appears to recommend that Debian users use a third onion, maintained by TP itself, to keep their Tor client on their Debian system up to date. (Or did I misread that page? It's confusing.)

On that basis, I believe that the current correct sources.list lines are these:

=================================

# onion mirror for Buster security patches
# deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security/ buster/updates non-free contrib main

# onion mirror for Buster release
deb tor+http://vwakviie2ienjx6t.onion/debian/ buster non-free contrib main

# onion mirror for Buster updates

# onion mirror for Buster backports
deb tor+http://vwakviie2ienjx6t.onion/debian/ buster-backports main contrib non-free

# onion mirror for Tor
deb tor+http://sdscoq7snqtznauu.onion/torproject.org/ buster main

==================================

(GNU purists can edit out the words "non-free" or "contrib" without harm.)

In my tests, the speed problems &c seem to have been corrected.

Can Tor Project confirm or correct?

Will TP arrange with Debian Project to announce here the new v3 addresses when they become known?

TIA

k239

July 07, 2020

Permalink

Install Tor and configure a v2 onion...
https://www.torproject.org/

Install OnionCat in IPv6 mode on your v2 onion...
https://www.onioncat.org/
ping fd87:d87e:eb43:
ping fd87:d87e:eb43:

Install an initial tracker within OnionLand, bind it to your v2 onion IPv6, it is used by torrent cloud until PEX/DEX/DHT/etc discovery protocols take over...
https://erdgeist.org/arts/software/opentracker/
https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_tracker_software

Install any IPv6 capable bittorrent client such as...
https://transmissionbt.com/
https://www.vuze.com/
https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clients

Download some torrent content, files, opensource ISOs, wiki, scihub, libgen, news media, youtube, data, leaks, etc from clearnet or wherever... or create your own content...

Add the tracker fd87:d87e:eb43::/48 IPv6 address to your torrents...
Now use torrent client to seed your torrents back out into the OnionCat IPv6 v2 OnionLand-only cloud...

Publish your torrent / infohash / magnet onto the OnionLand filesharing, news, websites, forums, and torrent indexes...
Publish the v2 onion IPv6 address of your tracker in the same places to help get large clouds of content and users started up in the sharing communities.
Start your own torrent sites in OnionLand...

Consider setup the firewall / VM since many bittorrent clients will phone home, adware, etc outside of the fd87:d87e:eb43::/48 which is private and dedicated to OnionLand.

Run a non-exit relay to support and donate back the bandwidth to tor network that your Bittorrent client is using. The ratio needed to support onion-to-onion P2P transfer clouds is about 7x what your client uses. Use bandwidth rate limits in firewall to do this.

The v2 onions services are crypto secure enough, and physical location hidden enough, for vanilla bittorrent users who are sharing typical torrent content, far more secure and hidden than clearnet. MAFIAA cannot takedown, and State Adversaries wont expose State Spy Secrets in court... OnionLand Bittorrent wins compared to clearnet.
Many groups have been using Bittorrent entirely within Tor OnionLand since 10 years now with zero safety or takedown problems ever reported on any forum.

Many big clearnet torrent websites / indexes / trackers / forums have onion addresses that are useful when torrenting the OnionLand.

And now you know how to do everything needed to Bittorrent entirely within OnionLand... no clearnet ever again :)

You can also use OnionCat for all IPv6 and UDP applications, it is black and nyan cat magic.

k239

July 07, 2020

Permalink

> More than 15 years ago, Onion Service (at the time named Hidden Service) saw the light of day.

Man, has it really been 15 years already? I remember it like it was yesterday...

k239

July 07, 2020

Permalink

You DO NOT have the right to arbitrarily decide whether or not users use v2, that is the USER's individual decisions to make.
Fork AWAY from Tor Project Incorporated.

k239

July 07, 2020

Permalink

I run relays. I vote to eliminate v2 and replace with v3. Do the cut over tomorrow if you can.

k239

July 08, 2020

Permalink

What about OnionCat?
We are using OnionCat every day to call people and distribute out files over p2p onion interfaces.