Re: Email sent through Tor, Problem
If you use the most recent torbutton, it should block dangerous scripts. It can be found here: https://torbutton.torproject.org/dev/torbutton-current-alpha.xpi Current version is 1.1.9.1 You can instead use the firefox addon noscript which blocks all scripts instead, together with the old torbutton 1.0.4.01 Either way is good. But if you use noscript, don't allow scripts on web pages if you suspect that they register your IP with a script or applet. Faqeer ALI skrev: Thanks for your cooperation. One more thing please tell what scripts to block while using hotmail.. yeah i have also checked the email and it works fine Regards FQ _ Peek-a-boo FREE Tricks Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us
Re: Email sent through Tor, Problem
Hello FQ, These below are NOT the SMTP hops your email followed. These are IP hops, between your PC and the mail server of your friend in China. What is sure is that this information was not retrieved from the email you have sent directly, since no mail client or SMTP server would put the whole traceroute in the mail! Your mail didn't even follow this path, but the following: - your PC - lots of IP hops (one TPC connection) to the first Tor node ... - lots of IP hops (one TPC connection) to the Tor exit node - lots of IP hops (one TPC connection) to the Hotmail HTTP server Till now you had your data sent through HTTP Now comes the SMTP part - Hotmail HTTP server putting your mail in a database - I suppose another server sending out you email to the mail server of you friends mailbox (lots of IP hops again) ... - your friend viewing/downloading the mail through SSH / HTTP / POP3 / IMAP (some IP hops again) Of all this, in a mail, you have something like the following: Received: from moria.seul.org (moria.csail.mit.edu [128.31.0.34]) by mail0.unitn.it (Symantec Mail Security) with ESMTP id D366AD2DA7 for [EMAIL PROTECTED]; Wed, 31 Oct 2007 04:28:42 +0100 (CET) Received: by moria.seul.org (Postfix) id 3AC21140F3A7; Tue, 30 Oct 2007 23:28:40 -0400 (EDT) Delivered-To: [EMAIL PROTECTED] Received: by moria.seul.org (Postfix, from userid 65534) id 3519A140F3F5; Tue, 30 Oct 2007 23:28:40 -0400 (EDT) X-Original-To: or-talk@freehaven.net Delivered-To: [EMAIL PROTECTED] Received: from bay0-omc1-s14.bay0.hotmail.com (bay0-omc1-s14.bay0.hotmail.com [65.54.246.86]) by moria.seul.org (Postfix) with ESMTP id DF518140F3A7 for or-talk@freehaven.net; Tue, 30 Oct 2007 23:28:39 -0400 (EDT) Received: from BAY116-W7 ([64.4.38.107]) by bay0-omc1-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 20:28:38 -0700 Message-ID: [EMAIL PROTECTED] X-Originating-IP: [58.65.160.140] From: Faqeer ALI [EMAIL PROTECTED] If you have not used Tor, your IP appears in one of the last lines, as it is directly seen at the TCP endpoint of the HTTP server @ hotmail. If you use Tor, but there is some JavaScript sending your IP as data, and this is somehow not filtered, your IP could still appear but not the traceroot! So, the question is, what do you mean by i have traced the first ip? Regards, Csaba Faqeer ALI wrote: Yeah i am pretty much sure, because i have traced the first ip ie my isp's. it gives some information like this. 1 10.0.0.138 2. PAKISTAN -- MY IP. 3. PAKISTAN 4,202.125.154.129 Islamabad, Pakistan 5.202.125.159.209 Pakistan 6.202.125.159.20Pakistan 7.202.125.128.161 Pakistan 8.63.218.1.193 Herndor, USA 9.63.218.61.190 Herndor, USA 10202.97.60.165 China 11. 202.97.43.174 China 12. 202.97.43.171 China 13. 202.97.68.80 China 14. 125.123.1.242 China 15. 125.123.1.158 China 17. 125.123.1.138 China End 125.123.40.183China Is there any trick to hide the header information while sending email through hotmail. Any suggestion? Regards FQ Date: Tue, 30 Oct 2007 19:39:49 -0400 From: [EMAIL PROTECTED] To: or-talk@freehaven.net Subject: Re: Email sent through Tor, Problem On Tue, Oct 30, 2007 at 04:22:38PM +, [EMAIL PROTECTED] wrote 1.8K bytes in 37 lines about: : : I have sent an email through web interface from hotmail adress to another hotmail adress. : The reciver has used the following sofware http://www.visualware.com/index.html; and got the details of the routes and hopes that the email had followed. Are you sure the receiver traced it back to your internet connection and not the tor exit server? EmailtrackerPro appears to just parse the mail headers and map whois data of the hosts in the headers. It then draws pretty lines between everything. As long as Hotmail is exposing your real IP, this will continue to work. Can anyone else with a hotmail account verify that hotmail is indeed getting the real IP for header insertion? -- Andrew _ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline
some civically irresponsible exits?
The documentation that comes with tor rather strongly suggests that exit servers should have exit policies rejecting the SMTP port (25). The tor sample torrc includes this rejection as well. This rejection of exits to port 25 would seem to be a Very Good Thing (tm) in light of the rapidly growing waste of Internet bandwidth in the form of massmail. Nevertheless, I decided a few minutes ago to take a peek at reality by playing with the exitlist python script in tor-0.2.0.9-alpha/contrib. Using one of the IP addresses for the system on which I get most of my email, I get: Script started on Wed Oct 31 03:27:42 2007 hellas # cat cached-descriptors*|exitlist 131.156.58.41:25|sort -n -t \. 58.110.205.100 64.53.198.249 67.18.176.110 69.180.229.28 70.254.240.206 70.68.52.41 72.15.233.132 74.193.218.181 76.177.54.127 76.224.88.156 76.237.99.108 77.2.140.188 78.29.132.53 78.56.68.25 80.233.200.118 81.168.161.71 81.235.202.179 83.246.120.22 85.16.220.225 85.178.35.255 85.182.9.13 85.243.118.88 85.25.20.143 89.110.156.22 89.179.2.20 116.0.103.103 194.1.151.81 204.111.222.56 206.116.78.21 209.126.229.83 209.41.143.102 212.149.225.3 hellas # exit exit Script done on Wed Oct 31 03:31:20 2007 If any of the operators of tor exit servers at IP addresses in the above list are subscribed to the or-talk list, I would be very interested to know your reason(s) for providing exit service to massmailers. It should be noted that such practices tend to make system administrators who might otherwise be sympathetic to tor users into avowed enemies of the tor network. 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: Email sent through Tor, Problem
On Wed, Oct 31, 2007 at 04:58:20AM +, [EMAIL PROTECTED] wrote 4.3K bytes in 73 lines about: : : i have read the instructions of tor installation. I don't know what changed on your end during this thread, but the inserted hotmail header is X-Originating-IP: [140.113.158.9] which was an exit node. -- Andrew
Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
an insecure configuration file. Both Windows and Mac OS X versions
are affected. The installed 'config.txt' file ('config' on Mac OS X)
had the following option values set to 1:
- enable-remote-toggle
- enable-edit-actions
Additionally, on Windows the following option was set to 1:
- enable-remote-http-toggle
Malicious sites (or malicious exit nodes) could include active content
(e.g., JavaScript, Java, Flash) that caused the web browser to:
- make requests through the proxy that causes Privoxy filtering to
be bypassed or completely disabled
- establish a direct connection from the web browser to the local
proxy and modify the user defined configuration values
The Privoxy documentation recommends against enabling these options in
multi-user environments or when dealing with untrustworthy clients.
However, the documentation does not mention that client-side
web browser scripts or vulnerabilities could be exploited as well.
It should be noted that using Tor is not a prerequisite for some of
these attacks to be successful. Users of Tor may be at greater risk,
because malicious exit nodes can inject content into otherwise trusted
sites.
In order to allow time for people to upgrade, additional attack
details and sample code will be withheld for a couple of days.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHKKB6WbVJrJm/lrsRApQLAKC5FRcVsCuBBxtSxnmbl0ihixaX3gCfZHZ8
gwXIIv2LUswWy1bSwg5CJU4=
=ZSdL
-END PGP SIGNATURE-
Re: Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
On 10/31/07, Gregory Fleischer (Lists) [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
an insecure configuration file. Both Windows and Mac OS X versions
are affected. The installed 'config.txt' file ('config' on Mac OS X)
had the following option values set to 1:
- enable-remote-toggle
- enable-edit-actions
Additionally, on Windows the following option was set to 1:
- enable-remote-http-toggle
Malicious sites (or malicious exit nodes) could include active content
(e.g., JavaScript, Java, Flash) that caused the web browser to:
- make requests through the proxy that causes Privoxy filtering to
be bypassed or completely disabled
- establish a direct connection from the web browser to the local
proxy and modify the user defined configuration values
The Privoxy documentation recommends against enabling these options in
multi-user environments or when dealing with untrustworthy clients.
However, the documentation does not mention that client-side
web browser scripts or vulnerabilities could be exploited as well.
It should be noted that using Tor is not a prerequisite for some of
these attacks to be successful. Users of Tor may be at greater risk,
because malicious exit nodes can inject content into otherwise trusted
sites.
In order to allow time for people to upgrade, additional attack
details and sample code will be withheld for a couple of days.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHKKB6WbVJrJm/lrsRApQLAKC5FRcVsCuBBxtSxnmbl0ihixaX3gCfZHZ8
gwXIIv2LUswWy1bSwg5CJU4=
=ZSdL
-END PGP SIGNATURE-
I know what that code would be (cause I tried this awhile back), but I'm not
going to be the one to post it. Although anyone with basic HTML coding
abilities and half a brain can figure it out. And javascript/java/flash
isn't required to make this happen. It can be done with a simple IFRAME.
But I'm not posting the one line of HTML code that would do this, no sir.
We noted this a while back with JanusVM, but I don't think we documented the
reasoning behind it.
(Cue Roger giving a friendly reminder to get more documentation and source
code produced ;-)
First we disabled those options for obvious reasons.
Then we enabled them because a couple of users wanted more control.
Then we disabled them again because that level of control can be accessed
from the console if they really want it.
Fun times.
no traffic?
Hello, In my mrtg graphs I see fair traffic until april, then less traffic until august and after august it is 2xx bytes/s in average with almost no peaks. Why is the traffic like it is? Udo
peculiar 0.2.0.9-alpha behavior this a.m.
[WARNING: I've included a *lot* of log entries in this note, interspersed with my observations and comments, so it is quite long and finding my remarks will require careful scanning.] Among the various windows I keep open in X, I usually have one open for /var/log/messages and another for /var/log/tor/notices.log (using tail -f to display them). Early this a.m. I was startled to see suddenly appear the following after /var/log/tor/notices.log had been silent for about twelve hours: Oct 31 02:51:21.091 [notice] Our directory information is no longer up-to-date enough to build circuits. Oct 31 03:03:40.827 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:03:44.227 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:05:54.303 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:06:04.881 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:06:05.788 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:06:07.634 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:20:47.606 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:20:52.109 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:20:52.452 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:20:52.961 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:35:34.688 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:35:36.741 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:35:38.253 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:35:41.936 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:46:23.371 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) Oct 31 03:49:32.305 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit) At this point, the two operations that had been trying to make connections via the client side of tor failed. I tried to trigger fetching a new directory by sending a SIGHUP: Oct 31 03:50:07.449 [notice] Received reload signal (hup). Reloading config. Oct 31 03:50:07.514 [notice] Tor 0.2.0.9-alpha (r12180) opening log file. Oct 31 03:50:07.515 [warn] Can't log to stdout with RunAsDaemon set; skipping stdout Oct 31 03:50:07.515 [warn] Can't log to stdout with RunAsDaemon set; skipping stdout Oct 31 03:50:43.108 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:50:59.337 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:50:59.734 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:51:00.324 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:51:00.582 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:51:00.844 [notice] I learned some more directory information, but not enough to build a circuit. tor often gives up a little too soon, so I tried again: Oct 31 03:54:36.937 [notice] Received reload signal (hup). Reloading config. Oct 31 03:54:37.019 [notice] Tor 0.2.0.9-alpha (r12180) opening log file. Oct 31 03:54:37.024 [warn] Can't log to stdout with RunAsDaemon set; skipping stdout Oct 31 03:54:37.024 [warn] Can't log to stdout with RunAsDaemon set; skipping stdout Oct 31 03:55:10.687 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit) Oct 31 03:57:51.575 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) Oct 31 04:07:11.865 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 04:07:14.915 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 04:07:15.758 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 04:07:16.986 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 04:07:18.166 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 04:07:36.604 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 04:15:25.256 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit) Oct 31 04:21:35.618 [notice] I learned some more directory information, but not
Re: Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
Kyle Williams [EMAIL PROTECTED] wrote:
On 10/31/07, Gregory Fleischer (Lists) [EMAIL PROTECTED] wrote:
Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
an insecure configuration file. Both Windows and Mac OS X versions
are affected. The installed 'config.txt' file ('config' on Mac OS X)
had the following option values set to 1:
- enable-remote-toggle
- enable-edit-actions
Additionally, on Windows the following option was set to 1:
- enable-remote-http-toggle
Malicious sites (or malicious exit nodes) could include active content
(e.g., JavaScript, Java, Flash) that caused the web browser to:
- make requests through the proxy that causes Privoxy filtering to
be bypassed or completely disabled
- establish a direct connection from the web browser to the local
proxy and modify the user defined configuration values
I know what that code would be (cause I tried this awhile back), but I'm not
going to be the one to post it. Although anyone with basic HTML coding
abilities and half a brain can figure it out. And javascript/java/flash
isn't required to make this happen. It can be done with a simple IFRAME.
But I'm not posting the one line of HTML code that would do this, no sir.
We noted this a while back with JanusVM, but I don't think we documented the
reasoning behind it.
Let me get this straight. A while ago, you found a vulnerability that
allows an attacker to change Privoxy's action files without relying on
the user to execute untrusted code, but decided not to report it to the
Privoxy Team and/or the people behind the Vidalia bundle and instead
only fixed it in your own Tor+Privoxy distribution?
Is there a remote chance that you could come around to
do the right thing and report it now?
Fabian
signature.asc
Description: PGP signature
Re: Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
On Wednesday 31 October 2007 15:34:18 Gregory Fleischer (Lists) wrote:
Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
an insecure configuration file. Both Windows and Mac OS X versions
are affected. The installed 'config.txt' file ('config' on Mac OS X)
had the following option values set to 1:
- enable-remote-toggle
- enable-edit-actions
snip
In order to allow time for people to upgrade, additional attack
details and sample code will be withheld for a couple of days.
TorK is affected by this too. There should be a 0.22 available before Friday.
signature.asc
Description: This is a digitally signed message part.
Re: peculiar 0.2.0.9-alpha behavior this a.m.
My server also had the I learned some more directory information, but not enough to build a circuit. problem today. It continued for a long while, so I tried to restart Tor and it worked. The problem with the I learned some more directory information, but not enough to build a circuit. message coming again and again without any good reason has happened before. Restarting Tor generally works, but not always the first time. I guess I don't need to show my logs as they are just like Scott Bennett's logs, full of I learned some more directory information, but not enough to build a circuit. BTW the problem is not with Vidalia, as I don't use Vidalia anylonger because of all the incompatibility problems between Tor alpha 0206-0209 and recent Vidalia versions. Seems like the alpha releases recently really have been true alpha, and not beta releases called alpha. ;-) The problem I wrote about previously, with Vidalia and Tor blocking each other at startup might also be caused by Vidalia, but since 0206 (I believe) they have been blocking each other in some way resulting in nearly 100% CPU sometimes and unresponsive programs. But that's probably a completely different problem. Scott Bennett skrev: [WARNING: I've included a *lot* of log entries in this note, interspersed with my observations and comments, so it is quite long and finding my remarks will require careful scanning.] Among the various windows I keep open in X, I usually have one open for /var/log/messages and another for /var/log/tor/notices.log (using tail -f to display them). Early this a.m. I was startled to see suddenly appear the following after /var/log/tor/notices.log had been silent for about twelve hours: Oct 31 02:51:21.091 [notice] Our directory information is no longer up-to-date enough to build circuits. Oct 31 03:03:40.827 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:03:44.227 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:05:54.303 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:06:04.881 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:06:05.788 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:06:07.634 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:20:47.606 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:20:52.109 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:20:52.452 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:20:52.961 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:35:34.688 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:35:36.741 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:35:38.253 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:35:41.936 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:46:23.371 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) Oct 31 03:49:32.305 [notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit) At this point, the two operations that had been trying to make connections via the client side of tor failed. I tried to trigger fetching a new directory by sending a SIGHUP: Oct 31 03:50:07.449 [notice] Received reload signal (hup). Reloading config. Oct 31 03:50:07.514 [notice] Tor 0.2.0.9-alpha (r12180) opening log file. Oct 31 03:50:07.515 [warn] Can't log to stdout with RunAsDaemon set; skipping stdout Oct 31 03:50:07.515 [warn] Can't log to stdout with RunAsDaemon set; skipping stdout Oct 31 03:50:43.108 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:50:59.337 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:50:59.734 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:51:00.324 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:51:00.582 [notice] I learned some more directory information, but not enough to build a circuit. Oct 31 03:51:00.844 [notice] I learned some more directory information, but not enough to build a circuit. tor often gives up a little too soon, so I tried again: Oct 31 03:54:36.937 [notice] Received reload signal (hup). Reloading config. Oct 31 03:54:37.019 [notice] Tor
0.1.2.18 Crash on Mac 10.3
Tor Crashes while starting after updating from 0.1.2.17 to 0.1.2.18. I used the Tor Privoxy Vidalia bundle. This is the crash log. OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: tor Path:/usr/bin/tor Version: ??? (???) PID: 377 Thread: Unknown Link (dyld) error: dyld: tor can't open library: /usr/local/lib/libevent-1.3e.1.dylib (No such file or directory, errno = 2) -- [EMAIL PROTECTED] -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow
Re: peculiar 0.2.0.9-alpha behavior this a.m.
On Wed, 31 Oct 2007 21:59:53 +0100 [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My server also had the I learned some more directory information, but not enough to build a circuit. problem today. It continued for a long while, so I tried to restart Tor and it worked. The problem with the I learned some more directory information, but not enough to build a circuit. message coming again and again without any good reason has happened before. Restarting Tor generally works, but not always the first time. I guess I don't need to show my logs as they are just like Scott Bennett's logs, full of I learned some more directory information, but not enough to build a circuit. BTW the problem is not with Vidalia, as I don't use Vidalia anylonger because of all the incompatibility problems between Tor alpha 0206-0209 and recent Vidalia versions. I should mention that I only use Vidalia when I run tor under WinXP, which was not the case that produced the log messages. I no longer run tor in server mode under WinXP, only in client mode long enough to download updates to security software. My tor server runs under FreeBSD 6.2-STABLE. I haven't succeeded in compiling Vidalia under FreeBSD, so I can't use it. Seems like the alpha releases recently really have been true alpha, and not beta releases called alpha. ;-) ;-} Indeed, yet they don't seem to be any worse than the stable versions. Makes me wonder about the wisdom of maintaining two branches of code that are effectively both production branches. The problem I wrote about previously, with Vidalia and Tor blocking each other at startup might also be caused by Vidalia, but since 0206 (I believe) they have been blocking each other in some way resulting in nearly 100% CPU sometimes and unresponsive programs. But that's probably a completely different problem. 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: some civically irresponsible exits?
Scott Bennett wrote: The documentation that comes with tor rather strongly suggests that exit servers should have exit policies rejecting the SMTP port (25). The tor sample torrc includes this rejection as well. This rejection of exits to port 25 would seem to be a Very Good Thing (tm) in light of the rapidly growing waste of Internet bandwidth in the form of massmail. Nevertheless, I decided a few minutes ago to take a peek at reality by playing with the exitlist python script in tor-0.2.0.9-alpha/contrib. Using one of the IP addresses for the system on which I get most of my email, I get: I don't see this as a problem at all. I see it as totally responsible. Some exit node operators allow outgoing port 25. They probably also allow port 6667, port 80, port 443, etc. Any and all of these ports can be abused. Mail admins that want to block Tor from sending possible email to their servers can easily use the TorDNSEL: http://exitlist.torproject.org/ I run that server and if you're in need of help using its features, feel free to write me. Tup wrote the Haskel that's powering it and it's been running fine for months. A mail admin should assign a score based on the results of an exitlist rbl test. Hopefully they won't just throw it away. I hear people use it for the same reasons that people use any other exit port. -Jacob
Re: no traffic?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/07, Udo van den Heuvel wrote: Hello, Hi! In my mrtg graphs I see fair traffic until april, then less traffic until august and after august it is 2xx bytes/s in average with almost no peaks. Why is the traffic like it is? No idea. Did you ever update/restart your Tor-server? Could you share your MRTG-grahps with us? Udo Alex. - -- I am tired of all this sort of thing called science here... We have spent millions in that sort of thing for the last few years, and it is time it should be stopped. -- Simon Cameron, U.S. Senator, on the Smithsonian Institution, 1901. . -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: http://firegpg.tuxfamily.org iQCVAwUBRykT7hYlVVSQ3uFxAQL+rwP+OqeTwV5KvNDafvmo0DcqtTm2z13lYhGk SaGGAJ+WxZubWdce3XOAmDo80Iby7z4wLbcqMuq1NTBYs4DT0OW6hbSSrkq7dyyX 8dwHnG1zSHH+NU8lxNEV9mtaFos9Tbs+FX4Ta4nGB76jdTQAVm/4XBuxWK1VGXco DtN3oyBpLys= =RTBm -END PGP SIGNATURE-
UpDate:,,, Success getting Server Up behind NAT,,
Hello Ringo, Csaba and everybody,, I did solve the Linksys NAT/RHEL/Tor server puzzle, I think. Server is up and normally I see about 100mbs/sec through it on Vidalia bandwidth graph. Yea! I had to learn a little about routers and network, Tor and RHEL, finally, to whomever is interested, I configured RHEL eth0 to a static IP of my choosing, corresponding to possible assignable IP's from Firewall/Router. Linksys support was good, they advised me of that range. I also had to interpolate other settings from Linksys windows config instructions. Finally, got it right! :),, So, server is up and working, thanks to all who tried to help! I still have two nagging concerns though. One is that Tor gives me nameserver failure notices intermittently, then system seems to go to back up DNS at comcast, as per settings for RHEL static IP. I am not sure what that is about, but it does seem to get resolved and seems to work fine most of the time. Also, I will have to check all info I can to harden my server computer. I have seen how many scans go over comcast owned net blocks, running a Tor server without doing *everything* monitoring system for intrusion attempts just would be asking for failure. Anyhow, I hope for the best, anyone with comments very welcome! Algenon Ringo Kamens [EMAIL PROTECTED] wrote: Can you try pining the DNS backup to see if you can reach it? Comrade Ringo Kamens On 10/29/07, algenon flower wrote: Hello TOR people, Yay! I did finally get server up, but all is not completely good: Anyone interested please note log entries.Thanks for advice and support. I hope to have it working perfectly soon. Am not sure exactly what to think of entries below: * Oct 29 03:31:32.969 [Notice] Tor v0.2.0.7-alpha (r11572). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686) Oct 29 03:31:32.975 [Notice] Initialized libevent version 1.1a using method epoll. Good. Oct 29 03:31:32.979 [Notice] Opening OR listener on 0.0.0.0:9001 Oct 29 03:31:33.131 [Notice] Opening Directory listener on 0.0.0.0:9030 Oct 29 03:31:33.138 [Notice] Opening Socks listener on 127.0.0.1:9050 Oct 29 03:31:33.142 [Notice] Opening Control listener on 127.0.0.1:9051 Oct 29 03:31:46.978 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working. Oct 29 03:32:19.088 [Notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Oct 29 03:32:45.443 [Notice] Performing bandwidth self-test...done. Oct 29 03:33:41.789 [Warning] eventdns: All nameservers have failed Oct 29 03:33:41.872 [Notice] eventdns: Nameserver 68.87.69.146 is back up Oct 29 03:33:46.790 [Warning] eventdns: All nameservers have failed Oct 29 03:33:46.856 [Notice] eventdns: Nameserver 68.87.69.146 is back up I can see from the Bandwith Graph that some traffic does flow through, though not a lot. Is this normal? Is it OK that I get a nameserver error and how can that problem be solved?? The listed back up is my normal DNS at comcast. Algenon algenon flower wrote: Hello Pei Hanru, experienced TOR users I have checked Linksys doc's and I think they were helpful. At present, I think I need to assign a static IP to my RHEL system behind NAT firewall. That seems to include two extra assigned IP numbers, like 196.168.1.20, Then I can use port forwarding set-up on NAT router. I bet this is elementary school for many of you, it took a little while for me :),, All I need now is the procedure to assign a static IP on RHEL. I am checking that now,, And, Hope it all Works! In any case, thanks to people interested, and additional comments welcome. peace, Algenon Pei Hanru wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2007-10-27 06:23 CST, algenon flower wrote: Hello Michael Holstein and other interested people I thought I had accomplished port forwarding (see attached file) but did not succeed. After checking with Linksys support site I am going to try a new apporach. Will study the doc's from Linksys, if anyone has experience with this please let me know. Algenon Unfortunately, you are doing worse... What you should do is first figuring out the *actual* private IP address of your Linux box, then forwarding port 9001 and port 9030 (or port range 9001-9030 if you like) to *that* address, rather than forwarding the same port range to three distinct addresses. It's a good idea to reread port forwarding part of Linksys manual carefully. Hanru -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJDrrtHG285r2MGoRAvAJAKDLRHZYc/5ZRXeNgaIXnZHUr/2zXgCeOqji h67261xOLOYdjvEyADPndks= =EmPN -END PGP SIGNATURE- __ Do You
Re: peculiar 0.2.0.9-alpha behavior this a.m.
On Wed, Oct 31, 2007 at 12:24:11PM -0500, Scott Bennett wrote: [WARNING: I've included a *lot* of log entries in this note, interspersed with my observations and comments, so it is quite long and finding my remarks will require careful scanning.] Among the various windows I keep open in X, I usually have one open for /var/log/messages and another for /var/log/tor/notices.log (using tail -f to display them). Early this a.m. I was startled to see suddenly appear the following after /var/log/tor/notices.log had been silent for about twelve hours: Oct 31 02:51:21.091 [notice] Our directory information is no longer up-to-date enough to build circuits. Oct 31 03:03:40.827 [notice] I learned some more directory information, but not enough to build a circuit. [...] And all has been well since the restart. I am mystified as to what went wrong that tor found itself unable to build circuits, even though I could see that it was adding new data to cached-descriptors.new quite frequently. Did anything strange happen to the directory authorities early this a.m. that might have induced this behavior? Hi, Scott! I'd suspect a bug in 0.2.0.9 alpha; I'm not aware of any authority bug. Unfortunately, the log messages still leave me clueless as to what's going on. If this happens again, can you: A) Make a copy of cached-descriptors* and cached-consensus, so that the state can be reproduced to try to investigate what's up. B) If possible, log at info for a while: it says a lot more about what's happening with downloads. I'm going to try to make those Not enough info messages more useful in the next alpha; sorry I can't figure this out just now. yrs, -- Nick Mathewson pgpbodUz50Poz.pgp Description: PGP signature
Re: 0.1.2.18 Crash on Mac 10.3
On Wed, Oct 31, 2007 at 02:42:18PM -0700, [EMAIL PROTECTED] wrote 0.5K bytes in 24 lines about: : dyld: tor can't open library: /usr/local/lib/libevent-1.3e.1.dylib (No : such file or directory, errno = 2) You are correct. For some reason, mostly mine, libevent was compiled with both shared and dynamic libs. This means Tor chose the dynamic lib during the build. I'll put up panther 0.1.2.18b packages soon. -- Andrew
Re: peculiar 0.2.0.9-alpha behavior this a.m.
On Wed, 31 Oct 2007 23:30:05 -0400 Nick Mathewson [EMAIL PROTECTED] wrote: On Wed, Oct 31, 2007 at 12:24:11PM -0500, Scott Bennett wrote: [WARNING: I've included a *lot* of log entries in this note, inters= persed with my observations and comments, so it is quite long and finding my rem= arks will require careful scanning.] Among the various windows I keep open in X, I usually have one open = for /var/log/messages and another for /var/log/tor/notices.log (using tail -= f to display them). Early this a.m. I was startled to see suddenly appear = the following after /var/log/tor/notices.log had been silent for about twelve hours: =20 Oct 31 02:51:21.091 [notice] Our directory information is no longer up-to= -date enough to build circuits. Oct 31 03:03:40.827 [notice] I learned some more directory information, b= ut not enough to build a circuit. [...] And all has been well since the restart. I am mystified as to what went wrong that tor found itself unable to= build circuits, even though I could see that it was adding new data to cached-descriptors.new quite frequently. Did anything strange happen to = the directory authorities early this a.m. that might have induced this behavi= or? =20 Hi, Scott! I'd suspect a bug in 0.2.0.9 alpha; I'm not aware of any authority bug. Unfortunately, the log messages still leave me clueless as to what's going on. If this happens again, can you: A) Make a copy of cached-descriptors* and cached-consensus, so that the state can be reproduced to try to investigate what's up. Sure. B) If possible, log at info for a while: it says a lot more about what's happening with downloads. Okay. However, unless the problem recurs while that is going on, I'm not sure what help it will be. Keep in mind that it has only happened on my system once so far with *any* version of tor that I've run, so it's quite possible that it may never happen again. I'm going to try to make those Not enough info messages more useful in the next alpha; sorry I can't figure this out just now. How about also logging whatever made tor decide that the information was out of date in the first place? The first sign of the problem was the log message: Oct 31 02:51:21.091 [notice] Our directory information is no longer up-to-date enough to build circuits. That doesn't tell me what the triggering event was. Had it just downloaded a network status document that caused it to believe that the information was too old? What timestamp did it use from whatever source to determine that the information was out of date? Thanks much! 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 * **
