Re: Debian/Ubuntu tor users, please check for core files
Jan Weiher wrote: Hi, no core files on my Ubuntu 8.04 relay. regards, Jan Has anybody checked to see whether the Tor instances running on Ubuntu have the ability to leave core files? I've never delved into the details, but I know on older versions of Ubuntu, running ulimit in a shell showed the maximum core file size set to 0. Jim *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: minimal traffic footprint Tor on the road
grarpamp wrote: Besides plugging DNS leaks, the two programs serve somewhat different purposes. Indeed, however neither program's purpose is to 'plug dns leaks'. They simply feed what connection [dns] requests they receive on towards Tor. I thought the reason you could not send Firefox's SOX5 straight to Tor was because of a bug in Firefox that would cause a DNS leak. Perhaps I misunderstood or my information is outdated? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: minimal traffic footprint Tor on the road
Jan Reister wrote: Il 28/09/2009 15:25, Eugen Leitl ha scritto: Why the switch to Polipo from Privoxy? Is Privoxy officially deprecated now? I just found out today and am wondering myself. From hearsay, Polipo should perform faster and better. There was a somewhat extended discussion about Privoxy vs Polipo on this list not too long ago (a month or two?). You may wish to review that. My recollection of that discussion is that Polipo being better was called into question. Certainly Privoxy is alive and well. Besides plugging DNS leaks, the two programs serve somewhat different purposes. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT]RE: Unsubscribe
downie - wrote: You have to send to a different address. Instructions [to unsubscribe] are in the headers. Having seen this situation on this list multiple times, it occurs to me that beyond To, From, and Date, many people have probably never seen the headers. Most non-techies probably don't even know it exists. I believe most GUI mail clients, by default, only show the abbreviated version I just mentioned. I know mine does. I don't know what the solution is, but I thought I would throw this out there for people's consideration. Jim
Re: seven bloxortsipt* relays ought *not* to be Valid
Scott Bennett wrote: a) are running an obsolete version of tor (0.1.2.19) under LINUX, which is far enough back to be a security problem due to the SSL key generation bug in LINUX, If the key generation problem refers to what I think, and just for the record, that was only a problem for Debian and Debian derived distributions of Linux. snipped other reasons That much, IMO, ought to justify removal of their Valid flags by the authorities. In the meantime, I have them all in my ExcludeNodes list, and I recommend that all relay operators concerned about security in tor do likewise. My comment above should *not* be construed to mean I disagree with this conclusion.
Re: Thanks for the inclusion...
Michael Cozzi wrote: Hello Tor Team. I'm not sure who to thank, but I noticed my suggested text regarding what IT Professionals use Tor for was included whole cloth on the web page. Thank you, that gave me geek-warm-fuzzies. Michael Very nicely done. It has been quite a while since I have looked at that page. The whole page is quite nice. Kudos to those involved.
Re: .exit handling (was Yahoo Mail and Tor)
downie - wrote: Date: Fri, 10 Jul 2009 11:15:25 -0400 From: eril...@gmail.com To: or-talk@freehaven.net Subject: Re: Yahoo Mail and Tor If I'm proxying through Tor and I type this into my browser: www.google.com.example.exit My browser asks the proxy for a connection to www.google.com.example.exit Once my browser receives the connection, it then sends this down it: GET / HTTP/1.1\r\n Host: www.google.com.example.exit\r\n \r\n The problem is that some web servers have multiple websites on the same IP and they decide which website to serve by looking at the HTTP Host header. So you need privoxy/polipo to strip the example.exit from the HTTP Host header before forwarding on the actual HTTP request, so it sends this instead: GET / HTTP/1.1\r\n Host: www.google.com\r\n \r\n -- Erilenz So far so good. A possible problem then arises when the served page contains absolute URLs for resources, links etc which no longer use the .exit notation, and so could be fetched from a different exit. How often that would happen is open to question. Another Privoxy rule could be written to rewrite those page URLs I guess, but how would you pass the name of the required exit to the rule? Should the tor exit be removing the .exit notation from the header instead of privoxy? Or perhaps the tor client, which selects the route? (I mistakenly thought one of those did it now. It has been a long time since I've used .exit ...)
Re: Yahoo Mail and Tor
Andrew Lewman wrote: A) The Privoxies after 3.06 have a local web control interface which we believe is a security risk. We think that remote websites can probably reconfigure your privoxy via that interface, maybe even without your noticing. If newer versions have the ability to disable this interface, we can consider testing and subsequently including those with our packages. Can you provide a link to what you are talking about? I just searched on the terms/phrase web control interface with privoxy and only had a few matches, none of which seemed relevant. I also checked privoxy's online manual ( http://www.privoxy.org/user-manual/index.html , v 1.60 2009/03/21 12:58:53) and I didn't see anything about changing configuration that had substantively changed since I started using privoxy 3+ years ago. At *least* since that time there there has been the ability to edit action files via browser (web interface) if allowed in the configuration file. The configuration file itself had to be manually edited, and, at least in *nix, the config file could be owned by root and set to be not writeable by privoxy (assuming privoxy was running w/o privilege). You could also toggle enable/disable through privoxy's web interface if allowed in the config file. It should be noted that disabling merely turns off the application of the rules -- it does *not* affect packet routing. So if something was sent via Tor with privoxy enabled, it is still sent through Tor with privoxy disabled. I have specifically verified that using http://torcheck.xenobite.eu . So could you point me to what has changed since 3.0.6 that causes security concerns? Thanks. P.S. Oops, I just noticed others have requested a link. Did not mean to repeat. I believe the rest of what I said is relevant.
Re: Yahoo Mail and Tor
bao song michaelw...@yahoo.com.au wrote: The standard Tor bundle download for non-Windows still includes Privoxy 3.0.6, which mangles Yahoo mail. I am running privoxy 3.0.6. If you want to email me off-list I will be happy to send you my user.action file which seems to more or less work adequately for Yahoo mail. (Sometimes there is some weirdness with scroll bars, but it is usuable. And the page *after* logging out is somewhat mangeled, but who cares about that?) You will have to sort the relevant yahoo rules from the rest for yourself. You can also simply disable privoxy (via its menu -- it still forwards to tor appropriately) while using Yahoo mail. If you email me, I would appreciate text (not html) email.
Re: Google and Tor
grarpamp wrote: GMail doesn't do this anymore. You can sign up through Tor just fine. Yes, there was a time years ago where they were invite only :( Then they opened up. This does not refer to that historical thing. I tried making four different acct names over the span of a day about a day before I first posted this. Clearing cookies and newnym between each. Account creation tests between then and now have worked without issue. Don't know what google was up to when I posted Seems fine now. Thanks, sorry for the noise. It may have been related to the traffic from those exit nodes that Google was seeing *at* *that* *time*. There was a time when Google's search engine would sometimes tell me something along the lines of we think you are a virus that was definitely time/exit-node dependent. (Now it is very rare that exiting from Tor does not cause me problems with Google's search.)
Re: Google and Tor
James Brown wrote: I use the gmail within Tor very easy but I have some problems sometimes with other services of Google. For maybe I couple of years it has been almost impossible for me to use Google's search via Tor. (It keeps calling me a virus.) Somebody eventually told me about Scroogle ( http://www.scroogle.org/scraper.html ) which I have had good luck with via Tor. I *think* that recently, after Google flags you as suspicious activity it allows you to proceed with a captcha *if* you accept cookies. Not a good way to remain anonymous unless you immediately delete the cookies. (When I first tried to use Tor I had some, now long forgotten, problem. Google-analytics was my motivation for solving the problem.) But about last two monthes there is problems with using the Yahoo mail through Tor. If you are talking about error 999 (Yahoo's term), I have occasionally had problems with that for a long time. Recently it seems to have become routine. You can immediately go to the captcha login for email (which I don't have trouble with from Tor) with: https://login.yahoo.com/config/login?.ab=1.done=http%3A//mail.yahoo.com (of course, Yahoo might break that link at any time) Be aware that although *login* to Yahoo mail is https, the other transmissions are in clear text. So you are exposing your email (both send and receive) to exit nodes. P.S. After seeing bao song's post, I remembered I have fiddled with Privoxy's settings to keep it from mangling Yahoo mail. But I have routed Yahoo's mail clear text straight to the Internet to avoid any exit node mischief. I send the https login via Tor because it it too difficult to separate from my other Yahoo traffic.
Re: 25 tbreg relays in directory
Arjan wrote: Jim McClanahan wrote: [...] Certainly, protecting the network is a priority. Protecting uninformed or unsuspecting users gets trickier IMHO. I'll admit this is a bit of a hot-button issue for me and I may have overreacted. But I think care needs to be taken before cavalierly shutting something down to protect uninformed or unsuspecting users. I agree with Ringo 2600den...@gmail.com when he wrote (at Tue, 30 Jun 2009 00:06:01 -0400) Remotely disabling Tor nodes is a slippery slope. In my humble opinion, protecting uninformed or unsuspecting users / relay operators should be a priority. The discussion was about Tor *clients* not Tor *servers*. I have repeatedly stated I didn't have problems with disabling the servers if that was needed to protect the network. And while I didn't specifically mention client in what was quoted above, I did reiterate that protecting the network was important.
Re: 25 tbreg relays in directory
Scott Bennett wrote: On Mon, 29 Jun 2009 07:13:42 -0600 Jim McClanahan jimmy...@copper.net Scott Bennett wrote: On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan jimmy...@copper.net wrote: Scott Bennett wrote: Ouch. This provides another example in support of having a way for the directory authorities to render insecure versions ... and only usable as clients to connect to the tor project's web site to download a current version of tor. This kind of thinking baffles me. It seems diametrically opposed to the notion of free software. I could understand if the outdated client was How so? It's still free of charge, freely available, and freely modifiable and redistributable. (GPL3-licensed software doesn't qualify, IMO.) I did not not mean it was not technically free software. The license takes care of that. My meaning is that the goal is to restrict people rather than to grant freedom. It is an issue of perspective rather than license technicalities. I probably could have phrased it better. Oh, okay. Thanks for clarifying. The intent of my suggestions has been to restrict abuse harmful either to an uninformed and unsuspecting user or to the tor network overall, not to restrict people. I have no problems with either of those goals. Certainly, protecting the network is a priority. Protecting uninformed or unsuspecting users gets trickier IMHO. I'll admit this is a bit of a hot-button issue for me and I may have overreacted. But I think care needs to be taken before cavalierly shutting something down to protect uninformed or unsuspecting users. I agree with Ringo 2600den...@gmail.com when he wrote (at Tue, 30 Jun 2009 00:06:01 -0400) Remotely disabling Tor nodes is a slippery slope. will do. endangering the Tor network (which was discussed in the portion of the comment I skipped over with the ellipsis). And I would have no problem Insecure relays endanger the network That is why I inserted the ellipsis and made the parenthetical comment about it. I am not arguing against neutralizing insecure relays. The danger to the network is perfect justification IMO. Note that the version of tor that Pei Hanru reported here had been part of the tbreg distribution is *not* secure. I was aware of that at the beginning of this discussion. It's not like the clients ended up there on their own w/o the consent of the user or owner. Trying to enforce a policy on people when those Pei Hanru suggested otherwise. My point was the users knew that they were installing *some* software. They may not have know that the software contained Tor or even what Tor is. But I see the situation as similar to unscrupulous people slipping malware or other unknown software into packages people willingly install. While I don't approve of that, neither do I feel compelled to police it. Which would be a futile endevour anyway. I would argue that those unsuspecting, involuntary tor operators were indeed harmed and further that they were placed at significant risk of far greater harms at the hands of that State. Yet the harm at the hands of that State has nothing to do (TMK) with the fact that the clients were insecure, but rather that they were Tor. technical argument. Obviously, it is technically possible to do what you describe. And because of the free license, it is technically possible and legally permissible for people to undo those changes on their copies of the software. It is also possible for the software to lie to the network about what it is. But as I stated, this attitude of trying to coerce other people baffles me. I am not saying nobody does it. The world is full of tyrants. Clearly, the above comments are inapplicable to this situation and to what I was suggesting as a way to deal with similar situations in the future. Again, maybe I was overreacting. But I do think people who are not trying to be tyrants nonetheless need to be very careful with for your own good attitudes. IMO it gets very tricky. Just to flesh out my view a little more, I would have no problem with a configuration option that says allow the tor network to nearly disable this client at somebody's discretion. As long as it could be Oh, stop it. That's ridiculous. All the person would have to do would be to upgrade to a valid version. It does not restrict the user. It just minimizes the damage that can be caused by software known/suspected to have something wrong with it. I probably should have canned the sarcasm, but I do think that any disabling of the client from the network should be easily reversible. Part of that is just my philosophy. But it also has a practical element in terms of what is required to resume functionality if the client suddenly and unexpectedly stop working. Somebody may not wish to take the time to install at that moment
Re: 25 tbreg relays in directory
Edward Langenback wrote: Jim McClanahan wrote: I probably should have canned the sarcasm, but I do think that any disabling of the client from the network should be easily reversible. Part of that is just my philosophy. But it also has a practical element in terms of what is required to resume functionality if the client suddenly and unexpectedly stop working. Somebody may not wish to take the time to install at that moment. I assume that Tor can (or could be made to) detect what OS it's being run on. Given that, what if Tor were to check it's current version against the directory servers while it's creating circuits. Then if the version running is judged too far out of date to be safe, it could download the most recent version (via the Tor network of course) for the OS it's running on and auto-update itself. I guess that would depend on the OS and how it is configured. If Tor is running without privilege, as recommended, I would think in most scenarios it would not have the ability to update itself. If something is configured non-standard (whatever that may mean in a particular situation) then I would guess the attempt to update would not have the desired result even if Tor had privilege. That said, it is my understanding that on MS Windows, Firefox has such an auto-update mechanism although I am not familiar with the details. Personally, I like to be in charge of what happens on my computers. I remain unconvinced that what happened in the case of tbreg should be determining policy for the Tor project, at least as far as client activity is concerned. To the extent the people who installed really didn't know it involved Tor, it seems to me that, if not technically malware, it is at least a close cousin (where software creators are not being up front with users). Trying to, in effect, be the guardian of such users is (IMHO) a losing proposition.
@Scott Bennett
I was trying to email you and it bounced: Final-Recipient: rfc822; benn...@cs.niu.edu Original-Recipient: rfc822;benn...@cs.niu.edu Action: failed Status: 5.7.1 Remote-MTA: dns; mp.cs.niu.edu Diagnostic-Code: smtp; 550 5.7.1 benn...@cs.niu.edu... Access denied
@Scott Bennett
Ah, I see. It is the duplicate messages from you that were confusing me. Why duplicate messages? As somebody else has pointed out recently, the fact that I can post on or-talk means I am subscribed to or-talk.
Re: 25 tbreg relays in directory
Scott Bennett wrote: Ouch. This provides another example in support of having a way for the directory authorities to render insecure versions ... and only usable as clients to connect to the tor project's web site to download a current version of tor. This kind of thinking baffles me. It seems diametrically opposed to the notion of free software. I could understand if the outdated client was endangering the Tor network (which was discussed in the portion of the comment I skipped over with the ellipsis). And I would have no problem with a friendly advisory as long is it wasn't incessant nagware that couldn't be disabled. But I don't understand the desire to dictate to people or some nanny viewpoint of trying to save people from themselves. (Before somebody makes an argument of keeping the Internet free of compromised machines, I rather imagine the number of machines compromised because of Tor software would be lost in the statistical noise of all the other ways machines get compromised. And I don't think the unsavory purpose these tbreg instances are put to is a relevant factor.)
Re: 25 tbreg relays in directory
Scott, when I did a reply on your email, it (tried to) sent it your personal email account rather than the list. -- Scott Bennett wrote: On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan jimmy...@copper.net wrote: Scott Bennett wrote: Ouch. This provides another example in support of having a way for the directory authorities to render insecure versions ... and only usable as clients to connect to the tor project's web site to download a current version of tor. This kind of thinking baffles me. It seems diametrically opposed to the notion of free software. I could understand if the outdated client was How so? It's still free of charge, freely available, and freely modifiable and redistributable. (GPL3-licensed software doesn't qualify, IMO.) I did not not mean it was not technically free software. The license takes care of that. My meaning is that the goal is to restrict people rather than to grant freedom. It is an issue of perspective rather than license technicalities. I probably could have phrased it better. (I happen to like, to the extent I understand it, GPLv3. But I don't see how it is relevant to this discussion and I don't know why it was injected into it.) endangering the Tor network (which was discussed in the portion of the comment I skipped over with the ellipsis). And I would have no problem Insecure relays endanger the network That is why I inserted the ellipsis and made the parenthetical comment about it. I am not arguing against neutralizing insecure relays. The danger to the network is perfect justification IMO. Insecure clients installed virally onto systems without notice to the users endanger those users. It's not like the clients ended up there on their own w/o the consent of the user or owner. Trying to enforce a policy on people when those people are not harming others reeks (IMO) of unsavory things like police states and nanny states. I am opposed. It is personal perspective, not technical argument. Obviously, it is technically possible to do what you describe. And because of the free license, it is technically possible and legally permissible for people to undo those changes on their copies of the software. It is also possible for the software to lie to the network about what it is. But as I stated, this attitude of trying to coerce other people baffles me. I am not saying nobody does it. The world is full of tyrants. Just to flesh out my view a little more, I would have no problem with a configuration option that says allow the tor network to nearly disable this client at somebody's discretion. As long as it could be disabled. But I really wonder why Tor developers would be interested in spending the time to implement such a thing. with a friendly advisory as long is it wasn't incessant nagware that couldn't be disabled. But I don't understand the desire to dictate to I don't think the current log messages are so influential as all that. Just take a look at the current consensus. :-( people or some nanny viewpoint of trying to save people from themselves. (Before somebody makes an argument of keeping the Internet free of compromised machines, I rather imagine the number of machines compromised because of Tor software would be lost in the statistical Again, when the software is installed by stealth onto the machines of unsuspecting users, then the probability on each user's machine becomes 100%. In other words, the number of machines w.r.t. the user is 1 out of 1, a ratio that cannot be considered lost in the noise for that user. By stealth??? If that is really so, I guess you could try to make the same argument about *any* free software that somebody decided to turn into malware. But I am still unconvinced the people who installed didn't know they were installing something. noise of all the other ways machines get compromised. And I don't think the unsavory purpose these tbreg instances are put to is a relevant factor.) How so? I note that you deleted all the relevant context in your reply. I did not reproduce Pei Hanru's email in its entirety because I did not see it as necessary. Or particularly relevant for this discussion. As I stated, I don't think the unsavory purpose these 'tbreg' instances are put to is a relevant factor. The unsavory purpose I referred to and perhaps what you call relevant context is the fact that Tor was part of software sold to (for the purpose of) (quoting Pei Hanru) automatically register large number of TaoBao accounts. It is my opinion (yes, once again, *opinion*) that the fact that an unscrupulous person (or group of people) used the free software in question in a manner that *might* be analogous to certain freeware (*not* free software) actually being a trojan, i.e. malware that arguably was installed by stealth, is not justification for taking a tyrannical attitude toward the users of said free
Question About Security Threat from Tor
Hi, I have read on this mailing list several times about how some previous versions of Tor contain vulnerabilities that can threaten the host machine itself. I am reminded of this again with Pei Hanru's excellent work tracking down the tbreg mystery. (I too say thank you.) While I understand that all software has bugs, some of which can be exploited for malicious purposes, I've long wondered how such vulnerabilities in Tor threaten the host itself if Tor is being run (as recommended) as an unprivileged user. Can somebody explain, or point me to an explanation? Thanks.
Re: Question About Security Threat from Tor
Michael wrote: Jim McClanahan wrote: Hi, I have read on this mailing list several times about how some previous versions of Tor contain vulnerabilities that can threaten the host machine itself. snip Hi Jim, Not so much related to Tor itself, but more toward general security. If a standard user account were to be compromised, that's the first step in getting control of a machine. snip Thanks, Michael. My impression from the list was it was a direct threat rather than just a stepping stone. Maybe the references were to Microsoft Windows, or maybe I misunderstood. And I know next to nothing about the security model of MS Windows ... Jim
Re: Lynx leaks DNS
Phil wrote: I realize this needs a fix not a workaround, but if a workaround is enough for now you could try running lynx via proxychains -- tor Proxychains might grab all the DNS requests. Thanks for your response. Now that I know lynx doesn't leak DNS when the protocol (e.g. http://) in included, using full URLs is enough of a workaround for me. (And a relief that I haven't been leaking all of this time.) For everybody's information, I think I learned more about the leaks while I was playing with proxychains. It *appears* that lynx is using DNS to try variations on the supplied name to find one that works. (Maybe there is an option to stop this?) So while I have a solution for myself, I think people using lynx with tor ought to be warned about this. You could also probably leave privoxy in the proxy chain or test it with and without. I haven't tried this with lynx, but proxychains does work with tor. I have tried using proxychains to chain to privoxy. Trying to chain directly to Tor would require more fiddling and I haven't tried that. Lynx couldn't get to the website *and* it DNS leaked. Maybe I didn't have it configured correctly? (privoxy is listening on 192.168.1.27:8119) The non-comment, non-blank lines of the configuration file were: strict_chain tcp_read_time_out 15000 tcp_connect_time_out 1 [ProxyList] http192.168.1.27 8119 I used the command: proxychains lynx http://torcheck.xenobite.eu With tcpdump I saw a DNS query, a TCP handshake with Privoxy, and then proxychains terminated the connection. The page request was not logged in Privoxy's logfile. proxychains reported: strict chain:192.168.1.27:8119..broken, and backgrounded and stopped lynx. # tcpdump -nni eth0 not tcp port 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 23:20:08.950239 IP 192.168.2.102.42865 65.247.xx.xx.53: 28346+ A? torcheck.xenobite.eu. (38) 23:20:08.952037 IP 65.247.xx.xx.53 192.168.2.102.42865: 28346 1/2/2 A 217.160.111.190 (137) 23:20:08.952807 IP 192.168.2.102.51357 192.168.1.27.8119: S 3021896822:3021896822(0) win 5840 mss 1460,sackOK,timestamp 709785 0,nop,wscale 5 23:20:08.954018 IP 192.168.1.27.8119 192.168.2.102.51357: S 3677520579:3677520579(0) ack 3021896823 win 5792 mss 1460,sackOK,timestamp 4633540 709785,nop,wscale 2 23:20:08.954052 IP 192.168.2.102.51357 192.168.1.27.8119: . ack 1 win 183 nop,nop,timestamp 709785 4633540 23:20:08.954245 IP 192.168.2.102.51357 192.168.1.27.8119: F 1:1(0) ack 1 win 183 nop,nop,timestamp 709785 4633540 23:20:08.955321 IP 192.168.1.27.8119 192.168.2.102.51357: P 1:54(53) ack 2 win 1448 nop,nop,timestamp 4633540 709785 23:20:08.955353 IP 192.168.2.102.51357 192.168.1.27.8119: R 3021896824:3021896824(0) win 0 23:20:08.955686 IP 192.168.1.27.8119 192.168.2.102.51357: F 54:54(0) ack 2 win 1448 nop,nop,timestamp 4633540 709785 23:20:08.955702 IP 192.168.2.102.51357 192.168.1.27.8119: R 3021896824:3021896824(0) win 0
Lynx leaks DNS
Hi, Quite by accident I discovered that the lynx browser is leaking DNS addresses. I have verified this on: Lynx Version 2.8.4dev.7 (03 Aug 2000) and Lynx Version 2.8.5rel.1 (04 Feb 2004) lynx is called from scripts with the following statements: export http_proxy=http://localhost:8119 export https_proxy=http://localhost:8119 export ftp_proxy=http://localhost:8119 export gopher_proxy=http://localhost:8119 export news_proxy=http://localhost:8119 export newspost_proxy=http://localhost:8119 export newsreply_proxy=http://localhost:8119 export snews_proxy=http://localhost:8119 export snewspost_proxy=http://localhost:8119 export snewsreply_proxy=http://localhost:8119 export nntp_proxy=http://localhost:8119 export wais_proxy=http://localhost:8119 export finger_proxy=http://localhost:8119 export cso_proxy=http://localhost:8119 Privoxy is listening on localhost:8119 and sends requests to tor in the standard way. I have verified from Privoxy's log that requests are received and http://torcheck.xenobite.eu verifies the request is coming through the Tor network. Supplying linx with the url of p.p (an alias that Privoxy understands) demonstrates that lynx does a DNS request and then ignores the result. Comments? Suggestions?
Re: Lynx leaks DNS
Fabian Keil wrote: Jim McClanahan jimmy...@copper.net wrote: Quite by accident I discovered that the lynx browser is leaking DNS addresses. I have verified this on: Lynx Version 2.8.4dev.7 (03 Aug 2000) and Lynx Version 2.8.5rel.1 (04 Feb 2004) Is there a reason why you aren't using a more recent build? That was what I had readily available. I just installed lynx on Ubuntu 8.04 LTS for more testing: lynx --version Lynx Version 2.8.6rel.4 (15 Nov 2006) libwww-FM 2.14, SSL-MM 1.4.1, GNUTLS 2.0.4, ncurses 5.6.20071124(wide) Built on linux-gnu Apr 8 2008 13:48:42 It shows the same behavior I saw before. But further investigation reveals this interesting twist: It does not leak if the URL with protocol is given. But if the http:// is omitted, it leaks, yet still loads the page. Without thinking, I had just been using p.p. When I used http://p.p, it did not leak. But it is not only p.p that leaks: tcpdump -nni eth0 udp port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 08:22:23.435995 IP 192.168.2.102.45063 65.247.xx.xx.53: 46608+ A? p.p. (21) 08:22:23.437732 IP 65.247.xx.xx.53 192.168.2.102.45063: 46608 2/2/0 A 64.158.56.50, A 63.251.179.30 (109) 08:33:39.447099 IP 192.168.2.102.54845 65.247.xx.xx.53: 19107+ A? torcheck.xenobite.eu. (38) 08:33:39.679776 IP 65.247.xx.xx.53 192.168.2.102.54845: 19107 1/2/2 A 217.160.111.190 (137) (The returned addresses for p.p is bad behavior on the part of my ISP. They lead to a not found page with advertising.) Both of the above were without http:// . And When http:// was added, neither leaked. torcheck.xenobite.eu (both with a w/o http://) verified I was accessing via Tor. Not as bad as I thought when I originally posted. But still disconcerting, particularly considering that it will happily render the page w/o http:// . I can't reproduce the problem with: f...@tp51 ~ $lynx --version Lynx Version 2.8.6rel.5 (09 May 2007) libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.8k, ncurses 5.7.20081102(wide) Built on freebsd8.0 Feb 27 2009 22:36:34
Re: Banners injected in web pages at exit nodes TRHCourtney*
Strange the the provided link didn't have injection... Adaptation on the nodes part? A few minutes ago I tried http://www.torproject.org.TRHCourtney01.exit/ and got a banner ad. Maybe they do it on a sporadic basis?
Re: GSoC Introduction! (TorButton)
Chris Humphry wrote: Hi Kroy! snip 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: TOR and HADOPI
Freemor wrote: On Thu, 28 May 2009 22:25:49 -0700 (PDT) Curious Kid letsshareinformat...@yahoo.com wrote: This policy model, applied globally, may put and end to Tor. Imagine if exit nodes in every country were shut down, yet their operators were still required to pay for an Internet connection for a long period of time thereafter. Each country having their own special blend of banned activities further complicates matters. Maybe Tor could go completely hidden. I really can't see how the pay for something you aren't receiving part of this bill will stand any kind of a legal challenge. Cutting off a persons service is one thing. Forcing a person to pay for nothing is almost universally considered theft/extortion. Particularly when the pay for nothing was not part of any due process. But we shall see.
Re: Iptables configuration for a transparent proxy for a singleuser
unknown wrote: INET_IFACE=eth0 #our internet interface $IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 9050 -j DROP $IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 9040 -j DROP $IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 53 -j DROP $IPTABLES -A INPUT -i $INET_IFACE -p UDP --dport 53 -j DROP # Block incoming traffic for this ports from outside. # Tor already ignore non-local connections by default. $IPTABLES -t nat -A OUTPUT -o lo -j RETURN $IPTABLES -t nat -A OUTPUT -d 127.0.0.1 -j RETURN # Pass direct connection to localhost services. # We can trying use privoxy at first before redirecticting unfiltered traffic to Tor. TOR_UID=debian-tor #see tor uid in file: #tor:x:XXX:YYY::/var/lib/tor) $IPTABLES -t nat -A OUTPUT -m owner --uid-owner $TOR_UID -j RETURN $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner tornet_user -m tcp --syn \ -j REDIRECT --to-ports 9040 $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner tornet_user -m udp --dport 53 \ -j REDIRECT --to-ports 53 $IPTABLES -t nat -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT # Transparent redirection of the traffic to Tor for tornet_user # $IPTABLES -t nat -A OUTPUT -m owner --uid-owner tornet_user -j DROP # This rule will not working anymore in new iptables. $IPTABLES -t nat -A OUTPUT -m owner --uid-owner tornet_user -j DNAT \ --to-destination 127.0.0.1 # Use DNAT instead of nat # Any traffic from tornet user if not redirected to tor, redirected to localhost. # If no services in localhost can accept this traffic than this packets dying quietly in our localhost. I test this rules with sniffer and cannot see any DNS leakage and everithing is works fine. Any possible vulnerabilities here? Rather than to just DNATing all un-REDIRECTed traffic of tornet_user to local host, I wonder whether it would be safer to direct udp tcp traffic to a particular port where you explicitly DROP (or REJECT) it. Something along the lines of: DROPDEAD=12345 $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner tornet_user \ -j REDIRECT --to-port $DROPDEAD $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner tornet_user \ -j REDIRECT --to-port $DROPDEAD $IPTABLES -t nat -A OUTPUT -m owner --uid-owner tornet_user \ -j REDIRECT $IPTABLES -A INPUT -p tcp --dport $DROPDEAD -j DROP $IPTABLES -A INPUT -p udp --dport $DROPDEAD -j DROP (BTW, DNATing to localhost for a locally generated packet is the same as REDIRECT.) Also, it looks to me like the following rule is not needed, as any packets that would match have already been RETURNed. $IPTABLES -t nat -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT
Re: Version checking (was Re: 25 tbreg relays in directory)
Tripple Moon wrote: IMHO, all and i mean *all* modifications of the original code and/or design should be committed to the development-tree, that's how things get improved and fixed etc by the community that maintains the development of the project. The problem with your logic (leaving aside the questions of whether it is desire or doable) is that it is *source* code that gets committed to the development tree, but you are wanting to authenticate against *object* code (at least that's what it used to be called), i.e., binaries. If there were a way to authenticate against *source* code (yeah, right) then your plan might be doable, even if not desirable. But when I compile my code (and I do), the resulting binary is dependent on the particulars of my system. I suspect if I compiled it on two different machines (and I have) I would get two different binaries even when I start with the same source. If the tor application wont get means to authenticate itself's internals, then im afraid (IMHO) we will be looking at a future with *many* independent tor networks who are not connected to each others cloud because of differences... The need is for the code to be interoperable. Interoperability is a much lower threshold than authenticating binaries people run. Presumably your desire to authenticate stems from lack of trust -- i.e. fear of an attacker. But attackers are (or can be) clever and I don't think that even in *prinicple* you can reliably authenticate w/o requiring things that would destroy anonymity. That is, before you can trust me, you have to know who I am (with certainty) and what I am doing. If you don't know who I am I can tell you anything I want (such as what binary I'm running) and you won't know the difference.
Re: Version checking (was Re: 25 tbreg relays in directory)
By remotely calculated CRC-value of the client i mean that the destination does the CRC calculation of the connecting client. Yes this means the client needs to send all of its binary-self to the destination. That would be a pretty big upload for a dial-up user! I am also wondering what kind of danger you think a *client* can have for the Tor network. And if somebody wanted to circumvent, I would think the client could be modified so that when it claimed to be uploading itself, it was actually uploading a copy of an unmodified binary. Am I missing something? Also what would be gained from a CRC based on the *binary*? Wouldn't that change according to the system that compiled it?
