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?