On 08/07/2016 12:16 AM, Nurmi, Juha wrote: > 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 >>
I use stealth onions to create a private email service - here is a prototype of one service i am working on. It is really rough. It uses debian postfix as a mailserver and a modified tails as a client. https://github.com/catskillmarina/torgroups/ --- Marina
signature.asc
Description: OpenPGP digital signature
-- 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
