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

["Tortilla" <tortilla@xxxxxxxxxxxxx>]

>> When operating a hidden service and a relay in one tor instance, tor
>> currently warns:
>>
>> [warn] Tor is currently configured as a relay and a hidden service.
>> That's
>> not very secure: you should probably run your hidden service in a
>> separate
>> Tor process, at least -- see https://trac.torproject.org/8742
>>
>> First, that issue has been fixed and closed.
>
> 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?

Igor's point:

> It is safe to assume that both relays and select hidden services are
> being scanned 24/7. When your host reboots (say, as a result of an
> automatic OS update), both your relay and your hidden service become
> unavailable at the same time, instantly revealing the IP of the hidden
> service.

This seems crucial, unless an operator somehow schedules random downtime
for the relay or hidden service so that coinciding downtime can't be as
easily correlated.



>> Second, I had read in the past opinions stating:
>>
>> When operating a hidden service, running a relay helps mix traffic so
>> that
>> anyone observing traffic from the machine cannot easily run an analysis
>> targeted at a hidden service that might exist on that machine.
>
> 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.

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?

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