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

Tue Sep 13 19:45:11 UTC 2016

I fully agree with the security points, I was just arguing for keeping the
_option_ to list a v2 service for a longer time (possibly forever). Let's
not make assumptions for the service operators - ok, make them enable the
option explicitly, have them do it at compile time if you want to (like
Tor2Web) but don't remove it just because you think the alternative is
better. Some services (like mine) are not worthy targets for a LEA (unless
they're interested in hacking your fridge), Tor is interesting to us
because of its NAT traversal capabilities and cryptographic service
authentication.

Don't assume that all users have the same goals and they are all fighting
well funded or state-level attackers. Another option to be honest would be
for us to just fork Tor at the time v2 services are removed altogether and
spin a few directory authorities of our own and a few relays around the
world (we send very little traffic) and call it a day. Tor can continue
onwards with the v3-only services while our Tor fork would be happily using
v2, separate from the main network (and less subject to attacks from well
funded attackers and DDOS operators interested in revealing activists'
identities and not in finding out that you're out of cheese in your
fridge). I think there's potential in making a simpler, slightly less
secure version of Tor but with significantly improved user experience.

Oh, and no, I wasn't planning on having the Onion Balance and OnionCat devs
fix bugs for us :). I just didn't want to duplicate effort, so if they have
a plan to adapt their tools to v3, I'd rather wait for their solution than
do a half-baked one of our own.

Razvan

On Tue, Sep 13, 2016 at 10:31 PM, s7r <s7r at sky-ip.org> wrote:

>
> On 9/13/2016 6:13 PM, Razvan Dragomirescu wrote:
> > 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.
> >
>
> Your analogy with IPv4 and IPv6 is unacceptable. IPv6 exists not because
> IPv4 isn't secure, but because the address space got filled up (internet
> grew). Of course it has some improvements compared to IPv4 but we cannot
> say IPv4 has questionable security. I don't think we can speak about
> security in IP context anyway since there are other protocols where this
> happens (BGP,TCP etc.). And they do exist in parallel with perspective
> to migrate to IPv6 entirely in the future (obviously v2 and v3 hidden
> services will have a migration period also, just not so large because we
> aren't talking about the entire internet here).
>
> > 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.
> >
>
> I am not sure what you mean by grabbing v3 hidden services (generating
> random ed25519 keys?) and how exactly you are going to proxy anything to
> the v2 hidden service without access to v2's private key? But regardless
> of how you have in mind to do this, your points are wrong.
>
> Maintaining v2 services just because operators advertised the v2 onion
> url style is not an argument. RSA1024 will be easily factored in coming
> years. We have strong reasons to believe factoring RSA1024 at current
> moment is not impractical if the target is worth it enough. So, if we
> allow v2 services forever, we increase the chances for a LE to hijack v2
> hidden services by factoring their private keys - this risk is bigger
> than what you are describing. For the second part, there are plenty ways
> to prove a v2 hidden service is tied to a v3 one, given you control v2's
> private key. It provides exactly the same level of cryptographic
> certification.
>
> > 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).
> >
>
> This doesn't sound good. Would your company ship to its users code that
> you do not support yourself, but relying on third parties to do so?
> Relying on a third party company for patches doesn't sound comfortable
> to me (with all due respect, I am sure your company is able to do it
> without problems, I just don't think it's professional this way). Rather
> than trying to spend time to code patches for the old v2 code why not
> spend that time and make your services compatible with v3 hidden
> services? OnionBalance and OnionCat will find ways to work with v3
> hidden services.
>
> > Ivan was right, moving to v3 would be, at least for my project,
> > extremely complex and unwieldy. Ed25519 is not supported by any
> > smartcards I know (but can be "hacked" by manually defining Curve25519
> > params and converting back and forth). But then we'd have to modify the
> > service re-registration (or wait for OnionBalance to do it), then add
> > another layer for OnionCat-like lookups, etc. It would be far easier to
> > just drop the Tor dependency at that point or centralize it a bit more.
> >
> > Just my 2 cents, if any hidden service operators wish to chime in, feel
> > free to do so. After all, it's us (them? :) ) that will have to make the
> > changes to their services.
> >
>
> Not only clients. Also, the relays -- hidden service directories -- for
> example I don't want to host v2 descriptors on my relays after prop 224
> is implemented.
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160913/e04169b1/attachment-0001.html>