Re: tor with OpenDNS as default DNS, using Firefox+FoxyProxy
- Original Message From: Tripple Moon tripple.m...@yahoo.com To: or-Talk Mailinglist or-t...@seul.org Sent: Monday, April 13, 2009 3:47:50 PM Subject: Re: tor with OpenDNS as default DNS, using Firefox+FoxyProxy Faking the address resolution does not alter the tracking abilities of web sites in the slightest. Well there you are dead wrong sorry to disagree here. Websites that track by IP-access are blocked this way. Ofcourse, i know there are plenty of other ways to track visitors, but IP-tracking is one that can be eliminated by _not_ accessing certain web servers at all in the 1st place... Are you saying that a solution to prevent websites from tracking their visitors is to have a third party block to have a content-based filter in case some of the blocked websites also happen to have IP tracking enabled (or are under some form of surveillance)? Is this really what you mean? How does this solution help when the traffic is coming from a Tor exit node and is reasonably well anonymized? My intentions were not to corrupt the tor service but to cleanup corruption of DNS servers used at certain locations in the world by authorities, and at the same time block some personally setup domains for my own LAN-access. Try to look at the big-picture what i want to accomplish as a whole, not just from tor's P.O.V. I want to circumvent the poluted DNS-service of my ISP/country and at same time block personally chosen domains. What do you think national authorities would say about someone in their country openly providing access to Internet content that they have blocked? Why would someone want to block content that has not already been blocked by the authorities? Can you share with us in what way Turkish DNS servers are corrupted? If you think that would be off-topic here, feel free to email me directly, as I would be personally very interested in specific examples of Turkish content filtering. Does OpenDNS allow blocking on a per-domain basis? All I could get from their website was their list of content categories from which an operator could choose. May I ask, which domains and content categories were you interested in blocking? Also, why impose the same blocking that you would use for your own LAN-access upon any Tor user that happens upon your exit node? Would it not be better to have any blocking in your exit policy so that users interested in content that you have blocked may instead route around you rather than see your personal message to them?
Re: exit counts by port number over 61 days
Hi Scott, Am 13.04.2009 um 19:00 schrieb Scott Bennett: 1) Why is the nicname/whois port the most heavily used? In fact, why is it getting much use at all? My guess: spammers and profilers, scanning for email adresses and other personal data. 2) Why are there so many exits to the standard socks port? It seems kind of strange to go all the way through the tor network fully encrypted, only to exit in the clear to a port somewhere else for re-encryption. Similarly, what about pptp? There are Trojans opening backdoors on that port. http://isc.sans.org/port.html?port=1080 4) Who still uses RFS? Didn't that die out a *long* time ago? (The rfs port had 70 exits.) I bet nobody. That's why there seems to be somebody using the port for something else. Sven smime.p7s Description: S/MIME cryptographic signature
Tor 0.2.1.14-rc is out
Tor 0.2.1.14-rc marks the first release candidate for the 0.2.1.x series. It begins fixing some major performance problems, and also finally addresses the bug that was causing relays on dynamic IP addresses to fall out of the directory. 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.14-rc - 2009-04-12 o Major features: - Clients replace entry guards that were chosen more than a few months ago. This change should significantly improve client performance, especially once more people upgrade, since relays that have been a guard for a long time are currently overloaded. o Major bugfixes (on 0.2.0): - Finally fix the bug where dynamic-IP relays disappear when their IP address changes: directory mirrors were mistakenly telling them their old address if they asked via begin_dir, so they never got an accurate answer about their new address, so they just vanished after a day. For belt-and-suspenders, relays that don't set Address in their config now avoid using begin_dir for all direct connections. Should fix bugs 827, 883, and 900. - Relays were falling out of the networkstatus consensus for part of a day if they changed their local config but the authorities discarded their new descriptor as not sufficiently different. Now directory authorities accept a descriptor as changed if bandwidthrate or bandwidthburst changed. Partial fix for bug 962; patch by Sebastian. - Avoid crashing in the presence of certain malformed descriptors. Found by lark, and by automated fuzzing. o Minor features: - When generating circuit events with verbose nicknames for controllers, try harder to look up nicknames for routers on a circuit. (Previously, we would look in the router descriptors we had for nicknames, but not in the consensus.) Partial fix for bug 941. - If the bridge config line doesn't specify a port, assume 443. This makes bridge lines a bit smaller and easier for users to understand. - Raise the minimum bandwidth to be a relay from 2 bytes to 20480 bytes (aka 20KB/s), to match our documentation. Also update directory authorities so they always assign the Fast flag to relays with 20KB/s of capacity. Now people running relays won't suddenly find themselves not seeing any use, if the network gets faster on average. - Update to the April 3 2009 ip-to-country file. o Minor bugfixes: - Avoid trying to print raw memory to the logs when we decide to give up on downloading a given relay descriptor. Bugfix on 0.2.1.9-alpha. - In tor-resolve, when the Tor client to use is specified by hostname:port, actually use the specified port rather than defaulting to 9050. Bugfix on 0.2.1.6-alpha. - Make directory usage recording work again. Bugfix on 0.2.1.6-alpha. - When starting with a cache over a few days old, do not leak memory for the obsolete router descriptors in it. Bugfix on 0.2.0.33. - Avoid double-free on list of successfully uploaded hidden service discriptors. Fix for bug 948. Bugfix on 0.2.1.6-alpha. - Change memarea_strndup() implementation to work even when duplicating a string at the end of a page. This bug was harmless for now, but could have meant crashes later. Fix by lark. Bugfix on 0.2.1.1-alpha. - Limit uploaded directory documents to be 16M rather than 500K. The directory authorities were refusing v3 consensus votes from other authorities, since the votes are now 504K. Fixes bug 959; bugfix on 0.0.2pre17 (where we raised it from 50K to 500K ;). - Directory authorities should never send a 503 busy response to requests for votes or keys. Bugfix on 0.2.0.8-alpha; exposed by bug 959. signature.asc Description: Digital signature
Re: exit counts by port number over 61 days
On Tue, 14 Apr 2009 15:06:22 +0200 Sven Anderson s...@anderson.de wrote: Am 13.04.2009 um 19:00 schrieb Scott Bennett: 1) Why is the nicname/whois port the most heavily used? In fact, why is it getting much use at all? My guess: spammers and profilers, scanning for email adresses and other personal data. That's kind of what I was thinking, too. However, I'm reluctant to close the port because it also be used legitimately. What do you think? 2) Why are there so many exits to the standard socks port? It seems kind of strange to go all the way through the tor network fully encrypted, only to exit in the clear to a port somewhere else for re-encryption. Similarly, what about pptp? There are Trojans opening backdoors on that port. http://isc.sans.org/port.html?port=1080 Hmm...very interesting. Maybe I should close that one. 4) Who still uses RFS? Didn't that die out a *long* time ago? (The rfs port had 70 exits.) I bet nobody. That's why there seems to be somebody using the port for something else. I have no idea what they are using it for. Does anyone still support RFS? A vendor perhaps? If it might be legitimate, I'll leave the port open. 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 * **
RE: Tor 0.2.1.14-rc is out
Thanks Roger, has the OSX version detection not been added to this branch? I had a crash after taking the 'NoKqueue' out. GD Date: Tue, 14 Apr 2009 10:27:46 -0400 From: a...@mit.edu To: or-talk@freehaven.net Subject: Tor 0.2.1.14-rc is out Tor 0.2.1.14-rc marks the first release candidate for the 0.2.1.x series. It begins fixing some major performance problems, and also finally addresses the bug that was causing relays on dynamic IP addresses to fall out of the directory. 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.14-rc - 2009-04-12 o Major features: - Clients replace entry guards that were chosen more than a few months ago. This change should significantly improve client performance, especially once more people upgrade, since relays that have been a guard for a long time are currently overloaded. o Major bugfixes (on 0.2.0): - Finally fix the bug where dynamic-IP relays disappear when their IP address changes: directory mirrors were mistakenly telling them their old address if they asked via begin_dir, so they never got an accurate answer about their new address, so they just vanished after a day. For belt-and-suspenders, relays that don't set Address in their config now avoid using begin_dir for all direct connections. Should fix bugs 827, 883, and 900. - Relays were falling out of the networkstatus consensus for part of a day if they changed their local config but the authorities discarded their new descriptor as not sufficiently different. Now directory authorities accept a descriptor as changed if bandwidthrate or bandwidthburst changed. Partial fix for bug 962; patch by Sebastian. - Avoid crashing in the presence of certain malformed descriptors. Found by lark, and by automated fuzzing. o Minor features: - When generating circuit events with verbose nicknames for controllers, try harder to look up nicknames for routers on a circuit. (Previously, we would look in the router descriptors we had for nicknames, but not in the consensus.) Partial fix for bug 941. - If the bridge config line doesn't specify a port, assume 443. This makes bridge lines a bit smaller and easier for users to understand. - Raise the minimum bandwidth to be a relay from 2 bytes to 20480 bytes (aka 20KB/s), to match our documentation. Also update directory authorities so they always assign the Fast flag to relays with 20KB/s of capacity. Now people running relays won't suddenly find themselves not seeing any use, if the network gets faster on average. - Update to the April 3 2009 ip-to-country file. o Minor bugfixes: - Avoid trying to print raw memory to the logs when we decide to give up on downloading a given relay descriptor. Bugfix on 0.2.1.9-alpha. - In tor-resolve, when the Tor client to use is specified by hostname:port, actually use the specified port rather than defaulting to 9050. Bugfix on 0.2.1.6-alpha. - Make directory usage recording work again. Bugfix on 0.2.1.6-alpha. - When starting with a cache over a few days old, do not leak memory for the obsolete router descriptors in it. Bugfix on 0.2.0.33. - Avoid double-free on list of successfully uploaded hidden service discriptors. Fix for bug 948. Bugfix on 0.2.1.6-alpha. - Change memarea_strndup() implementation to work even when duplicating a string at the end of a page. This bug was harmless for now, but could have meant crashes later. Fix by lark. Bugfix on 0.2.1.1-alpha. - Limit uploaded directory documents to be 16M rather than 500K. The directory authorities were refusing v3 consensus votes from other authorities, since the votes are now 504K. Fixes bug 959; bugfix on 0.0.2pre17 (where we raised it from 50K to 500K ;). - Directory authorities should never send a 503 busy response to requests for votes or keys. Bugfix on 0.2.0.8-alpha; exposed by bug 959. _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme
thoughts???
Just came across this: http://hosted.ap.org/dynamic/stories/T/TEC_PUNISHING_PROXIES?SITE=ILEDWSECTION=HOMETEMPLATE=DEFAULT Cheers, Harry
Re: thoughts???
On Tue, 14 Apr 2009 21:17:19 -0400 Harry Hoffman hhoff...@ip-solutions.net wrote: Just came across this: http://hosted.ap.org/dynamic/stories/T/TEC_PUNISHING_PROXIES?SITE=ILEDWSECTION=HOMETEMPLATE=DEFAULT From the March 2009 Progress Report, https://blog.torproject.org/blog/march-2009-progress-report On March 17, Roger attended a hearing at the US Sentencing Commission, where Seth Schoen from EFF was testifying in opposition to a new if you use a proxy when committing a crime, it's a sophisticated crime so you get more jail-time clause they were considering. It turned out one of the commissioners is an avid Tor user, so they were sympathetic to his testimony. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identica/Twitter: torproject
