[tor-dev] "old style" hidden services after Prop224

Ivan Markin twim at riseup.net
Tue Sep 13 21:13:00 UTC 2016

I agree with both s7r and Lunar here. Just want to add some bits:

> I disagree with your approach, for comparison's sake, let's say v2 is IPv4
> and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still
> is to this day, although IPv6 is arguably a much better solution in a lot
> of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a
> bit of a pipe dream.

The main goal of Tor Project is privacy and security _for everyone by
default_. If Tor is going to end up like PGP... it's a nightmare. ["Hey,
are you using new onion or old onion?", "Hm, I don't know. Maybe it's
better to go with normal Internet? At least it works.".]
If you don't care much about security/privacy/anonymity and look for a
"crypto-identified network" with NAT traversal - Tor is not _the_
network you're looking for. And yes, IPv4 is still around since it's
"just technology" and isn't tied to security. One can use outdated
technology (I do, a lot) but not use _outdated security_ ["outdated
security" hardly can be called security - a white horse is not a horse].
So ISPs can use IPv4 for any reason until the Sun become a supernova and
may not care about CGNAT and all this crazy stuff - it doesn't _threat_
anyone* except their budget.

> Tor hidden services are a bit "special" because it's hard to poll their
> owners on their intentions. Some hidden service operators have gone to
> great lengths to advertise their .onion URLs (v2-style), some have even
> generated vanity addresses (like Facebook). Forcing a switch to v3 at some
> point presents a very interesting opportunity for phishing because suddenly
> a service known and trusted at some address (as opaque as it is) would need
> to move to an even more opaque address, with no way to determine if the two
> are really related, run by the same operator, etc. If I were a LE agency, I
> would immediately grab v3 hidden services, proxy content to existing v2
> services and advertise my v3 URL everywhere, then happily monitor traffic.

It's not going to happen. You have v2 private key and your new v3
private key. Now you cross-certify them** and teach your users to use
new address.
If you've spent zillions of core-hours on generating a nice-looking
address on top of RSA1024 (can be factored now[1]) and truncated (!)
SHA-1 (someone probably can afford collisions now [2]) - congratulations.

> Attacks always get better; they never get worse.

Also, one shouldn't rely on secret keys as you've mentioned. It
shouldn't be an apocalypse if you lost/compromised your key.

> All I'm saying is don't remove the v2 services, even if you choose to no
> longer support them. Some operators (like my company) may choose to
> continue to patch the v2 areas if required and release the patches to the
> community at large. Forcing us out altogether would make us drop Tor and
> start using an alternative network or expending the additional effort to
> make our services network-agnostic (so no more good PR for Tor).

No problem, just run your personal Tor network in your corporate
environment - Tor is free software. It's not as hard as you may think.
And you're always welcome to contribute back. Also it's good since you
may find out some edge-cases or complicated bugs that could harm The Tor
Network at some point.
Just for the record, probably a good choice for your use case here is to
stick with cjdns [3]. It provides IPv6 "cryptoaddress" and mesh
networking and other cool stuff. You don't have to have authorities and
don't have to use OnionCat. It just works. But it's different from Tor
in many ways. The major difference - it's not anonymous.

* Yes, it does break end-to-end principle and makes the Internet less
fault-resistant etc, etc. Anyway, the Internet is already broken. Deal
with it.
** It definitely needs a proposal. :) Maybe I missed one? Something like

[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

[2] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
[3] https://github.com/cjdelisle/cjdns
Ivan Markin

More information about the tor-dev mailing list