[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Library Defeats Tor Followup Addl Info



     On Sat, 13 Oct 2007 17:30:30 -0700 mark485anderson@xxxxxx wrote:

>This group has not changed. I give information in good faith and then

     Well, at least *you* haven't changed:  you're still top-posting.

>nobody replies. Course in the beginning of this thread,
>watsonbladd@xxxxxxxxx and Scott Bennett" <bennett@xxxxxxxxxx were
>replying with uninformative answers, but then as soon as I give further

     Actually, we were responding primarily with questions, not answers
at all, in many cases in an attempt to get you to post the information
with which you should have begun the thread.  I continue that effort
below.

>information, my posts are ignored. Incidently, Scott Bennett care to
>tell me why posts to your address bounce (i dont have time for finding
>out now). This is why more people don't use Tor, it seems to be only the

     I'm not clairvoyant, so I can't read the error messages you got from
here unless you post them.
     That having been said, however, I will mention that the administrator
of this system graciously blocks most source addresses of massmail when
a) there is no functioning abuse or postmaster address at that source,
b) there is no valid MX RR for the source, or c) the source comes from
a part of the world that is currently a disaster area of massmail sources
for which reporting the massmail is nearly always a completely wasted
effort.  Attempts to send mail to users on this system from addresses so
blocked normally result in some sort of error message being returned to
the sender that provides a clue as to why the mail is being rejected.

>domain of an elite group, who could care less if others join in.
>
     At least some of the people on this list do not live according to
the same schedule you live by and may have different obligations upon
their time than you have.
>
>On Sun, 07 Oct 2007 14:12:57 -0700, mark485anderson@xxxxxx said:
>> Ok, promised I would report back. My testing time has been limited so
>> this information is not complete, but will help I think. Here is what I
>> have found:
>> 
>> 1) you cannot connect to any tor server until you connect first to a
>> library server, and accept the library TOS, else you get repeated error
>> messages from each tor server "will try again later..."

     Yes, that is typical.  So either wait to start tor until after you do
that, or ignore the messages that are issued up until your session is
authenticated via their web server.  I generally do the latter in those
situations.
>> 
>> 2) Once you have accepted the TOS on their web page through a direct
>> browser connection, then all DNS requests are made through that library
>> server, subjecting you to profiling and tracking.

     The private network address of the ISP's name server is usually used
as a forwarder address, and that address gets passed to your computer in
the DHCP lease.  I've forgotten exactly how to go about setting a permanent
address under Windows XP, but it should be fairly easy to do.  If you haven't
figured it out by the next time I shut down my FreeBSD system and boot WinXP,
I'll dig around in it to see what has to be changed.
>> 
>> Now the more interesting part:
>> 
>> You can defeat #2 by not allowing dns/p53 requests in you firewall
>> ruleset-that way all dns requests will then go directly to tor servers
>> (as far as my fw logs seem to indicate). This slows down the web page
>> and other requests considerably. I will have to relookup how to fix
>> Microsuck OS to do it's dns lookups directly from the client as I recall
>> it does not do it simply by putting entries in the hosts file.

     The slowdown is most likely the wait for the six-second timeout (or
however long it may be these days) before trying the next name server in
the list.  So the trick to doing that is to find the way to restrict the
DHCP client's ability to change the name server list and to set the name
server list only to those addresses you have chosen.
     Do not assume, though, that bypassing their chosen name server means
that you are safe. In the U.S., for example, an unconstitional (which is
to say, "illegal under the Supreme Law of the Land") Act of Congress
requires ISPs to keep logs of all name server queries, as well as HTTP
requests, so they are likely to log all outbound port 53 traffic, regardless
of its destination.
     Also, the /WINDOWS/system32/drivers/etc/hosts file is not the location
you're looking for.  What you need to look for is the WinXP equivalent of
a UNIX /etc/resolv.conf file.  (I've forgotten where it is or even if it is
in only one place; a quick search of my WinXP system did not turn up a file
by that name, so I'll try looking into it a bit more after I get some sleep.
I've been up about 27 hours at the moment, and it's getting hard to focus
on the screen.:-)
>> 
>> Even if dns requests are made to the library machine, running a sniffer
>> seems to show that the TCP packets are still encrypted at the client
>> level. I have not had a chance to analyze the sniffer logs yet well yet,
>> but just watching the traffic shows encrypted TCP going to and from tor
>> servers, so that part is safe.
>> 
>> You must disable dns requests at the firewall to prevent leaking to the
>> library IP.

     Possibly.  However, if you can find the WinXP equivalent of
/etc/resolv.conf and force it to remain unchanged by your DHCP client,
then you should be able to avoid sending queries to the library's name
server(s).  And if your proxy server(s) can use SOCKS4a or SOCKS5 in
connecting to tor, then the query resolutions can be obtained via the
tor network itself.
>> 
>> Once you do that it appears (again, on the surface without too much
>> study) that your traffic, including dns requests is safe.

     {Already covered above.]
>> 
>> I will do more intensive analysis and testing as time and access to the
>> library connection permits.

     Looks good.
>> 
>> Any useful comments and feedback appreciated.
>> 
>> On Sat, 29 Sep 2007 13:58:37 -0700, mark485anderson@xxxxxx said:
>> > Give me a couple days and I will confirm and report back after running a
>> > sniffer.
>> > I don't use this library node often, so it will be a few days. Besides I
>> > do not have the
>> > firewall logs with me now, so don't want to misstate things until I am
>> > sure and have gathered as much information as I can.
>> > 
>> > 
>> > 
>> > 
>> > On Fri, 28 Sep 2007 23:57:17 -0500 (CDT), "Scott Bennett"
>> > <bennett@xxxxxxxxxx> said:
>> > >      On Fri, 28 Sep 2007 15:06:48 -0700 mark485anderson@xxxxxx wrote:
>> > > 
>> > > >On Fri, 28 Sep 2007 15:02:53 -0700, mark485anderson@xxxxxx said:
>> > > >> 
>> > > >> On Thu, 27 Sep 2007 21:20:42 -0500 (CDT), "Scott Bennett"
>> > > >> <bennett@xxxxxxxxxx> said:
>> > > >> >      On Thu, 27 Sep 2007 19:05:27 -0700 mark485anderson@xxxxxx wrote:
>> > > >> > 
>> > > >> > >On Thu, 27 Sep 2007 19:52:30 -0500 (CDT), "Scott Bennett"
>> > > >> > ><bennett@xxxxxxxxxx> said:
>> > > >> > >>      On Thu, 27 Sep 2007 20:35:58 -0400 Watson Ladd
>> > > >> > >>      <watsonbladd@xxxxxxxxx>
>> > > >> > >> wrote:
>> > > >> > >> >mark485anderson@xxxxxx wrote:
>> > > >> > >> >> Then after agreeing to the TOS, you are able to connect to tor servers,=
>> > > >> > >> >
>> > > >> > >> >> but all dns requests go through a library computer IP, such that they
>> > > >> > >> >> can see and record where you are going. I am not sure if they can see
>> > > >> > >> >> the TCP content, but the UDP (which I assume is the dns lookups are all=
>> > > 
>> > >      What does your firewall software or other tool at your disposal have
>> > >      to
>> > > say about the TCP packets from your browser?  Do they go to privoxy?  And
>> > > where does it say that packets from privoxy go?  To your tor client? 
>> > > Somewhere
>> > > else?

     The above questions are, I think, still waiting to be answered.
>> > > 
>> > > >> > >> >> being monitored and probably logged by the library server through which=
>> > > >> > >> >
>> > > >> > >> >> you are connected. Firewall logs clearly show the outgoing and incoming=
>> > > >> > >> >
>> > > >> > >> >> DNS packets to the library IP. Rest of connections to Tor servers in th=
>> > > >> > >> >e
>> > > >> > >> >> firewall log appear normal.
>> > > 
>> > >      Just to confirm:  your firewall log shows that the UDP packets in
>> > > question are destined to some IP address and port 53?
>> > > 
>> > > >> > >> >Make sure to run DNS queries over tor if anonymity is important.
>> > > >> > >> 
>> > > >> > >>      Absolutely.  Check your privoxy configuration file to make sure its
>> > > >> > >> first line is
>> > > >> > >> 
>> > > >> > >> forward-socks4a / localhost:9050 .
>> > > >> > >
>> > > >> > >already is
>> > > >> > >
>> > > >> >      Okay.  Good.
>> > > >> > >> 
>> > > >> > >> If you're using some other port than 9050, change that accordingly. 
>> > > >> > >> Other
>> > > >> > >> programs, e.g. PuTTY, will need to be configured, too, if you use them.
>> > > >> > >> In the case of PuTTY, each remote login site that you configure to be
>> > > >> > >> proxied through tor will need to be set to use socks5 and to do DNS name
>> > > >> > >> lookups at the proxy end (see "Proxy" under "Connection").
>> > > >> > >> 
>> > > >> > >> >>=20
>> > > >> > >> >> I have not run a sniffer yet on this, because my laptop is old and it
>> > > >> > >> >> might not be able to handle it. But tor anonymity is obviously shot whe=
>> > > 
>> > >      Your laptop, old though it may be, apparently has no trouble
>> > >      handling
>> > > wireless IP traffic, so I would bet that a sniffer storing, say, only UDP
>> > > packets to port 53 wouldn't overtax it.
>> > > >> > >> >n
>> > > >> > >> >> connecting to their wifi nodes. I believe I tried to block the DNS
>> > > >> > >> >> lookups to the Library IP with privoxy generic block rules and then I\
>> > > 
>> > >      Because I don't know how that works in privoxy, I'll ask, does your
>> > > firewall allow you to block outbound UDP packets to port 53?  If so, what
>> > > happens if you block them that way instead of via privoxy?
>> > > 
>> > > >> > >> >Using socks-4a should fix this.
>> > > >> > >
>> > > >> > >already set to sock 4a
>> > > >> > >
>> > > >> > >> 
>> > > >> > >>      Right.  Or socks5, though privoxy doesn't yet appear to support
>> > > >> > >>      that.
>> > > >> > >
>> > > >> > >did you just start using tor?
>> > > >> > >
>> > > >> >      About 2.5 years so far.
>> > > >> > >> 
>> > > >> > >> >> could not load any web pages, indicating again that the dns requests ar=
>> > > >> > >> >e
>> > > >> > >> >> first being routed to the library machine, where they are, of course,
>> > > >> > >> >> logged (and maybe sent off to the FBI, if your reading muslim materials=
>> > > >> > >> >,
>> > > >> > >> >> haha).
>> > > >> > >> >Now are these DNS requests for sites you are browsing? It sounds like
>> > > >> > 
>> > > >> >      I think the question posed here may reveal the answer.
>> > > >> 
>> > > >> Already answered that I think, the dns requests APPEAR to be made each
>> > > >> time a new url is looked up and not in looking up tor servers, but I
>> > > >> will only know for certain when I run the sniffer, if that is possible
>> > > >> on my laptop.
>> > > >> 
>> > >      As long as your wireless interface (and its driver) can run in
>> > > promiscuous mode, a sniffer ought to work okay.  Some systems may well be
>> > > able to trap outbound packets without an actual sniffer.  On most/all
>> > > UNIX
>> > > systems, you will need root privileges, too, to run tools like
>> > > tcpdump(1).
>> > > >> 
>> > > >> > 
>> > > >> > >> >that is the case, but I just want to make sure.
>> > > >> > >> 
>> > > >> > >>      Most public wireless locations use no encryption at all.  In these
>> > > >> > >> situations, things like tor and SSH are about the only significant
>> > > >> > >> privacy
>> > > >> > >> protection most users have.
>> > > >> > >
>> > > >> > >no problem with tor and other wifi connections, dns goes to tor, hence
>> > > >> > >my OP title LIBRARY DEFEATS TOR
>> > > >> > >Tentative Conclusion: Tor cannot be used with any confidence on
>> > > >> > >publically maintained machines, but there is no reference to this on the
>> > > >> > >tor website; nor any real illumination from this group, so far.  I
>> > > >> > >suppose now someone is going to tell me to disable javascript and
>> > > 
>> > >      Actually, that's probably worth a shot, given recent postings by the
>> > > author of Torbutton.  It's also trivial to do if you have the Quick Java
>> > > and/or NoScript plugins installed in firefox.
>> > > 
>> > > >> > >cookies, ;-) The encryption is SUPPOSED to occur at the client before it
>> > > 
>> > >      Cookies are just data.  They do not execute and therefore do not
>> > >      query
>> > > name servers, so I wouldn't think that would be worth bothering with.
>> > > 
>> > > >> > >even gets to any outside server, but obviously this is not happening as
>> > > >> > >the dns requests are being subverted. Perhaps the traffic is being
>> > > >> > >shuttled from the kernel OS to a library server. IOW tor should provide
>> > > >> > >the encryption necessary and no wifi encryption should be needed. I will
>> > > >> > >see if I can run a sniffer to find out exactly what's happening.
>> > > >> > >
>> > > >> >      Yes, and I think that may be why Watson asked the question I noted
>> > > >> > above.  Tor does its own name server queries for two purposes:  1) to
>> > > >> > provide exit service when running in server mode, 2) to look up addresses
>> > > >> > of other tor servers, regardless of mode.  These are normal operations
>> > > >> > and reveal only those activities.  When you are using it in a public
>> > > >> > location, I assume that it is running only as a client.  So that returns
>> > > >> > us to the question of exactly what kinds of addresses is tor looking up?
>> > > >> 
>> > > >> the laptop appears to be getting web site dns translations from a
>> > > >> library node rather than from tor, which allows tracking and profiling.
>> > > >> each time a new url is introduced I get a firewall dns request in the
>> > > >> log.
>> > > >> 
>> > > >> > Are they only the addresses of other tor servers?  Or do they also
>> > > >> > include the addresses of the web sites you're trying to reach?
>> > > >> >      Would you also please double check your browser configuration to
>> > > >> > make sure it is forwarding everything through privoxy?  If you're using
>> > > >> > a firefox plug-in module like Torbutton, switchproxy, or foxyproxy, have
>> > > >> > you accidentally disabled the proxy?
>> > > >> 
>> > > >> nope, don't use those, the browser is always set to go through privoxy.
>> > > >> will do some further testing and try to report back, but suprised not
>> > > >> more answers to this post. certainly others should have experienced this
>> > > >> problem.
>> > > >> 
>> > >      I guess that's the point:  we haven't experienced it, which is why
>> > > we've been asking questions to try to debug the problem.  Here are more.
>> > > 
>> > > 	1) Are you using a Microslop operating system?  If so, which?

     The second question, namely, *which* operating system, still awaits
an answer.

>> > > 	And if not, then which operating system and version are you using?
>> > > 
>> > > 	2) What is the firewall software that you have referred to several
>> > > 	times?

     This question still awaits an answer.
>> > > 
>> > > 	3) Which version of tor are you running?

     This question still awaits an answer, but may no longer be important.
>> > > 
>> > > 	4) Which browser and version are you using?

     I understand you to be using Firefox, though you have not specified
which version.
>> > > 
>> > > 	5) Under the assumption for the moment that your connection to the
>> > > 	wireless attach point gets configured by DHCP, which IP address(es)
>> > > 	got assigned to your system for its own address, for an IP gateway,
>> > > 	and for name server(s) to be used?
>> > > 
>> > >      I keep having the feeling that what you think is happening differs
>> > >      from
>> > > what is actually happening and/or something misconfigured somehow is
>> > > being
>> > > overlooked.  Please be patient with us.  We're trying to help figure out
>> > > what's going on, and you're the only one who can provide the
>> > > observational
>> > > data that might lead to a solution.  If it seems like we are just
>> > > grabbing
>> > > at straws so far, rest assured that we aren't there yet and can't get
>> > > there
>> > > until we first have at least the basic facts of the case established. 
>> > > ;-)
>> > >      Anyone else with pertinent questions, please join in!

     FWIW, soon I intend to stop replying to top-posted followups, at least
in most cases, except when I choose to delete all of the previously posted
material that the top-poster has clearly deemed irrelevant as context for
his/her followup.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************