Opened 5 years ago

Closed 2 years ago

#13129 closed defect (worksforme)

Option for downgrading "Rejecting SOCKS request for anonymous connection to private address" log

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor Browser (or more precisely, both Tor Button and Tor Launcher) intentionally make requests via Tor to 127.0.0.1, because of #10682. See e.g.
https://gitweb.torproject.org/tor-launcher.git/blob/HEAD:/src/install.rdf#l12

So we have a thin but steady stream of users who see

Rejecting SOCKS request for anonymous connection to private address [scrubbed]

warnings in their logs, and ask us what the deal is.

That said, in other situations I've actually found it useful for that warn to show up, since e.g. my Pidgin was making requests to 127.0.0.1 rather than to the xmpp server, and that was a bug in my Pidgin.

Does that argue for a torrc option that TB can set to indicate that it knows it'll be doing this otherwise-considered-broken behavior?

Hm.

Child Tickets

Change History (14)

comment:1 Changed 5 years ago by cypherpunks

It's not *exclusively* occurring in the context of update checks, per the linked ticket. This also occurs, for example, when right-clicking in certain contexts.

comment:2 in reply to:  1 ; Changed 5 years ago by arma

Replying to cypherpunks:

It's not *exclusively* occurring in the context of update checks, per the linked ticket. This also occurs, for example, when right-clicking in certain contexts.

Can you provide enough details for us to reproduce?

It seems to me that any attempt to connect to localhost by the application, without the user specifically trying to do it, is a bug. But clearly the Tor Browser people think otherwise.

comment:3 in reply to:  2 Changed 5 years ago by gk

Replying to arma:
specifically trying to do it, is a bug. But clearly the Tor Browser people think otherwise.

They don't think otherwise necessarily. Maybe fixing an other bug this way was just waaaay cheaper? Anyway, feel free to open a ticket that would like to have a proper fix implemented.

comment:4 Changed 5 years ago by nickm

It seems like we need some decision-making here:

  • Option A: It's trivial to downgrade the warning. (But only some instances of it are instances we'd like to ignore.)
  • Option B: It's similarly pretty easy to make the ignorable instances distinguishable from the accidental instances (such as by for example by reinstating the old "noconnect" directive, or by using some kind of a socks extension, special username, or magic port). But in this case, a hostile program might be able to generate a request to localhost that Tor would close but not report. I'm not sure whether there's an attack there.
  • Option C: We could have a magic SOCKS username that means "Don't log a warning if this address is 127.0.0.1". We could let this randomly at startup, and have it be Yet Another Cookie. This would be a version of option B where a hostile program that didn't know the magic username couldn't suppress the warning. I'm not sure whether this is worthwhile.
  • Option D: TB could try to fix #10682 in a different way. I don't know how hard this is, but I suspect "at least somewhat".
  • Option E: Do nothing; annoying warnings are annoying.
  • Options F...Z: Something I'm not thinking of.

Right now, I'm thinking that A and E are possible for 0.2.5.x-final. Maaaaybe some version of B would also work out for 0.2.5, but maybe not. Option C might work out for 0.2.6 (if the complexity doesn't make us cringe), but it's a kludge and it's not for 0.2.5. I can't comment on the difficulty of option D.

comment:5 in reply to:  4 Changed 5 years ago by gk

Replying to nickm:

  • Option D: TB could try to fix #10682 in a different way. I don't know how hard this is, but I suspect "at least somewhat".

At least it needs a browser patch. But even if we fixed #10682 this way the problem would not go away due to the fix for #10419 (which kind of exposes our workaround in #10682 and causes the same log message for things unrelated to overriding the updateURL with https://127.0.0.1). This fix in turn was necessary due to Mozilla not having solved https://bugzilla.mozilla.org/show_bug.cgi?id=354493 yet (and a fix for this one is tricky). So I think option D is not as appealing as it might have looked in the first place.

comment:6 Changed 5 years ago by arma

Tor Browser 4.0 now emits these log messages to go with it:

1414363917043 addons.update-checker WARN HTTP Request failed for an unknown reason
1414363917045 addons.update-checker WARN HTTP Request failed for an unknown reason

where the word WARN means people tell us about it, e.g.
https://blog.torproject.org/blog/tor-browser-40-released#comment-77518

comment:7 Changed 4 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

If this is a high priority for TBB and there is a good design with an easy impl, maybe it can squeeze into 0.2.6. Otherwise, it's 0.2.7.

comment:8 Changed 4 years ago by gk

Pearl Crescent has found a pretty clever solution to our problem in comment:13:ticket:16200. We are taking this road (I've opened #16427 and #16428 for it).

Last edited 4 years ago by gk (previous) (diff)

comment:9 Changed 4 years ago by nickm

Clever indeed! Does this mean we can close this ticket for Tor?

comment:10 Changed 4 years ago by gk

Yes, I am fine with that unless you see a non-Tor Browser related reason to keep it open (I think Tor Messenger did the same https:// trick and might now need to switch as well. I'll check that).

comment:11 Changed 3 years ago by teor

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

Milestone renamed

comment:12 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:13 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:14 in reply to:  10 Changed 2 years ago by nickm

Resolution: worksforme
Severity: Normal
Status: newclosed

Replying to gk:

Yes, I am fine with that unless you see a non-Tor Browser related reason to keep it open (I think Tor Messenger did the same https:// trick and might now need to switch as well. I'll check that).

Note: See TracTickets for help on using tickets.