Re: GSoC Introduction! (TorButton)
Hi Jim, --- On Sun, 5/31/09, Jim McClanahan wrote: From: Jim McClanahan Subject: Re: GSoC Introduction! (TorButton) To: or-talk@freehaven.net Date: Sunday, May 31, 2009, 11:08 AM Chris Humphry wrote: > > Hi Kroy! > > > > I > informened Tor team how RefContorl will spoof the root of the site you > are visiting as the referrer. I will also point out functionality Privoxy has as an option. When you come from another site, it spoofs the referrer as the root of the site being visited as indicated above. But as you move around within a site it reports the referrer accurately. Some sites require this for proper functioning. Thanks for the heads up. I use Polipo though. I don't want to be in the 'un-cool' anonymity set (just kidding), but I do not want to be in the smaller (I assume) Privoxy anonymity set. I have yet to have any issues with RefControl but I do like your desceiption about switching back to non-spoofing, smart.
Tor 0.2.1.15-rc is out
Tor 0.2.1.15-rc marks the second release candidate for the 0.2.1.x series. It fixes a major bug on fast exit relays, as well as a variety of more minor bugs. This is a release candidate! That means that we don't know of any remaining show-stopping bugs, and this will become the new stable if there are no problems. Please test it, and tell us about any problems that you find. https://www.torproject.org/download.html.en Changes in version 0.2.1.15-rc - 2009-05-25 o Major bugfixes (on 0.2.0.x): - Fix a timing-dependent, allocator-dependent, DNS-related crash bug that would occur on some exit nodes when DNS failures and timeouts occurred in certain patterns. Fix for bug 957. o Minor bugfixes (on 0.2.0.x): - Actually return -1 in the error case for read_bandwidth_usage(). Harmless bug, since we currently don't care about the return value anywhere. Bugfix on 0.2.0.9-alpha. - Provide a more useful log message if bug 977 (related to buffer freelists) ever reappears, and do not crash right away. - Fix an assertion failure on 64-bit platforms when we allocated memory right up to the end of a memarea, then realigned the memory one step beyond the end. Fixes a possible cause of bug 930. - Protect the count of open sockets with a mutex, so we can't corrupt it when two threads are closing or opening sockets at once. Fix for bug 939. Bugfix on 0.2.0.1-alpha. - Don't allow a bridge to publish its router descriptor to a non-bridge directory authority. Fixes part of bug 932. - When we change to or from being a bridge, reset our counts of client usage by country. Fixes bug 932. - Fix a bug that made stream bandwidth get misreported to the controller. - Stop using malloc_usable_size() to use more area than we had actually allocated: it was safe, but made valgrind really unhappy. - Fix a memory leak when v3 directory authorities load their keys and cert from disk. Bugfix on 0.2.0.1-alpha. o Minor bugfixes (on 0.2.1.x): - Fix use of freed memory when deciding to mark a non-addable descriptor as never-downloadable. Bugfix on 0.2.1.9-alpha. signature.asc Description: Digital signature
Re: Issue about selection of Tor relays when using the default torrc configuration
Thank you Roger. Sambuddho Roger Dingledine wrote: On Sun, May 31, 2009 at 02:59:01AM -0400, Sambuddho Chakravarty wrote: Thanks for you help. However , is there no way that I can cause tor client to reload a new set of entry guard nodes ? I have tried both NEWNYM and HUP signals through *nc* to communicate to tor controller . However , in both cases only a small set of (infact 3) entry guards are selected. Yes, that's a feature. Otherwise you'll open yourself up to a variety of attacks: https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#EntryGuards If you want to turn off that defense, set "UseEntryGuards 0" in your torrc. Or you can delete them from your $datadir/state file while Tor is off, but that's probably more likely to cause problems. Also , in continuation to my previous email , where can I download the torctl python libraries from ? You can get it from SVN: https://svn.torproject.org/svn/torctl/trunk/python/ Do I need the library or I can just make do by sending text command to the tor controller to play around and test with ? Playing around and testing with telnet or nc is a fine start. You only need the torctl library if you find that playing around by hand is insufficient for your needs. --Roger
Re: GSoC Introduction! (TorButton)
Chris Humphry wrote: > > Hi Kroy! > > > > I > informened Tor team how RefContorl will spoof the root of the site you > are visiting as the referrer. I will also point out functionality Privoxy has as an option. When you come from another site, it spoofs the referrer as the root of the site being visited as indicated above. But as you move around within a site it reports the referrer accurately. Some sites require this for proper functioning.
Re: Issue about selection of Tor relays when using the default torrc configuration
On Sun, May 31, 2009 at 02:59:01AM -0400, Sambuddho Chakravarty wrote: > Thanks for you help. However , is there no way that I can cause tor > client to reload a new set of entry guard nodes ? I have tried both > NEWNYM and HUP signals through *nc* to communicate to tor controller . > However , in both cases only a small set of (infact 3) entry guards are > selected. Yes, that's a feature. Otherwise you'll open yourself up to a variety of attacks: https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#EntryGuards If you want to turn off that defense, set "UseEntryGuards 0" in your torrc. Or you can delete them from your $datadir/state file while Tor is off, but that's probably more likely to cause problems. > Also , in continuation to my previous email , where can I download the > torctl python libraries from ? You can get it from SVN: https://svn.torproject.org/svn/torctl/trunk/python/ > Do I need the library or I can just make > do by sending text command to the tor controller to play around and test > with ? Playing around and testing with telnet or nc is a fine start. You only need the torctl library if you find that playing around by hand is insufficient for your needs. --Roger
Re: A tor error message prior to crash
Nick Mathewson schrieb: > On Mon, May 11, 2009 at 01:33:41PM -0400, Praedor Atrebates wrote: >> I finally picked up a log entry that is associated with vidalia/tor failing >> at >> random moments: >> >> May 11 13:30:49.177 [err] Error from libevent: event_queue_insert: >> 0xa2e6d68(fd 33) already on queue 2 >> >> What does this mean and how do I fix it? >> > > I have a patch in the repository that might fix it. If you can build > from source, please try out the latest maint-0.2.1 branch to see > whether the bug is gone for you. > > (There might be some warning messages in the log that start with > "Bug". If there are, please let me know.) Nick's patch really fixed the problem. My exit node isn't crashing any longer. Current uptime is 12 days. Olaf
Re: Issue about selection of Tor relays when using the default torrc configuration
Also , in continuation to my previous email , where can I download the torctl python libraries from ? Do I need the library or I can just make do by sending text command to the tor controller to play around and test with ? Thanks Sambuddho Scott Bennett wrote: On Fri, 29 May 2009 17:17:33 -0400 Sambuddho Chakravarty wrote: I am using the default torrc without giving any information on what relays to select for circuit creation. But apparently tor (from what I experience) Tor doesn't change the relays selected in a long time. So each time (over a period of 2 - 3 hours) I start the tor client it seems to be selecting the same relays . Is there a way I can ensure different relay selection over each time I start the tor client. You may be observing any of several things that lead you to believe what you wrote. For example, The torrc distributed with the package and most likely the internal default in the code say that three entry guards are to be used. Entry guard connections can be held open for a very long time because all of your client traffic gets funneled through them. The default route length is 3, so each circuit needs at least two more nodes beyond the entry guard. We are fortunate that the tor network includes several dozen nodes that handle very large volumes of data at high rates. Those nodes, therefore, get chosen frequently during circuit route selection, so you may see these popping up over and over again, but regardless of how it seems in a Vidalia display, they are being used for new circuits each time. Also, many streams (i.e., TCP connections) may pass simultaneously or in succession through the same circuit. As long as a single stream is still present in a circuit, the circuit is considered active and will not be torn down, regardless of its age. The upshot of this is that if you have, say, a secure shell login session to your friendly UNIX/LINUX system somewhere and you stay logged in, the circuit that connection passes through will not normally be closed until you do logout. (Note that after a circuit has aged ten minutes, no *new* streams are to be assigned to it. New streams will be assigned to a new(er) circuit. tor's standard client behavior is to begin aging a circuit the first time it is used. It is important to remember this and to note that the first time a circuit is used could conceivably be quite a while after it is built because tor builds some circuits in anticipation of needing them. Such circuits may end up not being used, but if they aren't, then they will hang around anyway for an hour(?) or so before being torn down. If you use a tor controller, such as torctl or Vidalia, you can send a NEWNYM command to tor that will cause it to mark all aging circuits (i.e., those that have been or are being used at least once). Any circuits that are aging but have no streams in them (i.e., the circuits are not currently active) and get marked as "old" this way will automatically be torn down. Any that are currently active will still be marked "old", so that they can be torn down when they become inactive. When tor has no available circuits to assign a new stream to, it will begin building some new ones. I confess I don't recall offhand whether a NEWNYM or a SIGHUP will by itself cause tor to build circuits preemptively (i.e., in anticipation of need for them). The last time I used a version of Vidalia, it had some cute button to click on that said, "New Identity" or some such thing. 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 * **
