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@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays