Re: [tor-talk] privacy of hidden services

[Allen <allenpmd@xxxxxxxxx>]

From the discussion and studying the specs, my understanding is that:

The HS directory servers receive the HS public key aka onion address.
The information leakages are: (1) through various HSdir  enumeration
techniques, the world at large can discover the HS public key and
onion address; (2) the HS directory server is able to monitor service
descriptor uploads and retrievals.  Rend-spec v3 will change this by
instead sending the HS directory servers a pseudorandom subkey that
changes every 24 hours and can only be predicted by someone who knows
the onion address, which will prevent leakage of the onion address and
prevent long-term monitoring of descriptor uploads and retrievals for
an onion address that is not publicly published.

The HS directory servers also receive the list of intro points and
ephemeral service keys.  If basic or stealth auth is used, this is
encrypted so there is no info leakage--only authorized users can
obtain this info.

The only difference between basic and stealth auth is that stealth
auth is equivalent to creating a different onion address for each
authorized user.

The intro points receive only an ephemeral service key.  When basic or
stealth auth is used, the relationship between permanent keys and
ephemeral keys is only available to authorized users.  The intro point
can track the establishment of service connections for the ephemeral
key, but can't tie that back to the onion address.

The rendezvous point receives only a randomly generated single-use
cookie.  It knows it is establishing a rendezvous connection, but does
not know for what service.  The single-use cookie is sent to the HS
encrypted with the HS key, so only the HS can read that transmission.

To summarize, the info leakages for HS that do not use authorization are:

- World at large can discover onion address using various directory
enumeration techniques.
- HS directory can track HS descriptor uploads and downloads and tie
those to the onion address.
- Intro point can track HS connection attempts and relate them to onion address.

For HS's that use basic authorization:

- World at large can discover onion address.
- HS directory can track HS descriptor uploads and downloads and tie
those to the onion address.
- Intro point can track HS connection attempts but only relate them to
the ephemeral service key for the duration of the key.
- Authorized users who operated an intro point could track HS
connection attempts through that intro point.

For HS's that use stealth authorization:

- Each authorized user uses a different effective onion address.
World at large can discover each of those onion addresses, but can't
relate them to each other.
- HS directory can track HS descriptor uploads and downloads for each
individual onion address, but can't relate them to each other.
- Intro point can track HS connection attempts but only relate them to
ephemeral service key for the duration of the key.

Is all that correct?


On Wed, Dec 21, 2016 at 1:58 PM, David Goulet <dgoulet@xxxxxxxxx> wrote:
> On 21 Dec (19:37:13), Aeris wrote:
>> > Would anyone outside of myself and those two
>> > people be able to determine the onion address
>>
>> Yes. Your onion address is published on a DHT, hosted accross all nodes with
>> HSDir flag. Some bad behaviouring relays try to enumerate all onion addresses
>> by massive HSDir node creation to fetch different part of the DHT each time.
>
> Quick note that our next version of onion service (v3) will mitigate this
> harvesting as the HSDir and Introduction Point won't be able to learn the
> onion address. But yes, currently this is a weakness in the protocol.
>
>>
>> > or monitor activity related to the hidden service such as HS descriptor
>> uploads and downloads from directory servers, or connection attempts via
>> > introduction or rendezvous points?
>>
>> Yes too. HSDir node and rendez-vous points can monitor HS usage, because
>> HSDir/RdVPoint usage for a single HS is correlated to this HS usage.
>
> Wait. Rendezvous Point (RP) do *NOT* know the onion service identity unless
> you do some sort of circuit fingerprinting or HSDir correlation attacks. But,
> assuming not doing such an attack, RPs don't have the information. It can only
> track how much traffic is going through an onion service circuit without
> knowing which service it is.
>
> But, the Introduction Point (IP) does! so it can monitor how many connections
> are made to the service using the IP and identify the .onion. Although, it
> won't get them all as a normal descriptor has 3 different IPs but it can
> extrapolate easily.
>
>>
>> > Would it make a difference if the hidden service used basic or stealth
>> authorization?
>>
>> AFAIK, no. Auth for a HS is only to forbid unallowed client to connect to it,
>> but doesn't change the way HSDir and RdVPoint are handled.
>
> Correct except not the RdVPoint but the Introduction Point will be different
> for stealth authorization as it is a descriptor per client authorization.
>
> Cheers!
> David
>
>>
>> Regards,
>> --
>> Aeris
>> Individual crypto-terrorist group self-radicalized on the digital Internet
>> https://imirhil.fr/
>>
>> Protect your privacy, encrypt your communications
>> GPG : EFB74277 ECE4E222
>> OTR : 5769616D 2D3DAC72
>> https://café-vie-privée.fr/
>
>
>
>> --
>> 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