[tor-relays] Combined relay and hidden service, good idea or not?

[Florentin Rochet]

Hey Tortilla,

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 
HS's location.

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?

> <skip>
>
>> 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" [1] (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 
be changed.

>
> 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 :-)

Best,
Florentin

> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays