Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5840 closed defect (not a bug)

tor disregards MapAddress .exit mapping

Reported by: mr-4 Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version: Tor: 0.2.3.14-alpha
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In my torrc file I have the following statements:
AllowDotExit 1
[...]
MapAddress imap.google.com imap.google.com.<exit_node_hash>.exit

This is to prevent the stupid google blocks when my account appears to be accessed "from different location".

This, however, seems to be completely disregarded by tor as I have at least 4 different IP addresses - all from different countries - in my google imap logs (visible when I log in using the web interface and click on "details" on my "Last account activity" status at the bottom).

Before you ask - these were my sessions and not somebody else trying to hack my account as I know the times where I accessed it.

This is *extremely* annoying as when my MapAddress mapping is completely disregarded by tor, google blocks my account as it treats access to it "from different location" as suspicious, so every time that happens I have to manually log in via the web interface and reset that account and change my password.

Child Tickets

Change History (10)

comment:1 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:2 Changed 7 years ago by nickm

Priority: normalmajor

comment:3 Changed 7 years ago by mr-4

While on the subject of MapAddress functionality, I have a suggestion: As far as I know, MapAddress deals with exact domain names only (in other words "MapAddress *.google.com *.google.com.<exit_node_hash>.exit" won't work).

It would be nice if I could have the ability to use wildcards at the very least, but regex ideally, as part of the MapAddress mapping.

One simple case scenario - suppose I want to map every access to, say, domain.com, using a particular exit node. On the provider.com's side, they may use load-balancing and redirect all my requests to different servers - nodeXXX.provider.com. In such a case, I have to guess in advance what server (or servers) I may be redirected to and then define MapAddress for each possible combination of these.

This is very inconvenient and cumbersome, not to mention that as soon as new "node" is registered, my MapAddress is not going to function as intended.

comment:4 Changed 7 years ago by nickm

Hi!
A) Please use one ticket per issue; that way, we can track each issue separately.
B) The wildcard matching feature you want was implemented back in Tor 0.2.3.9-alpha. It was ticket #933.

comment:5 in reply to:  4 Changed 7 years ago by mr-4

Replying to nickm:

A) Please use one ticket per issue; that way, we can track each issue separately.

Noted.

B) The wildcard matching feature you want was implemented back in Tor 0.2.3.9-alpha. It was ticket #933.

Apologies Nick, I did not know that (note to self to read tor ChangeLog more thoroughly), thanks for pointing it out.

comment:6 Changed 7 years ago by mr-4

::ashamed:: OK, I hold my hands up...

In my initial bug submission (above) I used "imap.google.com" as an example as this is what I also used in my MapAddress statement in torrc (the intention was to force all connections to the google imap server to be made through a particular exit node).

As it turns out, there is NO such thing as "imap.google.com"! The correct mapping should have been "imap.googlemail.com"!

I discovered this by accident when I tried to specify "imap.google.com.<exit_node_hash>.exit" in my email program to force the use of that particular exit node and not use the MapAddress mapping in order to see whether that solves my problem (I use tor as my DNS resolution service as well). When I did that, I've got an error from tor that "imap.google.com" cannot be resolved. Doh!

In all fairness, tor should have warned me that there is no such thing as "imap.google.com" when I specified that in my MapAddress statement and not silently ignore it (I admit that it was my fault for not specifying the right address in the first place, but still...).

I have corrected my mistake and will monitor whether MapAddress is honoured by tor and will report here if I find that is not the case. Once again, apologies for this!

comment:7 Changed 7 years ago by mr-4

OK, having amended my settings and used MapAddress for the past 2 days everything works as it should - redirection is done via the node I specified at all times.

I don't see any reason why this "bug" should remain open, unless Tor devs need to use it as a reference to add a warning in case invalid address has been specified in torrc (like the "imap.google.com" I've had)...

comment:8 Changed 7 years ago by nickm

Resolution: not a bug
Status: newclosed

Okay, closing this bug. Thanks for tracking down the issues!

(It's hard to add a warning for an nonexistent address like that, since we don't try to actually resolve any of the addresses when we're parsing the configuration.)

comment:9 Changed 7 years ago by nickm

Keywords: tor-client added

comment:10 Changed 7 years ago by nickm

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