We Want You to Test Next-Gen Onion Services

by tommy | October 2, 2017

 

At DEF CON 25, Tor Co-Founder and President Roger Dingledine debuted next-generation onion services and detailed their security and usability improvements. At the time, we told you that the stable version is slated for December, and that we’d let you know if we wanted you to try them out.

That time has come! We’re looking for technical people to come help us test these new services. They’ve been fully merged into tor-0.3.2.1-alpha, and the latest version of Tor Browser supports them. We're still in the testing phase, though -- keep an eye on this blog for the official launch, probably some time in October during the Montreal meeting.

If you're technical, check out our wiki page on testing the new onion services and see how you can help out.

If you’re not technical, you can still use the new version of Tor Browser to check out some example onion services. There are always plenty of ways to get involved with Tor more generally, too. We’re always looking for dedicated volunteers who care about online privacy and internet freedom: here are some ways you can get involved and make the internet safer and more secure for everyone.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

October 02, 2017

Permalink

> We’re always looking for dedicated volunteers who care about online privacy and internet freedom
Are you talking about Tor or Tor Browser too?

Anonymous (not verified) said:

October 02, 2017

Permalink

Testing with Tails 3.2 with Tor Browser security slider on high (javascript disabled). Riseup requires javascript and I am redirected to non-javascript site. Could that become a security problem?

pastly (totall… (not verified) said:

October 02, 2017

Permalink

Latest ALPHA version of Tor Browser. Probably should specify that in the places you mention Tor Browser in this post.

@gk

Any chance for stable+alpha branch/channel? I want to test but if I switch to alpha I won't receive stable, right?

stable: S1->S2->...
alpha: S1.5->S2.5->...
tester(new): S1->S1.5->S2->S2.5->...

gk

gk said:

October 08, 2017

Permalink

Correct, you won't receive the stable in that case. What do you mean with a stable+alpha channel? How is that supposed to work if e.g. a new update is out there?

Anonymous (not verified) said:

October 09, 2017

Permalink

> What do you mean with a stable+alpha channel?
> How is that supposed to work if e.g. a new update is out there?

Let's call it "alwayslatest".
If the user set "alwayslatest" on apt update or Tor Browser channel, APT/TBB will download
latest file on either channel.

Currently, if I download alpha TBB, this browser will only download alpha(volatile) versions.
But if I download "alwayslatest" TBB, this browser will download alpha -> stable -> several week later -> alpha -> stable.

Here's some history:

Tor Browser 7.5a5 is released by boklm | September 28, 2017 **
Tor Browser 7.0.6 is released by boklm | September 28, 2017
Tor Browser 7.0.5 is released by gk | September 04, 2017
Tor Browser 7.5a4 is released by boklm | August 08, 2017 **
Tor Browser 7.0.4 is released by boklm | August 08, 2017

So,
7.0.4(Aug 08)
7.5a4(Aug 15) <--- push alpha to AL channel after {"1 week later of alpha release"}
7.0.5(Sep 04) <--- push {stable to AL immediately} because stable is better than alpha.
7.0.6(Sep 28)
7.5a5(Oct 2) <--- {"1 week later of alpha release"}

Anonymous (not verified) said:

October 03, 2017

Permalink

I'm already hosted oldonionsite.onion. If I add "HiddenServiceVersion 3", will I lose current domain? Or have multiple domain(old+v3)?

Also,
it is possible to host both(v2 v3) at the same torrc?
When will you update apt so I can update &try?

Hey there,

Yes it's totally possible to have both v2 and v3 with same torrc. Instead of adding `HiddenServiceVersion 3` on your current hidden service block, I suggest you make a second hidden service block with `HiddenServiceVersion 3` as shown in this example:

HiddenServiceDir /home/user/tmp/hsv2
HiddenServicePort 6667 127.0.0.1:6667

HiddenServiceDir /home/user/tmp/hsv3
HiddenServiceVersion 3
HiddenServicePort 6668 127.0.0.1:6667

I will also update the wiki page based on your feedback. Thanks!

Anonymous (not verified) said:

October 03, 2017

Permalink

> 4. Better onion address security against impersonation.

Can you clarify this line? I want to know why v3 is better than current onion.

Hello.

Nerdy answer: The problem with current (legacy) onions is that their onion address provides only 80-bits of security because the address is the 80-bit truncated hash of their identity key. This means that people can impersonate it (make a second identity key with the same onion address) if they spend enough computational power to cause a hash collision.

v3 onion addresses are 256-bits and are actual ed25519 public keys (not just a hash), which means that to impersonate them you would need to break the ed25519 signing algorithm.

Hope that makes sense. Please check the new guard spec (see wiki) for more details. Cheers! :)

Anonymous (not verified) said:

October 03, 2017

Permalink

I'm using HidServAuth stealth. Is v3 support this? If not, what is the alternative? (I just want to make sure only I can connect to it, so I am using it)

Hello,

unfortunately the client authorization feature is not available for v3 yet. It will most likely be part of the 0.3.3 release.

However, it's worth saying that v3 services are really hidden, in contrast to v2 services whose addresses can be discovered by malicious HSDirs. v3 service addresses stay really private to the network and can only be visited by people who know the onion address, no one else.

> v3 services are really hidden

That maybe so, but I need it to really hide it. For example, I use Tor networking to safely access to my camera from outside. Anyone who might know my onion never be able to reach my service without it.

When will be "0.3.3"? You might update a wiki to mention "HidServAuth NOT supported" because I know some people use that like me.

mosh (not verified) said:

October 04, 2017

Permalink

- will it happen suddenly and all the onion site will use the next-generation onion address ?
- why onion site are not all set in https ?
- captcha is back : am i more anonymous or less using it ?
- could you add a tbb cookie button off/on on the taskbar : it reloads & reloads when i validate a comment and stops without cookie (which is a tracker).
- is captcha a tracker _ leak issue?
- it sounds you work a lot about network & services so you can maybe answer at my last question : must i avoid http_onion_webmail using captcha ?

> - will it happen suddenly and all the onion site will use the next-generation onion address ?

No, we are imagining a gradual transition from v2 and v3. Currently the default version is v2. When we get more confidence we will switch the default version to v3. Then when v3 onions get widespread we will eventually phase out v2. But we are talking years in the future.

> - why onion site are not all set in https ?

onions have end-to-end security on their own so HTTPS is not strictly required for security. See https://blog.torproject.org/facebook-hidden-services-and-https-certs .

> - captcha is back : am i more anonymous or less using it ?
> - could you add a tbb cookie button off/on on the taskbar : it reloads & reloads when i validate a comment and stops without cookie (which is a tracker).
> - is captcha a tracker _ leak issue?
> - it sounds you work a lot about network & services so you can maybe answer at my last question : must i avoid http_onion_webmail using captcha ?

Hey I'm not sure which CAPTCHAs you are referring to. A CAPTCHA on its own should not be harmful to your anonymity, but I guess it depends on the situation and on the threat model. I wouldn't be so scared of CAPTCHAs in general, but they sure are annoying!

Anonymous (not verified) said:

October 07, 2017

Permalink

I really need HidServAuth because hiding .onion address is not enough.
With HidServAuth, attacker never reach my service without a key.

Please reconsider adding this feature before pushing V3 onion to the stable branch.

Also I'd like to see an improvement - 16bit key is surprisely weak. Attacker can bruteforce it.

New alternative method: string key(16/19) ---> ECC public key

HidServAuth xxxxxxxxxxxx.onion /tmp/ecc.mykey.onion.pem

Anonymous (not verified) said:

October 07, 2017

Permalink

In wiki's "Example prop224 services", I can see riseup's 2 onions.
However, I can't find any source for that. Even riseup.net website never mention about searx.

Can you add a source of these samples? This is a security problem.

The links on the wiki are being used to test the next generation onion service, and should only be used for testing, when the next generation onion service is officially released in December the officle links should go online. Check riseup when the next generation onion service is officially released, the official link should be online around that time.

Anonymous (not verified) said:

October 09, 2017

Permalink

Why is it _all_ V3 hidden services end with "d", as if "d.onion" would replace ".onion"? Is that intended behaviour?

Anonymous (not verified) said:

October 11, 2017

Permalink

/torspec.git/tree/rend-spec-v3.txt
1.2. In more detail: naming hidden services [NAMING]
A hidden service's name is its long term master identity key. This is
encoded as a hostname by encoding the entire key in Base 32, including a
version byte and a checksum

What "version byte"? The Tor version? Or the Protocol version? Computer version?
Does this include computer OS type? Because Tor version always include "Windows" or "Linux" string.

The Democratic… (not verified) said:

October 14, 2017

Permalink

Hello:
We need create some website to take against China government, but they have many human and host to Attack our website by CCdos on Tor

how to do with it?

all the money are come from people, dictatorship,tyranny,despotism,autocracy, I decide to subvert it, how can I create a website to prevent CCDOS?
next version can do it? thank everyone who work on it,

a Chinese little people.

why I can't send message?

======================
please look logs

Oct 13 17:16:41.000 [notice] Heartbeat: Tor's uptime is 17:59 hours, with 27 circuits open. I've sent 15.01 GB and received 12.36 GB.
Oct 13 17:16:41.000 [notice] Average packaged cell fullness: 79.088%. TLS write overhead: 3%
Oct 13 17:19:13.000 [warn] Failing because we have 4063 connections already. Please read doc/TUNING for guidance. [5027778 similar message(s) suppressed in last 21600 seconds]

Oct 13 14:53:15.000 [warn] Bug: /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fc566428b35] (on Tor 0.3.1.7 6babd3d9ba9318b3)
Oct 13 14:53:15.000 [warn] Bug: /usr/local/tor/bin/tor(+0x48a5b) [0x7fc567e30a5b] (on Tor 0.3.1.7 6babd3d9ba9318b3)
Oct 13 14:53:15.000 [warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:839 has n_chan==NULL. Dropping. (on Tor 0.3.1.7 6babd3d9ba9318b3)

indon (not verified) said:

October 15, 2017

Permalink

sorry for off-topic comment.

it seems that obfs4 proxy is blocked by indonesian telco operator telkomsel though fortunately tor and the site torproject.org are still not blocked - not yet? it's sad my country indonesia is slowly joining repressive countries like china and russia in censoring the internet.

giuseppetarall… (not verified) said:

October 16, 2017

Permalink

Buonasera,
continuo a non capire se Tor è un sito pericoloso oppure no. Mi dicono che è molto facile che vengano
scaricati sul pc virus o malware. Dove sta la verità? Grazie.
Saluti-

John (not verified) said:

October 29, 2017

Permalink

Why is the new tor address using Curve25519 instead of an already Post Quantum public key system like NTRU Prime ( https://ntruprime.cr.yp.to/software.html )?

The adoption is likely to take years, why not apply "NTRU Prime" now and have this scenario of quantum computers breaking all RSA/DSA/ECC public key systems already solved now.

Even the Chinese are using Post Quantum crypto for their satellite communications, and they aren't the only one's, in European Union they are using NTRU public/ private keys for many years now... and this "NTRU Prime" should be even better and shouldn't have the problems that the original NTRU has.

Lets not wast everyone's energy in something that may need to be switch again in 5/ 10 years.

I understand that in industry/ commerce they want people to buy new products, but in ONION network this is already to small, lets not keep dividing in more and more versions and make one to lest the next decades.

> Why is the new tor address using Curve25519 instead of an already Post Quantum public key system like NTRU Prime ( https://ntruprime.cr.yp.to/software.html )?

Ed25519 (EdDSA), not Curve25519 (ECDH). Closely related, but different.

Pedantry aside, there is a few reasons:
* There are no PQ algorithms that have public key sizes which are suitable to be used as addresses.
* NTRU at the time of the prop. 224 development work was patent encumbered, and none of the NTRU family algorithms have short enough public keys anyway.
* It's basically totally pointless to fret over onion addresses in a quantum setting, when all of the other cryptography is not Post Quantum.

Joao (not verified) said:

October 30, 2017

Permalink

- The patents seem a solved problem at least in onion network since they should be under the GPL.
- At least symmetric encryption is already available "NTRUEncrypt" under public domain.
- The forward secrecy also seems possible to solved (https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/883ec1c90bb60…)

- The size of the address, well no one can even memorized the current version, let alone the Ed25519 version... so in practice it will not matter, people won't remember it anyway... they will either add it to the bookmarks or copy them to some text file, or use some search engine, or some kind of index... so I don't get the issue from the practical point. Limitations on the browser? You are already changing it and adapting. Too long in the address? Just hidden it, and present only the page name. People want to see the page address? No problem: click the info and show it, and also allow the address to be compared or even copy. Or hide it and if the user wants to see he can click some place to expand and show the full address.
Any visual trust that the person is in the right place should be placed in a visual digital certificate anyway if trust is needed (and the address could be copy or compared to in the info). Digital certificates both from known trusted company's (in the internal list) and self-sign ones that the user obtains from other source and that he can verify their property's and compared with information available somewhere (paper for example).