[tor-relays] Possible problem with NYX

[teor]

> On 5 Sep 2018, at 02:36, Damian Johnson <atagar at torproject.org> wrote:
> 
> Nyx's 'should this be scrubbed' check is pretty simple [1].
> Inbound addresses are scrubbed if...
> 
> 1. You're configured to accept user traffic (ie. you set BridgeRelay
> in your torrc or have receive the Guard flag). [2]

There are so many edge cases for this check.

Flags are a *recommendation* to clients. They don't force clients
to behave a certain way.

For example:
* clients connecting via bridges can use a middle node as their
  second hop. These middle nodes will leak bridge addresses via nyx.
* clients and relays can have different consensuses:
  * if a relay loses the Guard flag, and finds out earlier than its clients,
    nyx will stop protecting those clients
  * if a client finds out before the relay, nyx won't protect those clients
* some Tor client versions don't check the guard flag at all. Others
  keep their guards, even if they lose the flag
* middle and exit relays can be used as bridges, even if they don't set
  BridgeRelay
* older Tor versions have a non-zero probability of choosing any relay
  as an entry, even if it doesn't have the guard flag
* various config options make tor clients ignore the Guard flag

Please only show an IP if the relay is already public in the consensus.

> 2. The connection doesn't belong to a another tor relay. [3]

> [1] https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n230
> [2] https://gitweb.torproject.org/stem.git/tree/stem/control.py
> [3] In particular, we check if the address/port is in the consensus.

You could also check if the connection is authenticated to a public relay.
But the IP check works in most cases, and if it fails, it's ok to keep more
info private.

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180905/0adce6f4/attachment-0001.html>