[tor-bugs] #933 [Tor Client]: MapAddress for domains?

[Tor Bug Tracker & Wiki]

#933: MapAddress for domains?
--------------------------+-------------------------------------------------
  Reporter:  Aleph0       |       Owner:  mwenge      
      Type:  enhancement  |      Status:  needs_review
  Priority:  minor        |   Milestone:  post 0.2.1.x
 Component:  Tor Client   |     Version:  0.2.0.33    
Resolution:  None         |    Keywords:              
    Parent:               |  
--------------------------+-------------------------------------------------

Old description:

> Would it be non-trivial to have the MapAddress option behave like
> TrackHostExits?  That is, if an entry is like
> MapAddress .rapidshare.com .rapidshare.com.exitpoint.exit
> have it applied to rs1xx.rapidshare.com, rs223dt.rapidshare.com,
> rs28tl2.rapidshare.com...
>
> I already have such a line in my TORRC file; on start Tor doesn't
> complain, but apparently that line doesn't have any
> effect.
>
> My goal is to have all connections to rapidshare.com exit through the
> same exit point (that I've already defined with
> a separate MapAddress line for rapidshare.com), regardless if I'm
> redirected.
>
> The alternative would be to add 5000-odd MapAddress lines specifying
> every possible hostname given Rapidshare's
> current naming convention (rs[0-9]+[a-z]+[1-9]?.rapidshare.com) , but I
> don't know how Tor would handle such a big
> config file; my connections drop (flaky company proxy) often enough
> already...
>
> I already have TrackHostExits enabled for both rapidshare.com and
> .rapidshare.com, so when rapidshare.com redirects
> me to whatever.rapidshare.com Tor will reuse the existing circuit.
>
> If the connection drops halfway, my download manager will remember having
> been redirected and will retry on
> whatever.rapidshare.com. However, if it takes more than
> TrackHostExitsExpire seconds, Tor will assign this stream to
> a new circuit with a different exit point (and Rapidshare will claim I've
> shared my account and lock it... T_T ).
>
> Thanks for your consideration.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 Would it be non-trivial to have the MapAddress option behave like
 TrackHostExits?  That is, if an entry is like
 MapAddress .rapidshare.com .rapidshare.com.exitpoint.exit
 have it applied to rs1xx.rapidshare.com, rs223dt.rapidshare.com,
 rs28tl2.rapidshare.com...

 I already have such a line in my TORRC file; on start Tor doesn't
 complain, but apparently that line doesn't have any
 effect.

 My goal is to have all connections to rapidshare.com exit through the same
 exit point (that I've already defined with
 a separate MapAddress line for rapidshare.com), regardless if I'm
 redirected.

 The alternative would be to add 5000-odd MapAddress lines specifying every
 possible hostname given Rapidshare's
 current naming convention (rs[0-9]+[a-z]+[1-9]?.rapidshare.com) , but I
 don't know how Tor would handle such a big
 config file; my connections drop (flaky company proxy) often enough
 already...

 I already have TrackHostExits enabled for both rapidshare.com and
 .rapidshare.com, so when rapidshare.com redirects
 me to whatever.rapidshare.com Tor will reuse the existing circuit.

 If the connection drops halfway, my download manager will remember having
 been redirected and will retry on
 whatever.rapidshare.com. However, if it takes more than
 TrackHostExitsExpire seconds, Tor will assign this stream to
 a new circuit with a different exit point (and Rapidshare will claim I've
 shared my account and lock it... T_T ).

 Thanks for your consideration.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment(by nickm):

 Looks neat!  Will we ever want to match anything in a form other than
 "Replace a suffix starting with a dot with this other suffix starting with
 a dot?"  I don't think so.

 The doxygen comment on addressmap_match_superdomains() doesn't actually
 say what it does with the match if it finds one.  It should take a const
 char *, not a char *.  Also, it should probably return 0 rather than 1.

 The check for ".exit" in addressmap_rewrite seems off.  There is no real
 reason to disallow "MapAddress .com .com.big-web-cache.com", even if "big-
 web-cache.com" doesn't end in exit.  Also, Why not allow "MapAddress .
 .everythinggoesoverthis.exit" ?

 IOW, I am proposing that the option syntaxes should be more like:

 MapAddress a.b.c   d.e.f  # This is what we have now
 MapAddress .a.b.c  d.e.f  # Replaces any address ending with .a.b.c with
 d.e.f
 MapAddress .a.b.c .d.e.f  # Replaces the .a.b.c at the end of any addr
 with .d.e.f

 So in the first case, "x.a.b.c" is unaffected, in the second case
 "x.a.b.c" turns into "d.e.f", and in the third case "x.a.b.c" turns into
 "x.d.e.f".  No special handling for .exit is needed.

 Parenthetically, do you think this "prefix dot" business is too subtle?
 Maybe the syntax should be "*.a.b.c" instead of ".a.b.c".  Do you think
 that would confuse people less?

 Throughout the code, it seems fragile to have the strings in
 addressmap_entry_t have a special meaning when the key/value starts with
 ".".  Maybe it would be better to strip the "." when generating them and
 instead have a flag field added to addressmap_entry_t to indicate whether
 it should be a suffix match or an exact match?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/933#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online