[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tor-talk] How stealth onions actually function?
On Sat, Aug 06, 2016 at 10:24:53AM +0300, Nurmi, Juha wrote:
> I have been playing with stealth onion services to protect some of my
> SSH servers from SSH MITM. I like to keep my servers as hidden as possible.
> Great to have this option on Tor :) I have some questions about it and I
> didn't find much information.
The only documentation I know that exists is the spec.
> Could someone tell me how it actually functions? What is the difference
> between basic and stealth? In addition, can an attacker verify that onions
> with stealth option exists and are online?
The spec has a more detail, but briefly both authentication methods rely on
a pre-shared secret between client and service. The distinction is made where
that shared-secret is used.
When a service uses basic authentication instead of publishes its introduction
points in plaintext, it encrypts the list of intro points with a key chosen at
random and then encrypts that symmetric key multiple times using the shared
secret for each client it has configured. With this, all clients can retrieve
the hidden service descriptor from the HSDir but if a client doesn't have a
valid shared secret then they can't find the intro points from the descriptor.
From the spec:
When generating a hidden service descriptor, the service encrypts the
introduction-point part with a single randomly generated symmetric
128-bit session key using AES-CTR as described for v2 hidden service
descriptors in rend-spec. Afterwards, the service encrypts the session
key to all descriptor cookies using AES. Authorized client should be able
to efficiently find the session key that is encrypted for him/her, so
that 4 octet long client ID are generated consisting of descriptor cookie
and initialization vector.
Stealth authentication is similar, except it publishes a hidden service
descriptor for each configured client.
With all else being equal to the preceding authorization protocol, the
second protocol publishes hidden service descriptors for each user
separately and gets along with encrypting the introduction-point part of
descriptors to a single client.
A hidden service generates an asymmetric "client key" and a symmetric
"descriptor cookie" for each client. The client key is used as
replacement for the service's permanent key, so that the service uses a
different identity for each of his clients. The descriptor cookie is used
to store descriptors at changing directory nodes that are unpredictable
for anyone but service and client, to encrypt the introduction-point
part, and to be included in INTRODUCE2 cells
> Moreover, several research papers measure the total number of onions and we
> know that someone is crawling TorHS Directories.
> Does HiddenServiceAuthorizeClient protect you against these measurements?
> I tested my stealth service without the passphrase on Tor client and Tor
> says "Closing stream for '[scrubbed].onion': hidden service is unavailable
> (try again later)."
> Tor manual describes HiddenServiceAuthorizeClient option:
> "If configured, the hidden service is accessible for authorized clients
> only. The auth-type can either be 'basic' for a general-purpose
> authorization protocol or 'stealth' for a less scalable protocol that also
> hides service activity from unauthorized clients. Only clients that are
> listed here are authorized to access the hidden service."
This is exactly one reason why stealth hidden services are great.
>  https://github.com/juhanurmi/stealth-ssh
>  https://www.torproject.org/docs/tor-manual.html.en
tor-talk mailing list - firstname.lastname@example.org
To unsubscribe or change other settings go to