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

[Nathaniel Suchy <me@xxxxxxxxxxx>]

Hi,

The implementation details of the SSH thing I talked about in my last email may of been unclear. When I said it's an security by advanced obscurity, I did not mean it's the only security. Other forms of access control are still in place. However keeping it only accessible over Onion Services means I don't have bots constantly trying to brute their way into SSH (stupid considering password auth is disabled guess that's China Unicom for you) I worry that publishing a list of every onion addressing would cause the same problem to come back.

1) User establishes a connection to OpenSSH Server over Tor Onion Services

2) User authenticates with their SSH Key (Password Auth is disabled, you can't even log in as root you need your own user and sudo)

2.5?) Secondary auth (played around with TOTP and U2F however haven't found a solution stable enough for my needs yet - still looking into it :)   )

3) User has a remote interactive bash shell protected with Onion Protocol Encryption

4) User is hopefully happy? Onion Services do tend to have higher latency so text editors like nano can be a bit sluggish - working on these issues one day at a time.

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?). Most relays are run by good individuals. While the risk is considered, it's still better than a public address.

I'm sure people on this list heard about the LibSSH Vulnerabilty (Knock knock, can I come in, yes I can come in, I come in) a while back. While requiring users to access it over an Onion Service doesn't solve the larger problem of security vulnerabilty is limits who can attack exploit it. Targeted attacks will still work, however if all Vulnerable LibSSH Servers were hidden behind an unlisted Onion Service we wouldn't be having mass exploitation problems.

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?

Cordially,
Nathaniel Suchy



Dec 3, 2018, 4:35 PM by s7r@xxxxxxxxxx:

> 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!*
>

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