[tor-talk] Tor official list of new .onion addresses?

[i***@cock.li]

Can the Tor Project publish the list? Some sites have published lists of
new .onion addresses, for example:
http://onionsnjajzkhm5g.onion/onions.php?cat=20&pg=1&lang=en
http://zlal32teyptf4tvi.onion/
http://56wr4dvq3abd2ivkf5z36nortvu7dgona55zqsihfaqo2aeg5er4moid.onion/

There may be no reason that the Tor project does it, but can the Tor
project not do it? :)

The Tor Metrics has published the number of unique .onion addresses for
version 2 onion services in the network per day already.
https://metrics.torproject.org/hidserv-dir-onions-seen.html

And if I act a relay, can I discover the number of unique .onion
addresses and new .onion addresses? If yes, is it good/bad to publish
lists of new .onion addresses?
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.o

[Nathaniel Suchy]

Consider the consequences of publishing the actual addresses. The number of
addresses is fine but the actual addresses should stay private for privacy
and security reasons.

I’m aware there are crawers looking for new services to show however if the
address is kept private only rouge HSDIRs are an issue and we can always
generate new addresses and delete the old keys.

I am running some Onion Services for SSH (clearnet disabled, you’ll need to
be physically present if Tor has an issue!) and while I require SSH Keys
it’d open a huge attack surface I’m trying to avoid. It’s basicaly an
attempt at security by really advanced obscurity.

Cordially,
Nathaniel Suchy

On Mon, Dec 3, 2018 at 9:53 AM <***@cock.li> wrote:

> Can the Tor Project publish the list? Some sites have published lists of
> new .onion addresses, for example:
> http://onionsnjajzkhm5g.onion/onions.php?cat=20&pg=1&lang=en
> http://zlal32teyptf4tvi.onion/
> http://56wr4dvq3abd2ivkf5z36nortvu7dgona55zqsihfaqo2aeg5er4moid.onion/
>
> There may be no reason that the Tor project does it, but can the Tor
> project not do it? :)
>
> The Tor Metrics has published the number of unique .onion addresses for
> version 2 onion services in the network per day already.
> https://metrics.torproject.org/hidserv-dir-onions-seen.html
>
> And if I act a relay, can I discover the number of unique .onion
> addresses and new .onion addresses? If yes, is it good/bad to publish
> lists of new .onion addresses?
> --
> tor-talk mailing list - tor-***@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/t

[s7r]

Hello,

Nathaniel Suchy wrote:
> Consider the consequences of publishing the actual addresses. The number of
> addresses is fine but the actual addresses should stay private for privacy
> and security reasons.
>
> I’m aware there are crawers looking for new services to show however if the
> address is kept private only rouge HSDIRs are an issue and we can always
> generate new addresses and delete the old keys.
>
> I am running some Onion Services for SSH (clearnet disabled, you’ll need to
> be physically present if Tor has an issue!) and while I require SSH Keys
> it’d open a huge attack surface I’m trying to avoid. It’s basicaly an
> attempt at security by really advanced obscurity.
>

Relying on the fact that nobody can ever learn the onion addresses you
have is a terrible security policy. This can be never guaranteed, as
relays are public and anyone can run one, thus become hidden service
directory as soon it meets the necessary flags.

You should be prepared and assume the onion address is known, thus
defend with ssh keys instead of weak passwords, possibly even change the
default port (this does not add security but bypasses some automated
brute force tools, it's no help for targeted manual attack so don't rely
either).

There are other techniques lower at little-t-tor protocol level that
suite your concerns, like HiddenServiceAuthorizeClient - you should
better look into those if you are concerned about someone trying to
connect to your onion address. These are neat for some services that
need privacy and need to not advertise to the unauthorized access users
that they are online up and running or only allow limited access to some
users that provide additional credentials or auth material other than
just knowing the onion address.

Onion addresses have the purpose to conceal the physical (IP) location
of the service, but the addresses themselves have to be prepared to be
known to the world, for a strong security policy. Tor documentation
clearly states this.

If you open ssh on an onion address and you allow root login with
password "1234" IT IS NOT Tor's FAULT YOU WERE PWNED. It is just a
terrible security policy. Do not do this.

*Hope for the best, prepare for the worst!*

[Mirimir]

On 12/03/2018 02:35 PM, s7r wrote:

<SNIP>

> There are other techniques lower at little-t-tor protocol level that
> suite your concerns, like HiddenServiceAuthorizeClient - you should
> better look into those if you are concerned about someone trying to
> connect to your onion address.

<SNIP>

I use that, sometimes. But how secure is it?
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://li

[Nathaniel Suchy]

I'm interested in information on the security benefits and risks that this functionality offers as well might be helpful in blocking of some unsolicited traffic if someone finds a way to publish a list of every onion address :|

Cordially,
Nathaniel Suchy



Dec 3, 2018, 8:42 PM by ***@riseup.net:

> On 12/03/2018 02:35 PM, s7r wrote:
>
> <SNIP>
>
>> There are other techniques lower at little-t-tor protocol level that
>> suite your concerns, like HiddenServiceAuthorizeClient - you should
>> better look into those if you are concerned about someone trying to
>> connect to your onion address.
>>
>
> <SNIP>
>
> I use that, sometimes. But how secure is it?
> --
> tor-talk mailing list - > tor-***@lists.torproject.org <mailto:tor-***@lists.torproject.org>
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>
>

--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/c

[Nathaniel Suchy]

This post might be inappropriate. Click to display it.

[Mirimir]

On 12/03/2018 10:42 PM, Nathaniel Suchy wrote:

<SNIP>

> You mentioned "HiddenServiceAuthorizeClient", a feature I did not know about. I'm going to figure out if this is possible to implement on the SSH System as that would solve some concerns about a leaked onion address. Could you elaborate a bit more on this functionality?

<SNIP>

I've just used basic authentication.

In the .onion server torrc:

$ sudo nano /etc/tor/torrc
...
HiddenServiceDir /var/lib/tor/foo
HiddenServiceAuthorizeClient basic [16-chracter-string]
HiddenServicePort 22 127.0.0.1:22
...

$ sudo cat /var/lib/tor/foo/hostname
[v2-hostname].onion [22-character-string] # client: [16-chracter-string]

The client ID must be 16 alphanumeric characters. Then you use the 22
character string in the client torrc.

In the client:

$ sudo nano /etc/tor/torrc
...
HidServAuth [v2-hostname].onion [22-character-string]
...
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi

[Aaron Johnson]

If you want to keep your onion address hidden, you should run a v3 onion service. An improvement of v3 over v2 is that Hidden Service Directories can no longer identify the onion address of the onion-service descriptors they store. As a result, there is no point in any Tor protocol at which a v3 onion address is leaked to any relay. As long as you keep the address to yourself, noone will be able to find it. For more information about v3 onion services, see <https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames <https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames>>.

Aaron

> On Dec 3, 2018, at 10:28 PM, Mirimir <***@riseup.net> wrote:
>
> On 12/03/2018 10:42 PM, Nathaniel Suchy wrote:
>
> <SNIP>
>
>> You mentioned "HiddenServiceAuthorizeClient", a feature I did not know about. I'm going to figure out if this is possible to implement on the SSH System as that would solve some concerns about a leaked onion address. Could you elaborate a bit more on this functionality?
>
> <SNIP>
>
> I've just used basic authentication.
>
> In the .onion server torrc:
>
> $ sudo nano /etc/tor/torrc
> ...
> HiddenServiceDir /var/lib/tor/foo
> HiddenServiceAuthorizeClient basic [16-chracter-string]
> HiddenServicePort 22 127.0.0.1:22
> ...
>
> $ sudo cat /var/lib/tor/foo/hostname
> [v2-hostname].onion [22-character-string] # client: [16-chracter-string]
>
> The client ID must be 16 alphanumeric characters. Then you use the 22
> character string in the client torrc.
>
> In the client:
>
> $ sudo nano /etc/tor/torrc
> ...
> HidServAuth [v2-hostname].onion [22-character-string]
> ...
> --
> tor-talk mailing list - tor-***@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>

--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproje

[Mirimir]

On 12/04/2018 08:41 AM, Aaron Johnson wrote:
> If you want to keep your onion address hidden, you should run a v3 onion service. An improvement of v3 over v2 is that Hidden Service Directories can no longer identify the onion address of the onion-service descriptors they store. As a result, there is no point in any Tor protocol at which a v3 onion address is leaked to any relay. As long as you keep the address to yourself, noone will be able to find it. For more information about v3 onion services, see <https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames <https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames>>.
>
> Aaron

That is very cool. But the problem for me is that v3 breaks OnionCat.
There was that sweet matchup between v2 onions and an IPv6 /48.

So is there an efficient way to specify a v2-sized subset of v4 onions?

>> On Dec 3, 2018, at 10:28 PM, Mirimir <***@riseup.net> wrote:
>>
>> On 12/03/2018 10:42 PM, Nathaniel Suchy wrote:
>>
>> <SNIP>
>>
>>> You mentioned "HiddenServiceAuthorizeClient", a feature I did not know about. I'm going to figure out if this is possible to implement on the SSH System as that would solve some concerns about a leaked onion address. Could you elaborate a bit more on this functionality?
>>
>> <SNIP>
>>
>> I've just used basic authentication.
>>
>> In the .onion server torrc:
>>
>> $ sudo nano /etc/tor/torrc
>> ...
>> HiddenServiceDir /var/lib/tor/foo
>> HiddenServiceAuthorizeClient basic [16-chracter-string]
>> HiddenServicePort 22 127.0.0.1:22
>> ...
>>
>> $ sudo cat /var/lib/tor/foo/hostname
>> [v2-hostname].onion [22-character-string] # client: [16-chracter-string]
>>
>> The client ID must be 16 alphanumeric characters. Then you use the 22
>> character string in the client torrc.
>>
>> In the client:
>>
>> $ sudo nano /etc/tor/torrc
>> ...
>> HidServAuth [v2-hostname].onion [22-character-string]
>> ...
>> --
>> tor-talk mailing list - tor-***@lists.torproject.org
>> To unsubscribe or change other settings go to
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>
>
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torpro

[Mirimir]

On 12/04/2018 03:55 PM, Mirimir wrote:

<SNIP>

Doh. Make that:

> So is there an efficient way to specify a v2-sized subset of v3 onions?

<SNIP>
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-b

[meejah]

Nathaniel Suchy <***@lunorian.is> writes:

> It's true that someone malicious can run a HSDir and get some (but not
> all) of the Onion Addresses however this would assume that your onion
> address ends up in a malicious HSDir (last time I checked it's
> published to 5 different HSDirs?).

v3 onions get rid of this enumeration attack entirely. They can be used
now with a recent Tor.

A wider point here is that "enumerate all .onions" *is* considered an
attack on the Tor network, so any "list of onion addresses" would have
to be strictly opt-in.

Anyone can therefore offer such a service (and people have over the
years done just that).

--
meejah

--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/ma

[Nathaniel Suchy]

I'll change to v3 Onion Services in the very near future. I hear that there are so many security improvements with v3 Onion Services and can't wait to give them a try :)

Also I agree with the wider point. You are attacking the network and likely violating the Tor Research Ethics Policy that was set out a while back. Publishing a master list is a very bad idea and I hope this never happens.

I like the idea of opt-in lists, but I shouldn't have to speak to opt-out of a list, just remain quiet and not opt-in.

Cordially,
Nathaniel Suchy



Dec 4, 2018, 1:43 PM by ***@meejah.ca:

> Nathaniel Suchy <> ***@lunorian.is <mailto:***@lunorian.is>> > writes:
>
>> It's true that someone malicious can run a HSDir and get some (but not
>> all) of the Onion Addresses however this would assume that your onion
>> address ends up in a malicious HSDir (last time I checked it's
>> published to 5 different HSDirs?).
>>
>
> v3 onions get rid of this enumeration attack entirely. They can be used
> now with a recent Tor.
>
> A wider point here is that "enumerate all .onions" *is* considered an
> attack on the Tor network, so any "list of onion addresses" would have
> to be strictly opt-in.
>
> Anyone can therefore offer such a service (and people have over the
> years done just that).
>
> --
> meejah
>
> --
> tor-talk mailing list - > tor-***@lists.torproject.org <mailto:tor-***@lists.torproject.org>
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>
>

--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torp

[i***@cock.li]

Tor does NOT have responsibility that the lists make onion sites
good/bad.
Who publishes the lists may have... a part of the responsibility?
Anyway I want the lists!

Then I studied below:
https://www.torproject.org/docs/onion-services
From this, DB (relay?) can get onion service descriptors.
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt
From this, HSDir relay can get hidden service descriptors.

The descriptors seem to indicate onion addresses. So if I act a relay, I
seem to be able to get the addresses. Then how? ... Could someone
skilled try to get the lists? :D
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailm

[grarpamp]

> The descriptors seem to indicate onion addresses. So if I act a relay, I
> seem to be able to get the addresses. Then how? ... Could someone
> skilled try to get the lists? :D

Yes, many services, researchers, and privates routinely do this.
The code exists in some repositories, or you can write your own,
it's not hard. Enumeration and listing in and of itself is not a problem,
neither good nor bad on its face, a mere fact of the technology in use.

It's up to the v2 users to decide if the tech works for them or not,
fits their use case or not, and whether or not to use it, not use it,
or use something else, or to seek or be provided education on the
tech and tradeoffs. For many users, v2 vs v3 simply doesn't matter.
For others, you may wish to blog or help them choose v2 vs v3.

And in fact, v2 onion services are very useful when combined
with OnionCat to yield IPv6 and UDP transport among tor's P2P
onions. That's simply not possible with v3's no-IP TCP only onions.
So for example, VoIP and other existing and new comms apps,
mossh, and Bittorrent freespeech and robust uncensorable
distribution channels, are enabled and exist entirely within tor's
v2 onion space, somewhat similar to I2P. Search the list and
tickets for "onioncat" for other use cases.

Just because some poor souls footshoot themselves... which they'll
still obviously somehow mangage to do with any tech regardless...
isn't sufficient reason to cease support, maintenance, development,
backporting, and furtherance of an agnostic technology such
as v2 onions.
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor

[grarpamp]

> with OnionCat to yield IPv6 and UDP transport among tor's P2P
> That's simply not possible with v3's no-IP TCP only onions.

That is to say, it's not possible with code that exists today...
the various possible solutions, and others yet to be proposed,
that could provide those things with v3 onions, haven't been
developed and put into working code yet. As such, it would be
an interesting project for anyone or group that wants to do it.
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject

[grarpamp]

[Typo in onion list address, fixed and resent herein]

> The descriptors seem to indicate onion addresses. So if I act a relay, I
> seem to be able to get the addresses. Then how? ... Could someone
> skilled try to get the lists? :D

Yes, many services, researchers, and privates routinely do this.
The code exists in some repositories, or you can write your own,
it's not hard. Enumeration and listing in and of itself is not a problem,
neither good nor bad on its face, a mere fact of the technology in use.

It's up to the v2 users to decide if the tech works for them or not,
fits their use case or not, and whether or not to use it, not use it,
or use something else, or to seek or be provided education on the
tech and tradeoffs. For many users, v2 vs v3 simply doesn't matter.
For others, you may wish to blog or help them choose v2 vs v3.

And in fact, v2 onion services are very useful when combined
with OnionCat to yield IPv6 and UDP transport among tor's P2P
onions. That's simply not possible with v3's no-IP TCP only onions.
So for example, VoIP and other existing and new comms apps,
mossh, and Bittorrent freespeech and robust uncensorable
distribution channels, are enabled and exist entirely within tor's
v2 onion space, somewhat similar to I2P. Search the list and
tickets for "onioncat" for other use cases.

Just because some poor souls footshoot themselves... which they'll
still obviously somehow mangage to do with any tech regardless...
isn't sufficient reason to cease support, maintenance, development,
backporting, and furtherance of an agnostic technology such
as v2 onions.


> with OnionCat to yield IPv6 and UDP transport among tor's P2P
> That's simply not possible with v3's no-IP TCP only onions.

That is to say, it's not possible with code that exists today...
the various possible solutions, and others yet to be proposed,
that could provide those things with v3 onions, haven't been
developed and put into working code yet. As such, it would be
an interesting project for anyone or group that wants to do it.
--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.

[Roger Dingledine]

On Tue, Dec 04, 2018 at 04:14:46PM +0000, ***@cock.li wrote:
> The descriptors seem to indicate onion addresses. So if I act a relay, I
> seem to be able to get the addresses. Then how? ... Could someone skilled
> try to get the lists? :D

Please don't.

In particular, if we notice that your relay is enumerating onion addresses
that it learns about, we will kick your relay out of the network.

That's because it's a known protocol bug with the old v2 onion service
design, and so we consider exploiting the bug to be a form of attacking
the network.

For a more detailed explanation, check out minutes 30-37 of
https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think
and you can follow along with slide 32 of
https://freehaven.net/~arma/slides-32c3.pdf

Or from yet another angle, if you're running a relay with the goal of
learning stuff about users, rather than the goal of providing safe
relaying for users, then I wonder what else you're willing to attack
or undermine rather than protect.

And if you're not forthcoming about your goals and why they're safe
enough, I worry that you're not a positive contributor to our community:
https://research.torproject.org/safetyboard.html

Hope this helps,
--Roger

--
tor-talk mailing list - tor-***@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torpro