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.fin...@gmail.com> 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@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 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk