Re: [tor-talk] How stealth onions actually function?

["Nurmi, Juha" <juha.nurmi@xxxxxxxx>]

Thanks Matthew!

So stealth makes onions really hidden by encrypting the list of intro
points. Nobody knows how many hidden services are out there. Great!

-Juha


On Sun, Aug 7, 2016 at 5:08 AM, Matthew Finkel <matthew.finkel@xxxxxxxxx>
wrote:

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