Hello ops,
Today I noticed something on NYX that I find disturbing. Page 2 (list of inbound/outbound connections) showed me the IP address of an inbound connection on one of my bridges! Not the authority. This is crazy as these are indicated as <scrubbed>:port for the users protection! I have never seen this before and haven't seen it since. Of course, on low usage bridges, the connection IP address can possibly be disseminated from netstat but that's not the point. It's my sense that this should never happen. I get chills imagining this happening on a guard relay operated by an antagonist ! !
I'm using the default NYX configuration on Ubuntu server 18.04.1 LTS, Tor 0.3.3.9.
Arisbe
You have to decide a balance of usefulness to a legitimate operator and privacy concerns. I could just as easily run Wireshark or TCPDump on my relays and get client IP Addresses that way. You are trusting most operators, like me, are the good guys. Of course a client IP isn’t very useful without a way to associate exit traffic to them.
Cordially, Nathaniel
On Mon, Sep 3, 2018 at 4:14 PM arisbe arisbe@cni.net wrote:
Hello ops,
Today I noticed something on NYX that I find disturbing. Page 2 (list of inbound/outbound connections) showed me the IP address of an inbound connection on one of my bridges! Not the authority. This is crazy as these are indicated as <scrubbed>:port for the users protection! I have never seen this before and haven't seen it since. Of course, on low usage bridges, the connection IP address can possibly be disseminated from netstat but that's not the point. It's my sense that this should never happen. I get chills imagining this happening on a guard relay operated by an antagonist ! !
I'm using the default NYX configuration on Ubuntu server 18.04.1 LTS, Tor 0.3.3.9.
Arisbe
-- One person's moral compass is another person's face in the dirt.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi arisbe. This isn't as concerning as you seem to think. As Nathaniel mentions it's simple to get this information, Nyx is simply attempting to scrub it cuz... well, it's ethically and legally the right thing to do. 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] 2. The connection doesn't belong to a another tor relay. [3]
Does the relay show relay information such as a fingerprint? If so then it shouldn't be scrubbed. If it doesn't and you've set BridgeRelay in your torrc then please let us know on...
https://trac.torproject.org/projects/tor/wiki/doc/nyx/bugs
Thanks! -Damian (author of nyx and stem)
[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.
On Mon, Sep 3, 2018 at 1:13 PM, arisbe arisbe@cni.net wrote:
Hello ops,
Today I noticed something on NYX that I find disturbing. Page 2 (list of inbound/outbound connections) showed me the IP address of an inbound connection on one of my bridges! Not the authority. This is crazy as these are indicated as <scrubbed>:port for the users protection! I have never seen this before and haven't seen it since. Of course, on low usage bridges, the connection IP address can possibly be disseminated from netstat but that's not the point. It's my sense that this should never happen. I get chills imagining this happening on a guard relay operated by an antagonist ! !
I'm using the default NYX configuration on Ubuntu server 18.04.1 LTS, Tor 0.3.3.9.
Arisbe
-- One person's moral compass is another person's face in the dirt.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thanks for this added info--it helps.
On 9/4/2018 9:36 AM, Damian Johnson wrote:
Hi arisbe. This isn't as concerning as you seem to think. As Nathaniel mentions it's simple to get this information, Nyx is simply attempting to scrub it cuz... well, it's ethically and legally the right thing to do. Nyx's 'should this be scrubbed' check is pretty simple [1]. Inbound addresses are scrubbed if...
- You're configured to accept user traffic (ie. you set BridgeRelay
in your torrc or have receive the Guard flag). [2] 2. The connection doesn't belong to a another tor relay. [3]
Does the relay show relay information such as a fingerprint? If so then it shouldn't be scrubbed. If it doesn't and you've set BridgeRelay in your torrc then please let us know on...
https://trac.torproject.org/projects/tor/wiki/doc/nyx/bugs
Thanks! -Damian (author of nyx and stem)
[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.
On Mon, Sep 3, 2018 at 1:13 PM, arisbe arisbe@cni.net wrote:
Hello ops,
Today I noticed something on NYX that I find disturbing. Page 2 (list of inbound/outbound connections) showed me the IP address of an inbound connection on one of my bridges! Not the authority. This is crazy as these are indicated as <scrubbed>:port for the users protection! I have never seen this before and haven't seen it since. Of course, on low usage bridges, the connection IP address can possibly be disseminated from netstat but that's not the point. It's my sense that this should never happen. I get chills imagining this happening on a guard relay operated by an antagonist ! !
I'm using the default NYX configuration on Ubuntu server 18.04.1 LTS, Tor 0.3.3.9.
Arisbe
-- One person's moral compass is another person's face in the dirt.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 5 Sep 2018, at 02:36, Damian Johnson atagar@torproject.org wrote:
Nyx's 'should this be scrubbed' check is pretty simple [1]. Inbound addresses are scrubbed if...
- 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.
- 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
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.
Thanks teor, great point. Will do: https://trac.torproject.org/projects/tor/ticket/27475
tor-relays@lists.torproject.org
-
arisbe -
Damian Johnson -
Nathaniel Suchy -
teor