#16824: Emit a warning message about side channel leaks when using relays as clients -------------------------------------------------+------------------------- Reporter: starlight | Owner: (none) Type: defect | Status: | needs_revision Priority: High | Milestone: Tor: | 0.3.5.x-final Component: Core Tor/Tor | Version: Tor: | 0.2.6.10 Severity: Normal | Resolution: Keywords: mike-can, tor-client tor-relay | Actual Points: sidechannel logging easy | Parent ID: | Points: 1 Reviewer: mikeperry | Sponsor: -------------------------------------------------+------------------------- Changes (by mikeperry):
* status: needs_review => needs_revision Comment: Initial thoughts: I don't like issuing a warning about merely having the SocksPort set. It is set by default. I also don't think telling relay operators to set it to 0 solves any problems here. In fact, all it does is make those people who deliberately set it more obvious. I don't really care about the case where the relay stalls briefly merely because it happens to build some testing/predicted circuits for a little while. In the grand scheme of things that cause Tor's performance to be poor, this side channel by itself is very very low on the list (though it is a result of our single-threaded architecture, which *is* a huge performance problem). However, I do care about the case where people are actively using their relay as a client. This indicates that they are trying to get some benefit from having relay traffic mixed with client traffic, and in the process, they are making it clear to external observers that their relay is doing client things (due to stalls of all traffic during client circuit construction from #16585). I still think that what those people actually want to do is use their Tor relay as a local bridge, and pin a guard node after it. Unfortunately, having a guard after a bridge is not something we support yet for general use (iirc, isis was working on a bridgeguards patch to prevent bridge enumeration by a censor, but I don't know if that got finished). We can have a guard/guards after this bridge for hidden services via the HSLayer2Nodes -- in that cause your layer2 guards become like entry guards, and your layer3 guards are functionally layer2 guards. But then, you would be a client that looks like they are using layer2 vanguards but not layer3 vanguars, which may be odd or rare. I have to think more about this to decide if that actually matters/is detectable. And then, even in this case, it is only something that relay operators who are running hidden services can do. Anyway as-is this is needs revision. We should discuss what we actually think people who want do this should be doing, and why, rather than just yelling at everybody who uses the default SocksPort in their relay. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16824#comment:48> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs