Opened 8 years ago

Last modified 2 years ago

#4378 new defect

Tor guesses IP address when Address is 127.0.0.1

Reported by: ln5 Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Minor Keywords: tor-relay usability logging needs-investigation
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:

Description

Setting Address to 127.0.0.1 should make Tor not guess IP address. Tor dislikes 127.0.0.1 (INFO level log) for not being public:

[info] resolve_my_address(): Address '127.0.0.1' resolves to private IP address '127.0.0.1'. Tor servers that use the default DirServers must have public IP addresses.

Then it guesses:

[notice] Guessed our IP address as [scrubbed by linus] (source: 213.115.239.118).

  1. it shouldn't guess
  2. the warning should not be at INFO

Thanks weasel and armadev.

Child Tickets

Change History (19)

comment:1 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:2 Changed 8 years ago by nickm

  1. it shouldn't guess

If I'm reading the code right, "last_guessed_ip" is what we update there. We don't actually use it unless we decide to call router_guess_address_from_dir_headers, which we only do if resolve_my_address() fails entirely. Perhaps the right behavior, then, is that we shouldn't in this case call it a failure from resolve_my_address(), but rather simply warn, and refuse to publish? Insight wanted.

  1. the warning should not be at INFO

Agreed. It looks like that warning is controlled by the "warn_severity" flag of resolve_my_address(), which is only passed as INFO from router.c, in router_pick_published_address, check_descriptor_ipaddress_changed, and router_new_address_suggestion.

The way that it's supposed to work is that when resolve_my_address is called earlier (in config.c, I think) it's supposed to give its warnings as warnings then, and only subsequently should it complain at INFO.

Is it workign right? Did it do the earlier warnings at WARN?

comment:3 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

Deferring to 0.2.4.x; we need to talk more about what is actually going on and what the problem is.

comment:4 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:5 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:6 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:7 Changed 6 years ago by nickm

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

comment:8 Changed 5 years ago by nickm

Milestone: Tor: 0.2.???Tor: 0.2.7.x-final

These may be worth looking at for 0.2.7.

comment:9 Changed 5 years ago by nickm

Status: newassigned

comment:10 Changed 5 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:11 Changed 5 years ago by nickm

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

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:12 Changed 3 years ago by teor

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

Milestone renamed

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

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:16 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:17 Changed 2 years ago by nickm

Keywords: 027-triaged-1-out removed

comment:18 Changed 2 years ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

comment:19 Changed 2 years ago by nickm

Keywords: usability logging needs-investigation added
Points: 2
Severity: Minor
Note: See TracTickets for help on using tickets.