[tor-talk] How stealth onions actually function?

[Matthew Finkel]

On Sat, Aug 06, 2016 at 10:24:53AM +0300, Nurmi, Juha wrote:
> Hi,
> 
> I have been playing with stealth onion services[1] 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[3].

> 
> 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[2]:
> 
> "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.

> [1] https://github.com/juhanurmi/stealth-ssh
> [2] https://www.torproject.org/docs/tor-manual.html.en
[3] https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n844