[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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!


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

> 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@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-talk@lists.torproject.org
To unsubscribe or change other settings go to