Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tor's Fall Harvest: The Next Generation of Onion Services

blog.torproject.org

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#71

Post by asn_tor »

jstanley wrote: post #62

> And finally from the casuals user's PoV, the only thing that changes is that new onions are bigger, tastier and they now look like this: 7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion. For more information on the nitty-gritty details, please check out our technical specification. It's a shame they don't have a description for technical users. I'm more interested than "bigger, tastier, and looks like…

Hey there,

Tor developer here. You are right there is no middle ground there.

I'm kind of on the run right now, so I can't write a big explanation here. However check this section of the proposal that presents some high-level improvements: https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3....

peace

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#72

Post by dublinben »

jstanley wrote: post #62

> And finally from the casuals user's PoV, the only thing that changes is that new onions are bigger, tastier and they now look like this: 7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion. For more information on the nitty-gritty details, please check out our technical specification. It's a shame they don't have a description for technical users. I'm more interested than "bigger, tastier, and looks like…

TL;DR of that change is that they've moved from a truncated SHA1 hash to SHA3/ed25519/curve25519. For more detail, here's their own summary from the technical specification:

   Here is a list of improvements of this proposal over the legacy hidden services:

   a) Better crypto (replaced SHA1/DH/RSA1024 with SHA3/ed25519/curve25519)
   b) Improved directory protocol leaking less to directory servers.
   c) Improved directory protocol with smaller surface for targeted attacks.
   d) Better onion address security against impersonation.
   e) More extensible introduction/rendezvous protocol.
   f) Offline keys for onion services
   g) Advanced client authorization

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#74

Post by asn_tor »

zaroth wrote: post #36

Here's a question I have on this -- I've been eagerly awaiting the new functionality to have onion addresses where using them doesn't reveal their existence. So the address itself becomes a form of shared key. But this opens another possibility of one-time addresses, and address scalability. My question is, does network cost increase with number of addresses? If peers on the network are using one-time addresses to fo…

Each onion service does increase network load but not anything super intense.

The use case you suggested should be possible. Also check out ricochet which works with legacy onions for chat.

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#75

Post by asn_tor »

MBCook wrote: post #14

Does it fix the LONG standing issue that Dr. Krawetz keeps discussing on his blog that makes it trivial to DOS an onion site? Description in the section about ‘Eddie’. https://www.hackerfactor.com/blog/index.php?/archives/762-At...

No the new design does nothing against such DoS attacks. Please see tor tickets #16052 and #16059 for some plausible ways forward. We would need more help from the community to design and develop solutions to handle the DoS threat.

I've tried to communicate with the hackerfactor person about this and figure out ways forward, but I received unproductive responses which did not make me want to proceed in discussion.

We need the community to help us understand how they best want to manage the DoS risks and build sustainable proposals to fight them.

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#76

Post by asn_tor »

nikcub wrote: post #48
pault wrote: post #28

The issue I've always had with onion addresses is that you can't remember them, which means you need to keep a list of bookmarks saved locally somewhere, which–if you're using tor to avoid prosecution–is pretty incriminating. What's the solution?

There is a pluggable name resolution proposal: https://gitweb.torproject.org/torspec.git/tree/proposals/279... You'd be able to run namecoin and other systems edit: to add, I haven't yet completely bought into the new onion services. I like a lot of the security improvements, but it is really going to depend on how name resolution works and how authenticating endpoints will work for users. Running a pluggable name re…

Yes indeed the naming issue is important and needs to be addressed. We are currently pretty busy with stuff so we haven't even started implementing the aforementioned proposal (or considered whether it's a good idea).

BTW check out this link for some survey results that point out that onion length might not matter so much since the legacy onions were already unrememberable: https://lists.torproject.org/pipermail/tor-dev/2017-Septembe...

Cheers and thanks for keeping the discussion fruitful :)

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#77

Post by tgragnato »

nikcub wrote: post #54

If you are looking for a practical use of hidden services: we use them as ingress for Docker and K8 management. You start a container that runs just tor with a config and can read the routing endpoints from your config, or link to localhost:2375 HiddenServicePort : You setup HiddenServiceAuthorizeClient with stealth auth type and a list of authorized clients. You can lock your firewall rules down as the hidden servic…

Apparently you need to stick to the second version of hidden services if you want to use stealth authentication.

Just tried to upgrade and got this `[warn] Hidden service option HiddenServiceAuthorizeClient is incompatible with version 3 of service in `.

Does anyone know if there is any plan to support stealth authentication? It's a pretty usefull feature.

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#78

Post by pault »

Ajedi32 wrote: post #45
wybiral wrote: post #33

Earlier quoted context omitted.

But now you have to trust that community directory not to give you the wrong onions...

Unless the bookmark entries in your directory are encrypted with a passphrase only you know. So... it sounds like what you're looking for is a password manager.

Doesn't protect from rubber hose side channel attacks.

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#79

Post by devrandomguy »

amelius wrote: post #57
amingilani wrote: post #38

I used to use Tor to bypass censorship on pr0n in my country and ended up trying to run a hidden service for fun. My biggest peeve with was the domain name. I mean, sure I understand why it isn't human readable but then there are so many ways to counter that. We've got the blockchain and we have the IPFS way to handle these things too. I'm hoping at some point blockchain DNS systems are adopted by mainstream (or nich…

How fast/convenient is Tor for downloading large files, like video (e.g. via Bittorrent)? PS: It seems that Bittorrent over Tor is a bad idea, [1]. [1] https://blog.torproject.org/bittorrent-over-tor-isnt-good-id...

In Qatar, which has a national firewall, I was able to use Tor to browse torrent sites, and then use a regular bittorrent client to fetch the contents of the magnet links (encrypted connections only). That worked great for the few years that I was there. The Qatari internet was a fair bit faster than what I am used to from Canada, about 30 - 50 MB/s at max torrent.

Re: Tor's Fall Harvest: The Next Generation of Onion Services

#80

Post by Ajedi32 »

pault wrote: post #78
Ajedi32 wrote: post #45

Earlier quoted context omitted.

Unless the bookmark entries in your directory are encrypted with a passphrase only you know. So... it sounds like what you're looking for is a password manager.

Doesn't protect from rubber hose side channel attacks.

Yeah, ideally you'd want plausible deniability.

In theory, you could achieve this by only storing the password DB in a cloud service you access through the Tor browser, but then you run into two other problems. First, how do you remember the address of the service you're using to store your password DB? If you store that address on your device, you've lost your plausible deniability. I guess you'd have to use a well-known clearnet site you access through Tor (Dropbox, Google Drive, etc).

That leaves another problem though. If you have a password manager installed on your PC, that implies the existence of a password database, which might also cause you to lose your plausible deniability.

Maybe if there was a profiles/password manager feature built into the Tor browser that lets you decrypt and load a profile from a service provider, then destroys all local evidence of that profile when you close the browser? Seems like a feature that could be useful in all browsers actually. A cross-browser password manager and bookmarks sync feature? That'd be really convenient.

Post reply on HN