Opened 10 years ago

Closed 9 years ago

Last modified 7 years ago

#1320 closed defect (invalid)

Tor/Vidalia report wrong hostname on same IP

Reported by: downie Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.1.24
Severity: Keywords:
Cc: downie Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

When accessing multiple sites on the same IP using Tor,
Vidalia reports the wrong website name as being accessed:
the incorrect name is a site on the same IP accessed previously.
The problem clears if 'Use a new Identity' is clicked,
but not in the normal course of relay paths being changed
as they fail or become stale.
This may have something to do with opening aconnection to
one site before a previous one has closed; or using Wget;
or deleting the Tor log.
It might possibly be a Vidalia bug.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (12)

comment:1 Changed 10 years ago by downie

Confirmed on Tor 0.2.1.25 running as a relay also.
OSX10.3.9
Sequence of actions: Sites A&B are on the same IP.

Start Tor and allow to reach 100%
Blank the Tor log.
Start Vidalia and connect it to Tor.
In the browser, access Site A - Vidalia Network Map says Site A

" " access site B - Vidalia Network Map says Site B
" " access site A - Vidalia Network Map says Site B!

the Network Map continues to say Site B whether Site A or Site B is being accessed.

In the browser, access unrelated Site C - Vidalia Network Map says Site C

" " access site A - Vidalia Network Map says Site B

So nothing to do with Wget certainly.

comment:2 Changed 10 years ago by downie

Someone please change Operating System to OSX until other OS have been checked.

comment:3 Changed 9 years ago by mwenge

This is a Vidalia bug. STREAM STATUS and the like report the correct host name.

comment:4 Changed 9 years ago by mwenge

Suspect it's this:

/ Adds <b>stream</b> to its associated circuit on the list of all circuits. */
void
NetViewer::addStream(const Stream &stream)
{

QString target = stream.targetAddress();
QHostAddress addr(target);


/* If the stream's target has an IP address instead of a host name,

  • check our cache for an existing reverse address mapping. */

if (!addr.isNull() && _addressMap.isMapped(target)) {

/* Replace the IP address in the stream event with the original

  • hostname */

ui.treeCircuitList->addStream(

Stream(stream.id(), stream.status(), stream.circuitId(),

_addressMap.mappedTo(target), stream.targetPort()));

} else {

ui.treeCircuitList->addStream(stream);

}

}

comment:5 Changed 9 years ago by nickm

Description: modified (diff)

If so, this should get moved over to the Vidalia bugtracker. Could you do that?

comment:6 Changed 9 years ago by edmanm

If a stream event includes only an IP address, Vidalia will use the address-mappings command to try to find the previous host name for that IP address. If two hostnames map to the same IP address, Vidalia has no way of knowing which one is correct given only the IP address. One alternative is to simply display the IP address for such cases, but then user would probably complaint that they're seeing an IP address rather than a (possibly incorrect) hostname.

comment:7 in reply to:  6 ; Changed 9 years ago by mwenge

Replying to edmanm:

If a stream event includes only an IP address, Vidalia will use the address-mappings command to try to find the previous host name for that IP address. If two hostnames map to the same IP address, Vidalia has no way of knowing which one is correct given only the IP address. One alternative is to simply display the IP address for such cases, but then user would probably complaint that they're seeing an IP address rather than a (possibly incorrect) hostname.

I think the problem is that a new Stream object is instantiated from each event and the target from that event is always used to update the stream item. So Vidalia doesn't remember that in the first event for the stream it got the correct hostname for the stream from Tor, i.e.:

650 STREAM 255 NEW 0 metrics.torproject.org:80 SOURCE_ADDR=127.0.0.1:38193 PURPOSE=USER

So when it later gets an event:

650 STREAM 256 SENTCONNECT 54 38.229.70.37:80

and reverse maps the IP it gets the first hit in its cache for that address rather than the hostname actually associated with stream.

Should vidalia only update the target in the StreamItem if it does not already have an opinion on the target's hostname (e.g. through maintaing a map of streams/hostnames)?

comment:8 in reply to:  7 Changed 9 years ago by mwenge

Replying to mwenge:

650 STREAM 256 SENTCONNECT 54 38.229.70.37:80

This was a typo, should have read:

650 STREAM 255 SENTCONNECT 54 38.229.70.37:80

The full event list for the case described by this bug is:

650 STREAM 254 NEW 0 yatei.torproject.org:80 SOURCE_ADDR=127.0.0.1:38191 PURPOSE=USER
650 STREAM 254 REMAP 0 38.229.70.37:80 SOURCE=CACHE
650 STREAM 254 SENTCONNECT 54 38.229.70.37:80
650 STREAM 254 REMAP 54 38.229.70.37:80 SOURCE=EXIT
650 STREAM 254 SUCCEEDED 54 38.229.70.37:80

650 STREAM 255 NEW 0 metrics.torproject.org:80 SOURCE_ADDR=127.0.0.1:38193 PURPOSE=USER
650 STREAM 255 REMAP 0 38.229.70.37:80 SOURCE=CACHE
650 STREAM 255 SENTCONNECT 54 38.229.70.37:80
650 STREAM 255 REMAP 54 38.229.70.37:80 SOURCE=EXIT
650 STREAM 255 SUCCEEDED 54 38.229.70.37:80

comment:9 Changed 9 years ago by edmanm

Sounds good. Feel free to close this ticket and reopen on Vidalia's bug tracker so I don't forget about it.

comment:10 Changed 9 years ago by edmanm

I moved this to ticket 608 in Vidalia's bug tracker and committed the fix linked in that ticket.

comment:11 Changed 9 years ago by nickm

Resolution: Noneinvalid
Status: newclosed

Closing this ticket; see the one on vidalia's trac.

comment:12 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.