Hello. I have configured my relay (jaffacakemonster2) to be non exit, however arm shows me the following (I edited out IPs' & some lines after copy/paste from connection screen for others security / brevity) Connections (1878 inbound, 2113 outbound, 19 exit, 1 control) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.4m (EXIT) IP --> <scrubbed>:4000 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.4m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 1.0m (EXIT) IP --> <scrubbed>:26155 UNKNOWN UNKNOWN 3.5m (EXIT) Atlas reports the flags Fast, Running & Valid. Lines as copied & pasted from torrc: ## Uncomment this if you do *not* want your relay to allow any exit traffic. ## (Relays allow exit traffic by default.) ExitRelay 0 What is going on here? I am confused as to why there is exit connections but I am not / dont want an exit relay. Thanks.
On 5 Mar 2018, at 21:02, Gary <jaffacakemonster53@gmail.com> wrote:
Hello.
I have configured my relay (jaffacakemonster2) to be non exit, however arm shows me the following (I edited out IPs' & some lines after copy/paste from connection screen for others security / brevity)
Connections (1878 inbound, 2113 outbound, 19 exit, 1 control) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.4m (EXIT) IP --> <scrubbed>:4000 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.4m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 1.0m (EXIT) IP --> <scrubbed>:26155 UNKNOWN UNKNOWN 3.5m (EXIT)
Atlas reports the flags Fast, Running & Valid.
Lines as copied & pasted from torrc:
## Uncomment this if you do *not* want your relay to allow any exit traffic. ## (Relays allow exit traffic by default.) ExitRelay 0
What is going on here? I am confused as to why there is exit connections but I am not / dont want an exit relay.
I think this is a bug in arm. Try nyx. T -- teor teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
Oops! Actually, this would happen with Nyx too. This is a Stem bug... https://trac.torproject.org/projects/tor/ticket/25423 Thanks for the catch! On Mon, Mar 5, 2018 at 2:49 AM, teor <teor2345@gmail.com> wrote:
On 5 Mar 2018, at 21:02, Gary <jaffacakemonster53@gmail.com> wrote:
Hello.
I have configured my relay (jaffacakemonster2) to be non exit, however arm shows me the following (I edited out IPs' & some lines after copy/paste from connection screen for others security / brevity)
Connections (1878 inbound, 2113 outbound, 19 exit, 1 control) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:443 (HTTPS) UNKNOWN UNKNOWN 3.4m (EXIT) IP --> <scrubbed>:4000 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.5m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 3.4m (EXIT) IP --> <scrubbed>:9001 UNKNOWN UNKNOWN 1.0m (EXIT) IP --> <scrubbed>:26155 UNKNOWN UNKNOWN 3.5m (EXIT)
Atlas reports the flags Fast, Running & Valid.
Lines as copied & pasted from torrc:
## Uncomment this if you do *not* want your relay to allow any exit traffic. ## (Relays allow exit traffic by default.) ExitRelay 0
What is going on here? I am confused as to why there is exit connections but I am not / dont want an exit relay.
I think this is a bug in arm. Try nyx.
T
-- teor
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hello, On Mon, Mar 5, 2018 at 2:49 AM, teor <teor2345@gmail.com> wrote: > I think this is a bug in arm. > Try nyx. I switched to nyx and it is fine allthough on deeper inspection the IP to <scrubbed> is actually my IP so clearly this is a bug. On 5 March 2018 at 18:18, Damian Johnson <atagar@torproject.org> wrote: > Oops! Actually, this would happen with Nyx too. This is a Stem bug... On reading the bug report, I have always used 'ExitPolicy reject *:*' and it wasn't until I installed tor on a new machine and on reading/editing the new default torrc I was surprised to learn that relays are now exit by default, so use both just to be sure. I am glad I took the time to read the 235 line torrc and the service-defaults in /usr/share/tor!! Thanks.
On Mon, Mar 05, 2018 at 10:02:10AM +0000, Gary wrote:
What is going on here? I am confused as to why there is exit connections but I am not / dont want an exit relay.
I am guessing those are self-reachability tests and self-speed tests that your relay does by making circuits back to itself. And I'm guessing that having arm or nyx label them as "exit" circuits is a confusing bug in arm/nyx. https://trac.torproject.org/projects/tor/ticket/6430 https://trac.torproject.org/projects/tor/ticket/12956 Based on that last ticket, it looks like the confusing word should have been fixed in recent nyx. If it's still there, or there are similarly confusing words, please open a ticket. --Roger
Hi Roger, I don't think thats' the issue here. The lines they cited were exit connections, not the 'Exit' circuit lines (the later look different and don't include scrubbing). For what it's worth here's where Nyx decides to label a connection as being an exit. The conditional is "if I can't resolve this to a relay and our exit policy allows exiting to it then label as an exit"... https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n225
I switched to nyx and it is fine allthough on deeper inspection the IP to <scrubbed> is actually my IP so clearly this is a bug.
Hi Gary. Sorry, not sure I follow. Are you saying Nyx (not arm) is labeling these as 'Outbound' but still scrubbing the address? Cheers! -Damian
On 6 Mar 2018, at 11:06, Damian Johnson <atagar@torproject.org> wrote:
For what it's worth here's where Nyx decides to label a connection as being an exit. The conditional is "if I can't resolve this to a relay and our exit policy allows exiting to it then label as an exit"...
https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n225
Is there something we can do in Tor to make it easier for Stem and other controllers to distinguish Exit connections from OR connections? Does Tor export a list of connections over the control port? (Tor has all the information, but it might not be available over the control port. Or it might be available, but somewhere you don't expect.) T
Does Tor export a list of connections over the control port?
Hi teor. Nope, tor doesn't. That's something I wanted many years ago and I made a proposal, but Jake talked me into limiting it to circuits instead... https://gitweb.torproject.org/torspec.git/tree/proposals/172-circ-getinfo-op... Having tor provide this would be very helpful. Stem vends nine different connection resolvers because it doesn't. ;P https://gitweb.torproject.org/stem.git/tree/stem/util/connection.py Cheers! -Damian
On 6 Mar 2018, at 11:29, Damian Johnson <atagar@torproject.org> wrote:
Does Tor export a list of connections over the control port?
Hi teor. Nope, tor doesn't. That's something I wanted many years ago and I made a proposal, but Jake talked me into limiting it to circuits instead...
https://gitweb.torproject.org/torspec.git/tree/proposals/172-circ-getinfo-op...
Having tor provide this would be very helpful. Stem vends nine different connection resolvers because it doesn't. ;P
https://gitweb.torproject.org/stem.git/tree/stem/util/connection.py
And a bunch of researchers I'm working with wrote their own connection event, too. A circuit getinfo sounds like a great feature. I'd be happy to review a proposal, but I'm not sure I'd have time to implement it. T
A circuit getinfo sounds like a great feature. I'd be happy to review a proposal, but I'm not sure I'd have time to implement it.
No worries! As mentioned, we already have a proposal. Eight years ago Nick encouraged me to write proposals for things I'd find helpful, but of course a proposal doesn't magically turn into engineering resources. We all have things on our plate, and there's no point in spending time writing proposals unless it's gonna turn into something. :) Cheers! -Damian
On 6 Mar 2018, at 12:27, Damian Johnson <atagar@torproject.org> wrote:
A circuit getinfo sounds like a great feature. I'd be happy to review a proposal, but I'm not sure I'd have time to implement it.
No worries! As mentioned, we already have a proposal. Eight years ago Nick encouraged me to write proposals for things I'd find helpful, but of course a proposal doesn't magically turn into engineering resources. We all have things on our plate, and there's no point in spending time writing proposals unless it's gonna turn into something. :)
Sorry, I meant to write "connection getinfo". And I'm not sure that the original reasoning applies: if Stem is getting the information from other sources anyway, why don't we just provide it through Tor? T
Hello, On 6 March 2018 at 00:06, Damian Johnson <atagar@torproject.org> wrote:
I switched to nyx and it is fine allthough on deeper inspection the IP to <scrubbed> is actually my IP so clearly this is a bug.
Hi Gary. Sorry, not sure I follow. Are you saying Nyx (not arm) is labeling these as 'Outbound' but still scrubbing the address?
When I switched to nyx the problem was gone - nyx did not list any *exit* connections. Before I copied & pasted arm's output (see first email) I changed the IP address in the first column to the words "IP". It turns out that IP was mine so there was no point in removing it for security as its already on Atlas. On 5 March 2018 at 23:15, Roger Dingledine <arma@mit.edu> wrote:
I am guessing those are self-reachability tests and self-speed tests that your relay does by making circuits back to itself.
Its worth noting that I have seen circuits on arm / nyx as part of reach ability tests like this (ref: https://trac.torproject.org/projects/tor/ticket/12956): 76.99.61.63 --> 188.138.17.248 (fr) 3.1m (CIRCUIT) │ 83.168.200.204 (se) ParadiseTorRelay1 1 / Guard │ 18.181.5.37 (us) VERITAS 2 / Middle └─ 188.138.17.248 (fr) EuropeCoastDE 3 / Exit However this is the first time arm has shown me "exit" connections like list on first email. Hope that helps you. Gary.
Sorry, I meant to write "connection getinfo".
And I'm not sure that the original reasoning applies: if Stem is getting the information from other sources anyway, why don't we just provide it through Tor?
Ah! Gotcha. No argument from me.
Its worth noting that I have seen circuits on arm / nyx as part of reach ability tests like this (ref: https://trac.torproject.org/projects/tor/ticket/12956):
76.99.61.63 --> 188.138.17.248 (fr) 3.1m (CIRCUIT) │ 83.168.200.204 (se) ParadiseTorRelay1 1 / Guard │ 18.181.5.37 (us) VERITAS 2 / Middle └─ 188.138.17.248 (fr) EuropeCoastDE 3 / Exit
However this is the first time arm has shown me "exit" connections like list on first email.
Hi Gary, *this* is the thing Roger was talking about. With Nyx this should be labeled as 'End' rather than 'Exit' to cut down on the understandable concern the later term causes. :)
participants (4)
-
Damian Johnson -
Gary -
Roger Dingledine -
teor