[tor-relays] Combined relay and hidden service, good idea or not?
florentin.rochet at uclouvain.be
Mon Jan 8 10:21:48 UTC 2018
Sorry for the late reply:
On 2018-01-05 21:13, Tortilla wrote:
>> The issue is fixed by adding the above warning message: if you care
>> about your hidden service's "hidden" property, do not run a relay on the
>> same process.
> Would you mind elaborating? As I read the tracker link, the issue was an
> informational leak in bandwidth reporting that has now been solved and
> closed. As such, the startup warning is misleading unless there are other
> concerns (such as Igor's below) and in which case, the warning should be
> re-worded. Why do you say it is *fixed* by adding a warning?
https://trac.torproject.org/8742 issue is already a stronger concern
than Igor's point, and there are more. The informational leak in
bandwidth is still there today, since these measurements are public. The
issue is marked as fixed because, if you do relay+HS, you got a warning
"not secure" that links to a possible attack (#8742) to recover your
To be honest, I don't really get why you feel that the startup warning
is misleading. Is it because it links a fixed and closed trac issue?
>> The part "cannot easily run an analysis targeted at a hidden service"
>> looks just wrong to me. If you want an example of an active attacker
>> able to easily uncover such a hidden service (when mixed with a relay),
>> you can give a look at our paper "Dropping on the Edge: Flexibility and
>> Traffic Confirmation in Onion Routing Protocols"  (to appear in
>> PoPETs18). The techniques presented are not applied on that particular
>> setup, but this is somewhat trivial to do.
> I believe the logic was that if a machine is identified in some way as one
> to watch, and if it is seen participating in the Tor network but is not
> listed as a public relay, it's easier to conclude that it may be hosting a
> hidden service, after which other correlation attacks can be targeted at
> the machine. Thus, the recommendation that running a public relay helps
> mask HS traffic.
> Perhaps in the case that the HS operator is not trying to mask the HS
> location, the act of mixing public relay traffic can be nothing but a
> *help* to defeat anyone trying to correlate traffic coming to the HS with
> traffic emanating from any one client.
Yes, if the HS operator does not want to mask the HS location, then it
is all good. For that purpose, I agree that the warning message should
> Forgive me for only skimming your paper, but I didn't see any explanation
> that the attack outlined was either facilitated or enhanced by the HS also
> running a relay. Would you mind commenting?
Ok, so suppose a public relay and a hidden service running on the same
process, and the attacker knows the onion address. The hidden service's
location can be uncovered using public bandwidth leaks of the relay.
Just do the following trick: send a few GB of trash data to the hidden
service using the kind of method described in the paper. Then, wait that
the public measurements are updated and look for the relay having a few
more GB of read data than write data. You should obtain only one IP.
Congrats, it's the IP of the hidden service.
So, if you care about your HS's hidden location, do not run a relay on
the same process :-)
> tor-relays mailing list
> tor-relays at lists.torproject.org
More information about the tor-relays