Onion Service v2 Deprecation Timeline
Greetings everyone! I will try to make this quick. Deprecation of v2 has already been discussed on this list [0] and so this is not about re-creating this discussion but rather giving you the Tor Project timeline for v2 deprecation. To very quickly summarize why we are deprecating, in one word: Safety. Onion service v2 uses RSA1024 and 80 bit SHA1 (truncated) addresses [1]. It also still uses the TAP [2] handshake which has been entirely removed from Tor for many years now _except_ v2 services. Its simplistic directory system exposes it to a variety of enumeration and location-prediction attacks that give HSDir relays too much power to enumerate or even block v2 services. Finally, v2 services are not being developed nor maintained anymore. Only the most severe security issues are being addressed. That being said, the deprecation timeline is now quite simple because v3 has reached a good maturity level: * v3 has been the default since Tor 0.3.5.1-alpha. * v3 is feature parity with v2. * v3 now has Onion Balance support [3] * Entire network supports v3 since the End-of-Life of 0.2.9.x series earlier this year. The deprecation to obsolescence 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 will be removed from the code base. 3) October 15th, 2021 We will release new stable versions for all supported series that will disable v2. This effectively means that from _today_ (June 11th 2020), the Internet has around 15 months to migrate from v2 to v3 once and for all. We plan to publish a blog post in the coming days/weeks about this deprecation, in order to inform as many users as possible. It will include the reasons why, how to migrate and the timeline. 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. Good Luck! The tor maintainers. [0] https://lists.torproject.org/pipermail/tor-dev/2018-April/013097.html [1] https://shattered.io/ [2] https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1084 [3] https://blog.torproject.org/cooking-onions-reclaiming-onionbalance -- 262Gy/4o+HGG/7ELoDp1drRojN33l7AZaBoRHN6mjXY=
On 15 Jun (12:34:17), David Goulet wrote:
This effectively means that from _today_ (June 11th 2020), the Internet has around 15 months to migrate from v2 to v3 once and for all.
Typo: June 11th 2020 --> June 15th 2020 :) David -- 262Gy/4o+HGG/7ELoDp1drRojN33l7AZaBoRHN6mjXY=
On Mon, Jun 15, 2020 at 12:34:17PM -0400, David Goulet wrote:
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
Thanks David. "Late 2020" is also a good timeframe for Tor Browser to learn how to warn users when they visit a v2 onion service. That is, we can't just change the underlying Tor proxy program to write warnings in a log file. We need to improve the user flow for popular Tor-using apps, starting with Tor Browser and maybe continuing to other common Tor-using apps we appreciate such as Brave. I recognize that the Tor Browser dev team has their hands full with keeping up with Mozilla's changes while trying to improve things for mobile while having not enough funded developers for those tasks. All the more reason to highlight this need early, and to do as much of the supporting design/planning/strategy work as we can in other teams like the UX team. --Roger
Roger Dingledine:
On Mon, Jun 15, 2020 at 12:34:17PM -0400, David Goulet wrote:
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
Thanks David. "Late 2020" is also a good timeframe for Tor Browser to learn how to warn users when they visit a v2 onion service.
That is, we can't just change the underlying Tor proxy program to write warnings in a log file. We need to improve the user flow for popular Tor-using apps, starting with Tor Browser and maybe continuing to other common Tor-using apps we appreciate such as Brave.
I recognize that the Tor Browser dev team has their hands full with keeping up with Mozilla's changes while trying to improve things for mobile while having not enough funded developers for those tasks. All the more reason to highlight this need early, and to do as much of the supporting design/planning/strategy work as we can in other teams like the UX team.
I just Created https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40001 (via email, yes, you don't need to click around anymore in a GUI to do this kind of thing ;)). Georg
Quoting Georg Koppen (2020-06-16 11:15:46)
Roger Dingledine:
On Mon, Jun 15, 2020 at 12:34:17PM -0400, David Goulet wrote:
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
Thanks David. "Late 2020" is also a good timeframe for Tor Browser to learn how to warn users when they visit a v2 onion service.
That is, we can't just change the underlying Tor proxy program to write warnings in a log file. We need to improve the user flow for popular Tor-using apps, starting with Tor Browser and maybe continuing to other common Tor-using apps we appreciate such as Brave.
I recognize that the Tor Browser dev team has their hands full with keeping up with Mozilla's changes while trying to improve things for mobile while having not enough funded developers for those tasks. All the more reason to highlight this need early, and to do as much of the supporting design/planning/strategy work as we can in other teams like the UX team.
I just Created
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40001
(via email, yes, you don't need to click around anymore in a GUI to do this kind of thing ;)).
I'm wondering if it will make sense to use Onion-Location in V2 onion services to advertise the V3 onion. So existing known V2 services can use it to upgrade their users to V3. AFAIK right now tor-browser ignores the Onion-Location header if is already coming from an onion service. Will it make sense to stop ignoring it at least for V2 onion services? -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.
On Tue, 16 Jun 2020 at 12:15, meskio <meskio@sindominio.net> wrote:
I'm wondering if it will make sense to use Onion-Location in V2 onion services to advertise the V3 onion. So existing known V2 services can use it to upgrade their users to V3.
AFAIK right now tor-browser ignores the Onion-Location header if is already coming from an onion service. Will it make sense to stop ignoring it at least for V2 onion services?
Or the site could just issue a Location header and/or explicit redirect to the v3 service? After all, if the v2 site is compromised to the point where that's a problem, then there are larger issues / "game over", etc. -a -- http://dropsafe.crypticide.com/aboutalecm
Quoting Alec Muffett (2020-06-16 14:10:24)
On Tue, 16 Jun 2020 at 12:15, meskio <[1]meskio@sindominio.net> wrote:
I'm wondering if it will make sense to use Onion-Location in V2 onion services to advertise the V3 onion. So existing known V2 services can use it to upgrade their users to V3.
AFAIK right now tor-browser ignores the Onion-Location header if is already coming from an onion service. Will it make sense to stop ignoring it at least for V2 onion services?
Or the site could just issue a Location header and/or explicit redirect to the v3 service? After all, if the v2 site is compromised to the point where that's a problem, then there are larger issues / "game over", etc.
True, I agree I don't see much value added to do the Onion-Location instead of just doing a redirect. I guess this is a better way of upgrading users. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.
participants (5)
-
Alec Muffett -
David Goulet -
Georg Koppen -
meskio -
Roger Dingledine