Opened 4 years ago

Last modified 2 years ago

#17971 new defect

Unrecognized relay in exit address '[scrubbed].exit'. Refusing.

Reported by: cypherpunks Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.6.10
Severity: Normal Keywords: log, docs, exit tor-client misleading-logs usability
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:

Description

This line appeared in my tor log the other day.

Unrecognized relay in exit address '[scrubbed].exit'. Refusing.

I don't know what it means, and a quick search didn't return anything useful. I wasn't doing anything out of the ordinary; just using Tor Browser. I use the system-installed Tor, so it could have come from anything on the system I guess. Safe logging was enabled, so I don't know what address was requested.

When I tried to reproduce it by making an explicit request to foo.nonexistant.exit, I got this.

The ".exit" notation is disabled in Tor due to security risks. Set AllowDotExit in your torrc to enable it (at your own risk).

What does the first line mean, and why wasn't the request rejected by AllowDotExit=0? Is this something I should be worried about? Even if it's benign, hopefully users who get this warning will find this ticket in searches, since I've been unable to find the exact message anywhere.

Child Tickets

Change History (11)

comment:1 Changed 4 years ago by nickm

Keywords: log doc exit added
Milestone: Tor: 0.2.8.x-final

summary: no reason to be worried; the bug here is that the original log message is pretty unhelpful.

So, the security fix for the problems with .exit is that Tor by default doesn't allow any .exit addresses from the user. But it still has a notion of "desired exit for a stream/circuit" internally, that it uses to implement features like TrackHostExits. My best guess here is that when Tor generates log messages about internal "desired exits" failing, it logs them as if the user had requested them, which is of course confusing.

The correct fix here is probably to make the log message describe better why Tor was trying to use that exit, and what happened.

comment:2 Changed 4 years ago by cypherpunks

Thanks for the explanation. I do use TrackHostExits, so that could have caused it. The error makes sense knowing that it is caused by internal exit selection, but otherwise the log message is unhelpful as you stated. I am curious why Tor would try to use an unrecognized relay address, so it might be worth logging that information too. It doesn't sound like too difficult of a fix.

comment:3 Changed 4 years ago by arma

Maybe the relay went unrecognized because it was still pegged in TrackHostExits, yet the relay disappeared from the consensus?

comment:4 Changed 4 years ago by nickm

Priority: MediumLow

comment:5 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

Throw most 0.2.8 "NEW" tickets into 0.2.9. I expect that many of them will subsequently get triaged out.

comment:6 Changed 3 years ago by nickm

Points: small/medium

comment:7 Changed 3 years ago by nickm

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???
Points: small/medium2

Would be interesting to do a better fix here; the right way to do this is to improve the log message to note where the .exit address came from. I can't get to this myself in 0.2.9 though.

comment:8 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:9 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:10 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 2 years ago by nickm

Keywords: docs tor-client misleading-logs usability added; doc removed
Note: See TracTickets for help on using tickets.