Re: [tor-bugs] #16824 [Core Tor/Tor]: Emit a warning message about side channel leaks when using relays as clients

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs