Re: Is "gatereloaded" a Bad Exit?
On 2/15/2011 5:00 AM, morphium wrote: 2011/2/14 Julie C: If this BadExit policy is being made up ad-hoc, that's fine by me. If the offending Tor node operators want to stand up and defend themselves, or their choices, that's fine too. So, I as a Tor Node Operator now have to defend myself, because it's a priviledge to run a Tor node, not a service to the community? Guys, whats up with you? I hate to continue a clearly dead-end argument, but have you ever volunteered, well, *anywhere*? If I were, say, volunteering to build houses for the homeless, and I started going off on my own, ignoring all guidelines, and hammering around wherever the fuck I wanted, I'd expect to either be asked what the hell I was doing (and allowed to continue given good reasoning), or be booted off the project. "I have my reasons for doing this, trust me" is not good enough. The same logic applies to nearly any volunteer or community service situation you could get yourself into. You wouldn't be allowed to re-arrange books at a library without explaining yourself, just as you shouldn't expect to run a broken- or malicious-looking Tor node without a heads-up to the community. Running a node is indeed a community service; however, all community service requires some degree of responsibility. If you're really in a position where such a responsibility would endanger you (or you're simply defiant to the point of rebelling against responsibility when you're told it's expected of you), then yes, I expect you to be limited to the "safe zone" of being a middle node until you explain yourself or grow the hell up. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is "gatereloaded" a Bad Exit?
On 2/14/2011 7:48 AM, grarpamp wrote: [snip] If another example is needed, not that one is; Corporate, edu and other LAN's sometimes think they can block 'ooo, encryption bad' ports so they can watch their user's plaintext URL's with their substandard vendor nanny watch tool of the day. All the while their staff laughs at them as they happily tunnel whatever they want over that (perhaps even the client or exit parts of Tor). Yes, this kind of joke exists :) [/snip] Although I've been keeping out of this argument for the most part, and even though I'm leaning towards seeing things Mike's way, I just wanted to comment that I've actually been in an environment like this several times, once at my previous university, and once working for a local government organization. As asinine as such reasoning is on the part of the network administrator (or the person who signs their checks), I can see why the *ability* to run strange exit policies could be a good thing, and should be preserved in the software. However, I see no reason why providing an anonymous contact email would be so hard. Certainly if you're going out of your way to avoid [insert conspiracy of choice] in order to run a node, you have the skills to use one of the hundreds of free email services out there? I don't think asking for a tiny bit of responsibility on the part of exit operators is too much to ask, and I'm amazed that "allow them to continue to function as middle nodes until they explain why their node appears broken or malicious" is continually being turned into some kind of human-rights violation. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excluding exit nodes
On 2/13/2011 10:19 AM, Tomasz Moskal wrote: [snip] How someone can recognise if an exit node *might* be doing something suspicious - like sniffing traffic for passwords? As far as I can tell (with my limited knowledge that is!) it's by checking which ports the node in question is making available. And if there are not the standards one then it *could* do something nasty - which of course don't mean it does. Could you clarify this whole "rouge/bad/evil" nodes matter I think it's worth mentioning that as an end-user you might be focusing on the wrong issues here. While there *may* be some nodes (exactly which is perpetually unknown) that record unencrypted traffic, it's more important to make sure that your private data (such as login credentials, text containing your whereabouts, etc) is encrypted end-to-end than to worry about excluding every "possibly bad" exit node. For example, it's much easier to use the https version of a website instead of http to protect a username/password combination than it would be to hunt down anyone who might be trying to record your http connection (as recording the encrypted https traffic would yield them nothing). The same logic applies to other tools as well, examples being using the encrypted ssh and sftp over telnet and ftp, respectively. See https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#CanexitnodeseavesdroponcommunicationsIsntthatbad if you haven't already. To answer your other question, as I understand it, the traditional definition of "bad" exit nodes has been ones that manipulate (actually change, rather than simply record) data as they pass through the node. These nodes are automatically awarded the "BadExit" flag and are not used as exits, so the end-user need not worry about them. Exactly whether using an asinine exit polixy should cause a node to be considered malicious has been a point of argument over the last week or so here, and relates only to the sniffing of unencrypted traffic. So again, make sure to use encrypted protocols wherever possible, and don't send any personally-identifiable information when forced to use unencrypted protocols, and you should be fine. Others will be better able to answer the other questions you had. Good luck, and stay safe! ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: advice on using accounting...
On 2/10/2011 6:34 PM, Roger Dingledine wrote: On Thu, Feb 10, 2011 at 06:19:27PM -0500, Joseph Lorenzo Hall wrote: I run a no-exit relay that can sustain about a hundred KB/s but I need to limit to about 4 GB/day to stay under bandwidth caps. I have accounting set up but what happens now is that it blows through that in 12 hours and then hibernates until the next day. Sounds reasonable. [snip] I've been meaning to ask about this for awhile. Is it more helpful to the network to have (using this example) a node running at 100KB/s for 12 h/d, or limit it to 50KB/s and have it run 24/7? At what point does speed outweigh uptime (or vice versa)? ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IP address blocked on certain site
On 2/3/2011 10:23 PM, Robert Ransom wrote: On Thu, 03 Feb 2011 22:21:34 -0500 "Aplin, Justin M" wrote: On 2/3/2011 8:28 PM, Joe Btfsplk wrote: I am using Torbutton. It is supposed to Torrify Firefox - yes? In a roundabout way, yes. Torbutton forwards Firefox traffic to Polipo, which in turn sends the traffic to the SOCKS port of Tor. Disabling Torbutton and entering the Tor SOCKS information into Firefox's network configuration would skip the Polipo part, and eliminate any problems you might be having with some hidden Polipo cache. Turning off 'Use Polipo' in the Torbutton Preferences dialog would be easier and much safer. Robert Ransom Do this. I haven't used Tor as a client in months, I'd completely forgotten this was an option. My bad. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IP address blocked on certain site
On 2/3/2011 8:28 PM, Joe Btfsplk wrote: I am using Torbutton. It is supposed to Torrify Firefox - yes? In a roundabout way, yes. Torbutton forwards Firefox traffic to Polipo, which in turn sends the traffic to the SOCKS port of Tor. Disabling Torbutton and entering the Tor SOCKS information into Firefox's network configuration would skip the Polipo part, and eliminate any problems you might be having with some hidden Polipo cache. Everything else you mentioned points to you using Firefox and Tor properly, I'd try either skipping Polipo (really only a testing solution, as by not using Torbutton, you lose all the other goodies it gives you (beyond simple SOCKS configuration), and would have to change Firefox's network config every time you wanted to use or stop using Tor). If it's indeed a Polipo problem and that fixes it, Geoff's solution seems like it would make a rather nice permanent solution for you. You could skip right to that if it sounds easier than screwing around with Firefox's network configuration. On 2/3/2011 8:35 PM, Joe Btfsplk wrote: Don't know what would have to do to clear mem cache from Fx activity - shut down computer? (assuming memory caching was enabled) Simply close the process. The memory cache disappears along with the rest of the rest of the process. No fenangling necessary. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IP address blocked on certain site
On 2/3/2011 5:53 PM, Geoff Down wrote: ... Neither could I. It may be entirely in memory. Nevertheless that was the conclusion I came to. It's not the IP address being cached, it's the response from the site I would say. Your new request is never being sent (via your new IP) because Polipo is returning the cached version of the page IMO. Anyone have other ideas? GD Before he goes through all that trouble, wouldn't it be worth just SOCKSifying Firefox to use Tor directly, rather than Polipo? If it's some hidden cache issue with Polipo, the issue would disappear then, no? Also he mentions opening a new tab, but never says he cleared the Firefox cache; could Firefox itself simply be fishing the page up from memory? A simple tools > clear everything would be a decent test. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: torr file question...
Simply edit the torrc while both Tor and Vidalia are closed. Vidalia edits the torrc file when changes are made using its interface; upon starting up, however, I believe it gathers its parameters directly from the torrc. In my experience when I write a custom torrc with Tor and Vidalia closed, and then start Vidalia (which in turns starts Tor), my custom torrc is overwritten, but upon careful observation of the new file, it can be seen that each of my settings remains the same, although reordered and with added header comments. I do wish there was a "do not edit torrc" or "confirm before editing torrc" option in Vidalia, but generally the changes it makes are harmless. C'est la vie. ~Justin Aplin On 2/3/2011 4:56 PM, Zaher F. wrote: i am usingVidalia Bundle 0.2.1.29-0.2.10 and i found in my torcc file this : This file was generated by Tor; if you edit it, comments will not be preserved # The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it # If set, Tor will accept connections from the same machine (localhost only) # on this port, and allow those connections to control the Tor process using # the Tor Control Protocol (described in control-spec.txt). ControlPort 9051 # Where to send logging messages. Format is minSeverity[-maxSeverity] # (stderr|stdout|syslog|file FILENAME). Log notice stdout # Bind to this address to listen to connections from SOCKS-speaking # applications. SocksListenAddress 127.0.0.1 so how i can control and fix or define my exitnode thx
Re: Polipo bug reporting
On 1/31/2011 7:58 PM, Geoff Down wrote: The difference is that the PPC bundle with vidalia 0.2.9 was built on a 10.3.9 ppc mac. However, the 10.3.9 machine died a smelly, melty death during a build a few months ago. Is nobody freecycling one? http://www.freecycle.org/group/US/ GD I may be wrong about this, but I believe it's more of a software issue than a hardware one. The last version of Xcode produced for 10.3 is known to produce some wonky, apparently random errors in some applications when they are run on 10.4 and 10.5. I imagine that 10.4 and above are much more prevalent on current live machines (although I'd love to see some hard data either way on that one), so given one dedicated PPC build machine I imagine the emphasis should be placed on producing stable applications for 10.4 and 10.5 (10.6 being Intel-only). Xcode for 10.5 is known to produce applications that play fairly nice with 10.4, but again, things sometimes get wonky with 10.3 (and then again, sometimes not). That's not to say, of course, that if you happened to find and old mac and some 10.3 disks laying around, that a donation wouldn't be appreciated =) ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Per-Tab Torbutton
On 1/25/2011 1:25 PM, Jerzy Ćogiewa wrote: Hello Is it possible to have Torbutton activate Tor only on specified tabs and not others? It would make Tor much more useful. So far this is not possible, no. There is an ugly, but workable, solution in using Firefox's profile manager. By creating two separate profiles in the profile manager (by running Firefox with the -profilemanager switch) and creating two shortcuts/links with respective -P "yourprofilename" switches, it is possible to run two separate instances of Firefox, one of which is free to use Torbutton while the other does not. Until Firefox provides a way to isolate tabs as individual processes, I don't see such a feature being implemented. ~Justin Aplin | |
Re: Is "gatereloaded" a Bad Exit?
On 1/31/2011 6:05 AM, morphium wrote: 2011/1/31 Mike Perry: So when I said in my earlier post that we don't need exit capacity that bad, I meant it. Thanks, but no thanks. You are contributing negative productivity, and none of the non-bitorrenting exits really will notice your absence in terms of load. Please direct yourself towards the nearest forbidden lake. So, to summarize that, you are saying to every operator that is not your opinion: We (as the Tor project) don't need you. Thats... pretty arrogant. I'm not sure how that's arrogant at all. These nodes aren't exit-flagged, have suspicious (though maybe not damning) "exit" policies, and have no or fake contact information. They're either malicious or horribly configured, and in either case there's no way to get in touch with the operators. Strong odds are they're doing the network (and its goals) more harm than good, so they're removed from it (note that there was no IP ban, so the operators are free to return to the network if they so choose). Honestly, it seems to me that this is the Tor Project equivalent of a slap on the wrist; a much stronger, more irrational decision could certainly have been elicited. I'm operating under the assumption that we run our nodes to further the goals of the Tor Project and help the community. I'm not sure why removing exits with idiotic or malicious configurations (until the operator either fixes them or explains themselves) is a bad thing. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Question about torbrowser for mac
On 10/27/2010 6:16 AM, Erinn Clark wrote: This is actually a weird Firefox thing -- depending on where you install the extensions, they either show up in the add-on list or they don't. The Torbutton extension is installed somewhere different from the other extensions, because that was how I got it to work originally. So it's installed, and it works, it's just some accidental ninja obfuscation happening. (Incidentally, it *does* show for me on 10.5, so it took me a while to figure out what was happening.) BTW, does the Torbutton toggle button show in the bottom right of the browser for either of you? Odd that we're both running 10.5 and seeing it differently. No, I can't see the toggle button, but I rather thought that was intentional. What's the point of using the browser bundle if you're going to disable Tor? Personally I'd use another browser instance for any non-Tor browsing. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: several Tor crashes
On 10/18/2010 9:34 AM, Joe Btfsplk wrote: BTW, I don't see (or remember) the 'keys' folder or 'fingerprint' file - don't remember seeing them in past. My bad. These files only show up when one is running a bridge/relay/exit node. The majority of my work with Tor is setting up and running exit nodes, so I'm in the habit of thinking about installations in that light. These files won't show up if you're only accessing the Tor network as a client. Re: Vista permission. It's not that the alpha ver didn't run - quite a while in fact - before crash. Seems if was a permissions issue, would've seen probs right off when started using Tor? Based solely on the two errors I've seen from your logs, I can only guess that there is either some sort of permissions issue (which could include a rogue process, possibly Tor itself, changing permissions while Tor is running), or that some process is accessing the lock/state files and preventing Tor from interacting with them properly. I chose the "nuke the unnecessary files" approach first because if it worked, it'd be the quickest and easiest fix. The slightly-more-involved approach would be checking permissions, etc. The pain-in-the-ass approach would be rooting around in your system trying to find out what's going on, filing bug reports, etc etc. I tend to start with the quick & easy attempt at fixing the problem because I'm exceedingly lazy =) ~Justin Aplin On 10/18/2010 8:23 AM, Joe Btfsplk wrote: Thanks Justin, Good info for the future. Right now, really busy (job search) so went back to stable ver of Vidalia bundle - for now. Your suggestions may well have solved probs w/ current alpha ver, but from my exper w/ vidalia / tor for couple yrs, this was a new development crashing (multiple times - same apparent reason). Does suggest alpha ver needs some tweaking (that's why it's "alpha"). If get more time to test, will try your suggestions. Hopefully, others will find the post useful. On 10/16/2010 12:11 AM, Justin Aplin wrote: The very first thing I would try is simply getting rid of the files and allowing Tor to recreate them. Personally I'd shut down Tor and delete the 'lock' and 'state' files, along with any file or folder starting with 'cached', and then restart Tor. Make sure not to touch the 'keys' folder or the 'fingerprint' file. If the issue shows up again, the next thing I'd try is double-checking the permissions on the Tor appdata folder, along with *every folder above it down to the root*. I had a similar issue trying to run Tor as a system service where I needed to grant the system service user explicit permissions to every folder leading up to the Tor appdata folder. I haven't played with Vista permissions, though, so YMMV. Let us know how it turns out, and what fixes it. ~Justin Aplin On Oct 15, 2010, at 3:03 PM, Joe Btfsplk wrote: since upgrading to Vidalia 0.2.2.17a couple days ago, Tor has crashed 2x now after running for quite a while each time. Crashes were an hr? or more apart. Seemed to be running fine during those times, up to the crashes. Rarely did I ever have Tor stable versions crash in past (over many vers). If I report this as bug, what else should I include in report? Vidala log errors: Oct 15 12:59:21.741 [Warning] Error replacing "C:\Users\name>\AppData\Roaming\tor\state": File exists Oct 15 12:59:21.743 [Warning] Unable to write state to file "C:\Users\\AppData\Roaming\tor\state" Note: the user\AppData path is not protected - the acct I was running in Vista at time of Tor crash has full access to the paths \ files mentioned above. The file: state.tmp DOES exist in the location mentioned. I can open / read - state.tmp - (after Tor crash & Tor is shut down). Has no obvious errors msgs in the file. Is another file: "lock" (w/ 0 bytes) in same folder as state.tmp (after crash & Tor / Vidalia are shut down). Properties of the "lock" file show was created yesterday 10/14, & last mod 10/15. Its file attribs are "AN" - archived, not indexed? Other than that, no real info on it. Err Rpt from Windows Vista x64 prepared to send to MS: Problem signature: Problem Event Name:APPCRASH Application Name:tor.exe Application Version:0.0.0.0 Application Timestamp:4ca65e57 Fault Module Name:tor.exe Fault Module Version:0.0.0.0 Fault Module Timestamp:4ca65e57 Exception Code:c005 Exception Offset:000c3bf9 OS Version:6.0.6002.2.2.0.768.3 Locale ID:1033 Additional Information 1:fd00 Additional Information 2:ea6f5fe8924aaa756324d57f87834160 Additional Information 3:fd00 Additional Information 4:ea6f5fe8924aaa756324d57f87834160 Any suggestions? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *
Re: several Tor crashes
On 10/18/2010 9:23 AM, Joe Btfsplk wrote: Thanks Justin, Good info for the future. Right now, really busy (job search) so went back to stable ver of Vidalia bundle - for now. Fair enough. Better one more working node on the network than a broken one you don't have time to play with. Your suggestions may well have solved probs w/ current alpha ver, but from my exper w/ vidalia / tor for couple yrs, this was a new development crashing (multiple times - same apparent reason). Does suggest alpha ver needs some tweaking (that's why it's "alpha"). If get more time to test, will try your suggestions. Hopefully, others will find the post useful. I can only speak of my own experience running the alpha on my WinXP machine, which has been flawless so far, but this is the first time I've seen this particular error mentioned, so I'm not convinced it's a problem inherent in the alpha. That said, alpha builds are listed as unstable for a reason, and I don't keep myself updated on all the bug reports, so a grain of salt is warranted. I'm assuming that you downgraded your Tor bundle by using the packaged uninstall utility, which on Windows deletes all settings directories by default. These would have been recreated when you reinstalled the old version, which *could* have corrected some permissions issues. I'm wondering if reinstalling with the alpha version would have yielded the same results. Or something else entirely about your setup could be giving Tor indigestion. It's really a "poke it until it works" sort of situation (and I encourage a good and thorough poking if/when you get the time). ~Justin Aplin On 10/16/2010 12:11 AM, Justin Aplin wrote: The very first thing I would try is simply getting rid of the files and allowing Tor to recreate them. Personally I'd shut down Tor and delete the 'lock' and 'state' files, along with any file or folder starting with 'cached', and then restart Tor. Make sure not to touch the 'keys' folder or the 'fingerprint' file. If the issue shows up again, the next thing I'd try is double-checking the permissions on the Tor appdata folder, along with *every folder above it down to the root*. I had a similar issue trying to run Tor as a system service where I needed to grant the system service user explicit permissions to every folder leading up to the Tor appdata folder. I haven't played with Vista permissions, though, so YMMV. Let us know how it turns out, and what fixes it. ~Justin Aplin On Oct 15, 2010, at 3:03 PM, Joe Btfsplk wrote: since upgrading to Vidalia 0.2.2.17a couple days ago, Tor has crashed 2x now after running for quite a while each time. Crashes were an hr? or more apart. Seemed to be running fine during those times, up to the crashes. Rarely did I ever have Tor stable versions crash in past (over many vers). If I report this as bug, what else should I include in report? Vidala log errors: Oct 15 12:59:21.741 [Warning] Error replacing "C:\Users\name>\AppData\Roaming\tor\state": File exists Oct 15 12:59:21.743 [Warning] Unable to write state to file "C:\Users\\AppData\Roaming\tor\state" Note: the user\AppData path is not protected - the acct I was running in Vista at time of Tor crash has full access to the paths \ files mentioned above. The file: state.tmp DOES exist in the location mentioned. I can open / read - state.tmp - (after Tor crash & Tor is shut down). Has no obvious errors msgs in the file. Is another file: "lock" (w/ 0 bytes) in same folder as state.tmp (after crash & Tor / Vidalia are shut down). Properties of the "lock" file show was created yesterday 10/14, & last mod 10/15. Its file attribs are "AN" - archived, not indexed? Other than that, no real info on it. Err Rpt from Windows Vista x64 prepared to send to MS: Problem signature: Problem Event Name:APPCRASH Application Name:tor.exe Application Version:0.0.0.0 Application Timestamp:4ca65e57 Fault Module Name:tor.exe Fault Module Version:0.0.0.0 Fault Module Timestamp:4ca65e57 Exception Code:c005 Exception Offset:000c3bf9 OS Version:6.0.6002.2.2.0.768.3 Locale ID:1033 Additional Information 1:fd00 Additional Information 2:ea6f5fe8924aaa756324d57f87834160 Additional Information 3:fd00 Additional Information 4:ea6f5fe8924aaa756324d57f87834160 Any suggestions? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the b
Re: vidalia source tarball is missing
On 10/11/2010 6:21 PM, Erdem Bayer wrote: Can someone please replace the tarball or update download URL? Not a fix, but the source you're looking for can be found here: https://www.torproject.org/dist/vidalia/vidalia-0.2.9.tar.gz ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BetterPrivacy - necessary?
On 9/29/2010 2:19 PM, Matthew wrote: I currently use Tor + Polipo + Torbutton + NoScript. Obviously there are other add-ons for Firefox out there such as BetterPrivacy. Are any other add-ons necessary or would people suggest I am now fully protected? Thanks. There is no such thing as being "Fully protected". Personally, as long as you don't have a three or four-letter agency after you, and are making SURE that all personally-identifiable information you enter is encrypted (under HTTPS or otherwise), I think you should be "protected enough" for most purposes. ~Justin Aplin
Re: A few questions and potential answers:
On 9/20/2010 4:22 AM, David Bennett wrote: Bad Guys == Anyone blocking or monitoring a persons access to knowledge Granted. Q: What is to stop operatives working for the bad guys from running tor proxies from 3rd party locations? Granted, they would only be able to sample a portion of the traffic, but traffic that they did sample could lead to identification of users. It doesn't seem like it would be that hard to match up the encrypted client side requests with the un-encrypted outgoing requests. Perhaps I don't understand what you're going for here. If a user is using https (or another client-server encryption protocol), then a "bad guy" viewing traffic without the onion-layer encryption would simply see more encrypted traffic. Even if the user does not (or cannot) use https-like protocols, because each node does not know where along the circuit it lies, this is no more useful than passively monitoring an exit-node's traffic for information. That said, there are plenty of warnings on the project website about this: tor is not magic, and users need to be careful that any unencrypted traffic does not contain any personally identifiable information. PA: The only solution I can think of here is centralized control of the proxy network provided by a press/media sponsorship model as opposed to the bandwidth volunteer model. It's to easy for bad guys to infiltrate the volunteer network. It would also be easier to swap in and out new proxies as they are blocked. runtime selection of alternative proxy networks would be a nice feature. The volunteer model is exactly what keeps tor afloat: nodes appear and disappear all the time, and traffic to many of them looks innocuous, as if they were connecting to any other computer on the net. See below. Q: I have noticed lists like: http://proxy.org/tor.shtml that appears to be a list of tor proxies. What's to stop the bad guys from blocking the entire proxy database? My understanding is that countries like Iran have the national ISP market under their thumb. There are many bridges that are only distributed on request via https://bridges.torproject.org and via email to brid...@torproject.org. These change dynamically enough to keep most users connected. Where access is blocked, mirrors and relays can be found with a little fenangling about search engines. PA: There needs to be a way to deal out proxies to clients without the ability to easily reveal the entire network to anyone. Perhaps even semi-static assignments similar to DHCP. Of course, there is also the problem of 'blocking the dealer' similar to the P2P security issues with trackers. Ultimately, to really make this fool proof, there would need to be a way to communicate proxy dealers offline (verbally / off-network) in a concealable way. See above. As I understand it, as soon as a client can connect to a single bridge, they can then obtain enough information to build circuits without needing to refer to any central authority. Q: How can we address bad guys blocking port 443. PA: Proxies should be able to hide behind other services such as 25,80,110. Also nice would be a 'spoof greeting' feature that would simulate a 'normal' service for that port before a magic code was sent. Of course, the magic code would need to be changeable (possibly dynamically by a proxy dealer). Tor bridges and exits are in no way limited to port 443. My exits currently use port 9001, with directory mirrors on port 9050; this is the purpose of the orport and dirport lines in the torrc. I'm not qualified to comment on why the rest of your proposal would or would not be a good idea. Q: What about DPI which can provide encryption protocol info to the bad guys (if not the payload). PA: plug-in packet obfuscation, possibly agreed upon between proxy and dealer and embedded in a magic code given by the dealer to the client then provided back to the proxy in the request header. This could be implemented by means of a tiny secure VM that ran small byte-code obfuscator programs shared between proxy and dealer and referenced by the magic code. Even though the bad guys could run the VM de-obfuscator, it would be challenging to implement at OSI levels 1-4 given current technology. The ultimate idea would be to keep the Bad Guys busy chasing their tails and break them through over investment in competence. As they attempt to keep up with the changing methodologies they become victims of their own system of control, meanwhile they have less time to do their normal bad guy stuff. Basically, the circumvention tool itself becomes an agent provocateur. Again, not qualified. I hope someone will provide a better answer to this. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On 9/10/2010 5:29 AM, Scott Bennett wrote: Even if an editor were available that could handle line lengths great enough to allow placement of each entire list onto a single line in torrc, I'm still in astonishment, wondering how I can actually exclude the nodes that should be excluded. I'm not really sure I'm seeing what the problem is. You mentioned ~170 nodes; a quick copy and paste of 200 40-bit fingerprints yields an 8400-character line (including $s and commas), which is easily handled by Nano on my Linux machine and Notepad++ on my Windows box. I'm sure Pico under OSX would work just as well. I can see why you would be upset that your comments are rendered useless, and that your nicely-formatted torrc is now has to be a bit uglier, but your overall goal shouldn't be affected: just plop them all on one line and you'll at least get the functionality you've been shooting for. ~Justin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Why does this happen?
On 9/9/2010 12:00 PM, Udo van den Heuvel wrote: Try to use ntp... I imagine this is either a case of the BIOS clock not being set to GMT, or the incorrect time zone being selected in the OS. The easiest solution, I think, would be to double-check your timezone setting and enable NTP. If that's already been done and the correct time for your area is being displayed, then I wouldn't worry about it. Keep an eye on your logs and see if it happens with every directory server, or if it was just a one-time issue. ~Justin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Google and Tor.
On 8/25/2010 8:52 PM, Mike Perry wrote: Thus spake Matthew (pump...@cotse.net): On numerous occasions when using Google with Tor (yes, I know there are other options like Scroogle) it claims I might be sending automated queries and gives me a CAPTCHA. Sometimes this allows me to search; other times I am caught in a loop and am constantly send back to the CAPTCHA screen. This has been a known problem with Google for ages. (snip) Really? I've never had this problem until recently. For about 2 years now every Google CAPTCHA I've run into has been uneventful and let me through after the first try, only in the past month or so have I been getting caught in the "CAPTCHA loop". ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Google language turns depending on tor node...
On 6/19/2010 10:22 AM, emigrant wrote: when i give a keyword to search, in most cases, i get results in languages i cannot read. is there any way to keep it always to english? There are many ways to do this listed in the FAQ. Please see: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#WhydoesGoogleshowupinforeignlanguages ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Downloading attachments with Tor - is this secure?
Yes, if you use Torbutton, the attachment itself will be downloaded only via Tor. I believe this is the short answer to your question, though everything else Mike said is good to keep in mind as well, especially in situations where paranoia is appropriate. This is especially dangerous if you are using Yahoo Mail, because even if you trust the person who sent you the document, your attachment will be downloaded in plaintext (via http, not https). Watch out for this. Yahoo's *login* page for webmail and other services may be HTTPS, but this reverts to plain HTTP once you're actually viewing your mail and downloading attachments. A simple solution for secure webmail at the moment is using Gmail and the new Firefox addon "HTTPS-Everywhere" available from https://www.eff.org/https-everywhere . This addon is *NOT* magic, as it only works with the particular list of websites available on its option page, but making sure "Google Services" is checked in it's options will allow all Gmail connections (including downloading attachments) to happen over HTTPS. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Downloading attachments with Tor - is this secure?
On 6/18/2010 3:06 AM, Matthew wrote: Apologies in advance for the basic-ness of this question. I cannot find the answer with Google or in the Tor documentation. I believe the answer you're looking for is #4 here: https://www.torproject.org/download.html.en#Warning In these cases, how is the file downloaded? Does the download happen through HTTP/S? If I am using Polipo and Tor then I assume the file is downloaded as HTTP/S and goes through the Tor nodes like any "normal" HTTP/S traffic. This depends on where you're downloading from. Tor encrypts everything between you, the clients in your circuit, and the exit node. However, when traffic enters or leaves the exit node, it is *exactly* as if the exit node were visiting that website for itself. So, if you are downloading over standard HTTP, *nothing between the website and the exit node will be encrypted*. This usually isn't a terrible problem with downloads that don't contain any personal information that leads back to you, as it would be extremely difficult to follow the encrypted data over several hops through the network. *However*, as the documentation says repeatedly, use HTTPS wherever possible, *especially* when communicating sensitive information that could lead back to you. This way, the traffic between the exit node and website is encrypted, and doubly so between you and the exit node. Much less will be gained by examining the traffic coming to/from the exit. Hope that answers your questions. (Side Note: the above does not pertain to .onion websites or other hidden services, which are contained completely within the network.) ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
No fingerprint in "Notice" level log on Windows
This may be borderline nitpicking, but a nice feature I've noticed when configuring my PPC machines is that Vidalia catches a line from the log starting "Your Tor server's identity key fingerprint is...". I've found it's useful to have at a glance in a number of testing and configuring situations. None of my Windows machines seem to show this; both are let at log level "Notice". I haven't had time to play with different log levels yet, maybe I'll get to it this weekend. Plus my Windows server has been getting a lot of traffic today, I feel bad restarting it lol. Is anyone else as anal as me about noticing things like this? ~japlin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gwget and tor?
On 5/26/2010 7:39 AM, emigrant wrote: is there a way to use gwget with tor? most of the times i download a direct link in tor enabled firefox it stops in the middle despite the internet connection is good. I don't know about gwget, but plain wget supports http proxies, which you can point at Polipo. If you're only going to need to do this every once in a while, I'd pop open a terminal and do the following: HTTP_PROXY=127.0.0.1:8118 && HTTPS_PROXY=127.0.0.1:8118 && FTP_PROXY=127.0.0.1:8118 export HTTP_PROXY && export HTTPS_PROXY && export FTP_PROXY wget your://url.to/download.here If that doesn't work for you, open your Polipo configuration file and see what port it's set up to run on, and change the bit after the colon in the environmental variables. Wget will pick up on the environmental variables and should route your download through Tor. These settings will only last until you either close the shell, or until you log out (I forget which and can't make it to my linux box to check), so if you'll be doing this a lot you can add the following lines to your .wgetrc file to have them executed automatically: proxy = on HTTP_PROXY = 127.0.0.1:8118 HTTPS_PROXY = 127.0.0.1:8118 FTP_PROXY = 127.0.0.1:8118 To resume an interrupted download, just add the -c option, like so: wget -c your://url.to/download.here thanks. Anytime =) ~japlin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Exit Node hosting: torservers.net
On 5/25/2010 7:39 PM, Curious Kid wrote: Yes, of course it should be obvious that it is not sponsored by The Tor Project. Maybe it's just me, then. I tend to assume that anything not on the official website isn't sponsored by the official project, unless they make a point of explicitly saying "Sponsored by...". If that's not as general an assumption as I would think, then perhaps it does bear making the point clear. I take it you didn't see the favicon. Look again. Fair enough, that is a tad misleading. People in the past have created "non-competing" companies that used the Tor name to increase their profits. This will be a contention point. Most of me hopes this is an honest effort at contributing to the Tor project. Of course, that hope includes the big assumption of things like, all donations being used to cover costs (no profit), and all sponsors getting their donations back if the new relays never get off the ground. Big hopes and big assumptions; time will tell I suppose. It should not be in very small letters in the most hidden spot. Frankly, the leadup posts in the mailing list raised red flags for me that it would deliberately try to look like part of The Tor Project. Again, maybe it's just me, but it was clearly visible on my screen when I brought the page up. I haven't seen anything come out of his own mailing list yet, but you can be sure I'll be watching it closely. Cautious optimism is the way to go with any new project like this, methinks. ~japlin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT] another proxy, but not open source :-(
On 5/25/2010 6:22 AM, Scott Bennett wrote: "Proprietary" means the client companies pay for it, right? Which means they are funding its development, right? Windows Server releases are closed source, right? And client companies install and use it, right? Now, none of that tells us "how many large contributors would be willing to install closed-source software that they're not involved in developing on their servers", but I should think that the number may be fairly large. Ha, I see your point. Although by "large contributors" I was thinking of those awesome souls to run our heavy-duty relays and not corporations. A quick run-through of our top 50 contributors shows 47 Linux boxes and 3 FreeBSD boxes. I guess I'm just biased into thinking it's the open-software nuts who most support the cause ;-) ~Japlin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT] another proxy, but not open source :-(
On 5/25/2010 4:59 AM, Scott Bennett wrote: You may well be assuming too much. It's not easy to know at this point because it's still undocumented vaporware. I still think the whole thing smacks of being a honeypot for gullible humans. I'll admit I could be totally off base. But it's 5 in the morning and I honestly can't think of another way they could implement what they're trying to do (effectively, anyway) without an enormous infrastructure. Cheapest way to create one seems to be distributing your free software and having your users act as... oh wait, somebody thought of that already! Well, that, at least, happens all the time. How many installations of Windows Server 200[38] would you guess there are, for example? Maybe I've been out of the game for too long, but in my experience proprietary software is used either because it works well, or because it comes with support (i.e. insurance). The Windows servers, for example, work well in corporate environments running a large number of Windows machines in a Domain, and often said corporation will purchase support to go with it. It's worth the cost to keep things running (somewhat) smoothly. If you have a free alternative that works just as well and can be maintained by your staff without too much ado, odds are it will be used. Apache on *nix comes to mind as one example, as opposed to IIS. So if we have two free softwares, one open-source and one closed-source, neither with any *explicit* support, the choice is going to come down to which one works better, and which one looks better. If they put out a crappy product, odds are it'll get uninstalled by the majority of users who just don't want to bother fucking with it. If it's a decent product, however, and it has a decent UI, and their production team can keep up with releases and bugfixes and whatnot, we may be in for some viable competition. We'll see. Somehow I doubt it. China has done that at least once already. They apparently managed to get ~80% of what the bridge authorities had at the time, IIRC. Yet the remainder continued to operate and serve many people in China during that time. And bridges come and go, just like ordinary relays. Many are on dynamically assigned IP addresses, so their addresses change, thereby invalidating those data in the Chinese government's list. The picture in my head reminds me of this, for some reason: http://xkcd.com/350/ I am a tad unnerved at the number of links to the donation page, though I appreciate the costs associated with such an endeavor. Indeed. As an aside, they do have a shiny-looking website, and I won't pretend users aren't attracted to that. We could do with a little shininess ourselves. Still though, pandering for donations when you're not even offering any sort of product or service... honeypot indeed. ~japlin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/