Re: Load Balancing
On 9/22/07, Roger Dingledine [EMAIL PROTECTED] wrote: Once upon a time, the value of 10 minutes was actually more like 1 minute. You see, the shorter it is, the fewer actions from the user are linkable with each other based on being in the same circuit. But Tor server operaters complained they were using 100% cpu because they were constantly handling new circuit creation requests. So we moved it back to 10 minutes -- bad for user security, but necessary to keep things working. If the user started churning through circuits at five times the current rate, we may end up forced to move the 10 minute value back even farther to compensate, resulting in even more user connections becoming linkable. Why does new circuit creation use up so much CPU? Are you spawning a new thread for each circuit, or something? If so, maybe there's a way to be more efficient instead? I know, I know, I shouldn't complain if I'm not going to offer code. So don't consider this a complaint, just a question.
Re: Filtering traffic from your node - for exit points
On 9/11/07, Martin Senftleben [EMAIL PROTECTED] wrote: Am Dienstag, 11. September 2007 13:11 schrieb Anthony DiPierro: On 9/11/07, Peter Palfrader [EMAIL PROTECTED] wrote: On Mon, 10 Sep 2007, Torified User wrote: If it is in common agreement that tor should not filter, then I'm afraid I'd prefer not to run tor at all :( You could run a non-exit node. That's - imho - preferable to filtering. Or run an exit node which exits only to itself, then run a filtering proxy service which is reachable through that exit node. If enough people did that, we could build a separately directory of such services, and anyone using it would take load off the exit nodes (and maybe get a faster browsing experience to boot?). Are there instructions somewhere on how to go about that? Not that I know of. I basically came up with it myself.
Re: Filtering traffic from your node - for exit points
On 9/11/07, Torified User [EMAIL PROTECTED] wrote: Anthony DiPierro [EMAIL PROTECTED] wrote: Or run an exit node which exits only to itself, then run a filtering proxy service which is reachable through that exit node. If enough people did that, we could build a separately directory of such services, and anyone using it would take load off the exit nodes (and maybe get a faster browsing experience to boot?). Are there instructions somewhere on how to go about that? Not that I know of. I basically came up with it myself. Not sure this can be done. The problem lies that you'd have to preselect an outgoing .exit before this would be feasible. I thought this was handled by exit enclaves. See http://archives.seul.org/or/cvs/Aug-2005/msg00162.html The only solution re: filtering or not filtering lies in having a separate directory server for filtered exit points. (as far as I can tell). Well, yeah, this would handle the directory server mechanism completely outside of Tor. You'd have to specifically set up privoxy to connect to those filtering proxy services through tor.
Re: more letters from the feds
On 1/28/07, Fabian Keil [EMAIL PROTECTED] wrote: Anthony DiPierro [EMAIL PROTECTED] wrote: That brings up an idea, though. Are there certain common perfectly legitimate things that exit nodes are being used for, that maybe some hidden services could be set up to take the load off? I guess the most obvious and perfectly legitimate thing to use exit nodes for is anonymous communication on the net. I don't understand how using hidden services would take off any load though. If a hidden service does the job of an exit node you might as well consider it as one. Hidden services don't require exit nodes, so if exit nodes are the bottleneck, then moving traffic from exit nodes to middleman nodes will improve the entire network. As for if a hidden service does the job of an exit node you might as well consider it as one, I'm not really sure what that means. What if a hidden service does *some* of the jobs of an exit node? Do you count it as part of one? After all it's request IP address will be visible to the public in which case the risk for the operator stays the same (unless requests are routed through the Tor network again, in which case it would only add latency). The risk is the same for the same services, but there's no requirement for a hidden service to, for instance, forward POST requests, which I would think greatly reduces the risk. If one runs an exit node, they're agreeing to forward all requests, not just GET requests or GET requests without any parameters, and not even just HTTP traffic (as was pointed out, any traffic can go over port 80). Anthony
Re: more letters from the feds
On 1/27/07, Seth David Schoen [EMAIL PROTECTED] wrote: Anthony DiPierro writes: Or what about a hidden service for reading web pages in general? Something which doesn't support POST (or maybe even GET), so is much less likely to be used abusively. Is this feasible? The current directory scheme does allow (in fact, requires) policies to be specified in terms of IP addresses and TCP port numbers. So a web browsing only exit node is possible. A port 80 only exit node is possible. This isn't the same as an exit node which can only be used for reading web pages). A GET-only exit node can't be specified with the current directory system, which isn't capable of expressing any information about what an node will do with connections to a particular TCP port other than allow or deny them. You could make an HTTP GET only exit node, but you wouldn't have a way to tell clients that your node enforced that policy, and users would probably get mad (and stop using your exit node entirely) when some of their transactions failed mysteriously. Yes, exactly. What you could do, though, is run a hidden service which provides anonymous HTTP GET-only web access, and you wouldn't have to break any protocols or cause anyone to get mad. *IF* that hidden service became popular, it could potentially take a lot of load off the exit servers. Anyway, just an idea I was throwing out there. The big questions are 1) is there enough traffic which consists only of browsing websites to make it worth it, and 2) are there enough people willing to run HTTP GET-only hidden services to make it worth it? Personally I'd answer a resounding yes to question 1 in that I use Tor primarily for HTTP GET, but as I'm currently on a relatively slow EVDO connection I couldn't answer yes to question 2. Anthony
Re: more letters from the feds
On 1/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Problem still exists though, that Tor needs more exit nodes. If nobody is willing to run an exit server the performance of the network suffers dramatically. If *nobody* is willing to run an exit server the performance drops to zero (at least for all but hidden services). That brings up an idea, though. Are there certain common perfectly legitimate things that exit nodes are being used for, that maybe some hidden services could be set up to take the load off? For instance, one could set up a hidden service to search Google or to read Wikipedia, things which aren't going to attract any negative attention, but which would take the load off an exit server. Or what about a hidden service for reading web pages in general? Something which doesn't support POST (or maybe even GET), so is much less likely to be used abusively. Is this feasible? Anthony
Re: Using Gmail (with Tor) is a bad idea
On 9/21/06, glymr [EMAIL PROTECTED] wrote: why not just use your own client with the socks proxy turned on and access gmail via the pop and smtp they provide (both of which are encrypted, one ssl, the other tls)? I haven't really found any (gratis) clients I like that well, not that I've done a very thorough search. Gmail's filtering does kind of suck, though.
Re: Using Gmail (with Tor) is a bad idea
On 9/18/06, Fabian Keil [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] top posted (please don't): Are you saying that some info gets leaked if you use unencrypted http to transfer mail with gmail? Yes, and some info means everything but your password. And even if you enter through https://mail.google.com/, a man in the middle can send your browser a redirect to http://mail.google.com/, Google then sends your browser another redirect to the encrypted login page on another server and after the secured login you will get redirected back to http://mail.google.com/. OK, so if you're careful, and enter through https://mail.google.com/, you're fine, as long as you don't go to *any* http site before you clear your cookies. But if you log in to gmail, even through https, then you go to a an http site (like http://www.yahoo.com/, for example), then your session can be stolen. Firefox/1.5.0.7 honours an unencrypted redirect as response for a https connection request. You don't get a warning, but of course if you look for it, you can see that the connection is unencrypted. Assuming this can't be turned off, the only real workaround I think would work is to disable the http proxy. This might be realistic, you could switch between three proxy settings, one for normal browsing, one just for gmail/tor (which would send http requests to a proxy at a nonexistant IP address), and one for normal tor browsing. These three settings could be managed through SwitchProxy, which would automatically clear cookies between each one. For those gmail diehards (like me) who want to hide their IP address from gmail (not a bad idea), it might be a reasonable workaround. At that point, however, the man in the middle already has your authentication cookies and I would be surprised if he couldn't take over the session. Of course that'll require greater efforts than some regular expressions. And considering how many sites, including financial sites, are happy to send you a new password by email, getting your gmail session stolen could be really horrible. Anthony
Re: Exit Node sniffing solution...an idea...
On 8/21/06, Michael Holstein [EMAIL PROTECTED] wrote: If you're using TOR, you shouldn't be using your name in the first place (what's the point of *anonymously* identifying yourself?). I know there are other arguments for TOR like defeating geolocation, but if that's all you're after, there are easier ways to do it (like just rent a shell account somewhere and use SSH redirection). /mike. It's not just defeating geolocation. It's about not having your IP address tied to your identity (at least, not without collusion with your ISP). I suppose renting a shell account somewhere and using SSH redirection, only when identifying yourself and for no other purpose, would solve approximately the same purpose. But that's a lot more complicated (and a little more expensive) than just using Tor and making sure you clear your cookies before logging in and after logging out of any services where your identity is revealed. Plus you'd have to have a different SSH account for every single pseudonym you use. Anthony
Re: FW: [Full-disclosure] Tool Release - Tor Blocker
On 6/3/06, 4non ym0us [EMAIL PROTECTED] wrote: If your machine is listening on a public IP, and can be hacked on a completely valid TCP connection (which is the only kind TOR allows -- leaving out most of the tricks hackers use), then you've got bigger problems then tor. I doubt most administrators care about the difference. The concern would be if such a module becomes a standard part of most servers, it would effectively take all static IP TOR routers out of the web and subsequently affecting the desirability of using TOR, wouldn't it? I can't wait until IPv6 finally becomes widespread. On another note, Tor is big and getting bigger. Plus there are a number of Tor nodes that are on dynamic IPs. Blocking them all is going to become more and more painful. Anthony
Aren't exit node names supposed to be unique?
It would seem to me that exit node names should be unique, in part in order for ExcludeNodes to work. But a recent download of the list showed the following (just the two relevant lines): US godzilla3635 B/s 68.42.126.128 MICHIGAN-3 22 53 80 110- 143 443 5190 6667 NO godzilla 25600 B/s 80.203.228.236 NEXTGENTEL-NO 22 53 80 110- 143 443 5190 6667 Does this mean that these two nodes have the same owner/key/etc? Or is it a bug? Or maybe something else? Anthony
Re: Aren't exit node names supposed to be unique?
On 5/24/06, Roger Dingledine [EMAIL PROTECTED] wrote: On Wed, May 24, 2006 at 07:28:37AM -0400, Anthony DiPierro wrote: It would seem to me that exit node names should be unique, in part in order for ExcludeNodes to work. [snip] They have the same nickname, but different keys/owners/etc. As of Tor 0.1.0.x, nicknames are no longer unique. This is the whole point of binding your nickname to your key via the directory authorities: http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CanIJustConfigureAndRun If you use an unnamed nickname (one not already bound by the directory authorities to a particular key) in ExcludeNodes, etc, Tor will warn you that you're ambiguous. You should specify it by key, e.g. $FF8845046DB449DA989B025AEA1D10E19E709166 for the one in Norway. --Roger Thanks for the info. It looks like that perl script on serifos needs to be updated, since nicknames aren't unique. Specifically, the desc.pl takes a query where the variable q is set to the nickname of the router. Now I guess I should look into accessing this information more directly instead of scraping someone else's tor script output :) Anthony
Re: User.Actions Template
On 5/21/06, Fabian Keil [EMAIL PROTECTED] wrote: Anothony Georgeo [EMAIL PROTECTED] wrote: I think it is wise to note that Privoxy can not filter HTTPS. Most non-tech end-users do not know this. I do not block HTTPS connections as I think it is easiser to simply not visit an HTTPS url. How do you convince your browser not to fetch additional images and style sheet through HTTPS? Not actively visiting untrusted HTTPS sites doesn't stop anyone from spicing up his pages with HTTPS content to get more information about his visitors. I thought a browser was supposed to warn you of this mixed content situation (an http site with https images, for instance), but checking Firefox apparently it doesn't! Anyway, it seems like the only proper solution here is to not use privoxy at all, this way https and http both present exactly the same header information. But this of course means taking all the identifying information out of your browser - easier said than done. Anthony
Re: Some legal trouble with TOR in France
On 5/15/06, Mike Perry [EMAIL PROTECTED] wrote: Thus spake Ringo Kamens ([EMAIL PROTECTED]): Also, they can put you on grand jury and give you obstruction of justice for refusing to talk. According to wikipedia (http://en.wikipedia.org/wiki/Grand_jury): In all U.S. jurisdictions retaining the grand jury, the defendant has the right under the Fifth Amendment not to give self-incriminating testimony. [] OK, that covers the defendant, but what if the person in question is not a defendant? Unfortunately, the First Amendment does not seem to apply to questioning by a court (or Congress, for that matter). The Fifth Amendment protects you from being a witness against yourself, but it doesn't protect you from being a witness against someone else. Anthony
Re: Some legal trouble with TOR in France +
On 5/15/06, Ben Wilhelm [EMAIL PROTECTED] wrote: The line is drawn. The line is that Tor does not censor. That's the only line that makes sense, because everything else requires subjective judgement that many would not be able to agree on. There's always the possibility of letting each exit node decide for itself what subjective judgement to make. And in fact that's what is being done. Some exit nodes allow port 25, some don't. Some allow 6667, others don't. Some exit nodes only allow port 80. You can likewise filter by IP address. The only real problem is that it's not feasible to effectively filter out the type of traffic you don't want (especially in a way which can be described in an exit policy). Remember that by default Tor *does* censor. Port 25 is blocked by default. Why is this? Anthony
Is three hops enough? (was Re: Tor client over a SOCKS proxy, and Tor client running through another Tor Circuit)
On 4/27/06, Ringo Kamens [EMAIL PROTECTED] wrote: I don't really see anything wrong with it if you really want to do it. It doesn't really increase anonymity, but it sounds good to me. I'm assuming that tor2 sees the ip address of the tor 1 exit node. The way I picture it it would basically be equivalent to adding extra hops. I remember reading this is possible to hack into the standard tor software, but I believe it requires a recompile and not just a config file tweak. Anyway, it is my understanding that the current default implementation uses three hops. Now am I correct that that includes the exit node? Does it also include the entry node which is generally on the same computer? If so, it seems that in the current default implementation only one compromised node, the middle node (working with the destination site), is needed to significantly impact your anonymity. The IP address of the exit node is generally recorded in web logs along with the time and date. So if the middle node records the incoming and outgoing node IP addresses, that can then be matched up with the web logs. If someone is using three hops the way I described it above, then the incoming IP address would be the address of the tor user, right? Sure, you'd have a little bit of plausible deniability, as there's no proof your system was set up this way, but that's it. Now hopefully I'm just wrong about what constitutes three hops (or that the default setting is three hops). Or maybe I'm missing something as to why this type of attack isn't possible. One thing seems almost certain, adding hops does increase the security against a compromised node attack. Anthony
Re: Is three hops enough? (was Re: Tor client over a SOCKS proxy, and Tor client running through another Tor Circuit)
On 4/28/06, glymr [EMAIL PROTECTED] wrote: Anthony DiPierro wrote: Well, it's a matter of what type of odds are acceptable to you. If 1/100th of circuits are compromised, I'd consider that too high. Now under the diagram I drew above, that'd require about 1/10 of the nodes to be compromised. If you add in another hop, then 1/10th of the nodes being compromised would mean only 1/1000th of circuits were compromised. Or am I calculating something wrong? Anthony yes, in fact more hops means almost nothing relative to the number of compromised nodes. remember, the proportion of compromised nodes is the pool the client picks its hops from, and thus given a random distribution, the amount of compromise risk reduction accelerates quickly to nothing with extra hops, and increases latency unacceptably. The only way to defend against compromised nodes getting two hops in your circuits would be to implement some kind of system to register suspect nodes and instruct the client not to use them. The way I understand it, an attacker would need to compromise all the nodes except for the exit node (and the start node, of course) - *not* that they need to compromise any two nodes in the chain. If there is an attack that can be made, for example, over a 9 hop chain where an attacker only has two nodes compromised, I'm not sure what it is. I suppose there could be some sort of timing attack, one that can't be easily mitigated by cover traffic. Maybe that's what I'm missing. Anthony
