[tor-talk] How stealth onions actually function?

[Marina Brown]

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.finkel at 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 at 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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20160807/8432055e/attachment.sig>