Re: Undeletable cookies
Thus spake Irratar (irrata...@gmail.com): Hello. I have just found a site that can recognize me when I re-accessed it after I deleted all private data, toggled Torbutton and restarted Tor. http://samy.pl/evercookie/ This is news to me. Are you using the default Torbutton settings? When we tested this in the past, Torbutton was protecting against it. I also just tested it now, and it did not recover my cookie. Perhaps one of your other addons betrayed you? Did you enable plugins? Or perhaps you have a misconfigured polipo storing these cookies in its cache? The Tor Browser Bundles are a good way to ensure you have a properly configured, vanilla Tor setup. Of course, it isn't a Tor problem, but I think it's better to know for these who are interested in privacy. many sites may use the same technology stealthy. I will try to discover more about how does it keep my private information. So far this site seems to forgets me when I disable JavaScript, but maybe it just can't display the proper number. Actually, web application layer privacy attacks *are* a Tor issue. We try very hard to protect against them: https://www.torproject.org/torbutton/en/design/#adversary -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp45LsHkPuZg.pgp Description: PGP signature
Re: Contacted by oompaloompa operator: BadExit removed
Thus spake t...@lists.grepular.com (t...@lists.grepular.com): On 16/02/2011 05:10, Mike Perry wrote: I was contacted by the operator of oompaloompa. He has changed the exit policy of his two nodes to the Reduced policy: http://torstatus.blutmagie.de/router_detail.php?FP=775df6b8cf3fb0150a594f6e2b5cb1e0ac45d09b http://torstatus.blutmagie.de/router_detail.php?FP=babbf0694251e5aff7bf3a0a02efdc12cb99b05f Is this one of the guys who didn't have published contact info? I can see he does at the moment... Did he explain why he didn't have it? The contact info there is not a valid email address. He contacted me privately via a different one. Since he hasn't updated his contact info to the new address, I'm guessing he prefers not to list it. I have no personal issues with this. I haven't actually spoken to Roger or Peter yet though, they may feel different (though I doubt it). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpuUwa3TDsh1.pgp Description: PGP signature
Re: Please Badexit:
Thus spake morphium (morph...@morphium.info): Hi, please BadExit the following nodes (for the same reason you badexit'ed gatereloaded et al. - no valid contact info, they didn't explain their exit policy to us, I suspect they are sniffing unencrypted Exit traffic): TORy0 - 753e0b5922e34bf98f0d21cc08ea7d1adeee2f6b TORy2 - f08f537d245a65d9c242359983718a19650a25f7 These are running a slightly modified default exit policy. They allow 443. They are fine by me. st0nerhenge - c2f9d30118bebf3efee6d96252374082ca73c054 Funny you should mention this node. A researcher flagged it once in a test to detect sniffing, but was not able to reproduce it later. Maybe they just turned off their sniffer and got lucky :). There were also serious issues with the methodology though, and it may have been a bug in the scanning technique. However, at this point we are only going after nodes that carried unencrypted versions of both mail *and* web. The reason we did this was because another researcher actually detected another node that he *was* able to reproduce. It had this exact type of exit policy. It calls itself 'agitator'. When we found that sniffer, we looked for other exit policies similar to that one, and found the five here that caused so much controversy. We probably should have came out with all this earlier, but the researcher requested we keep their methodology secret until publication. It also needs some work in the reproducibility dept... At any rate, this node appears to (now?) carry 443. Did it's policy just change? vivalarevolution - 29448afd5251b60a44fc79f4414423e7d026500d Same as Tory0. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp5dLfYdFjyX.pgp Description: PGP signature
Re: Please Badexit:
Thus spake morphium (morph...@morphium.info): 2011/2/15 Mike Perry mikepe...@fscked.org: please BadExit the following nodes (for the same reason you badexit'ed gatereloaded et al. - no valid contact info, they didn't explain their exit policy to us, I suspect they are sniffing unencrypted Exit traffic): TORy0 - 753e0b5922e34bf98f0d21cc08ea7d1adeee2f6b TORy2 - f08f537d245a65d9c242359983718a19650a25f7 These are running a slightly modified default exit policy. They allow 443. They are fine by me. Oh why? They modified the exit policy and didn't explain here why. And they allow 80 (unencrypted HTTP as you know) as unecrypted mail ports. I think they should be definitely blacklisted! I think you've become a troll. Sorry 'bout it, man. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpRVngQRF0W0.pgp Description: PGP signature
Contacted by oompaloompa operator: BadExit removed
I was contacted by the operator of oompaloompa. He has changed the exit policy of his two nodes to the Reduced policy: http://torstatus.blutmagie.de/router_detail.php?FP=775df6b8cf3fb0150a594f6e2b5cb1e0ac45d09b http://torstatus.blutmagie.de/router_detail.php?FP=babbf0694251e5aff7bf3a0a02efdc12cb99b05f He said that he started those two nodes as a test to experiment with Tor, and picked the exit policy quickly off the top of his head, keeping it brief because it was tedious to write. He also gave the following reasons why one might want an exit policy like this (though he said none of these were his reasons): 1. Crypto may not be legal The problem with this is that Tor is already pumping a ton of crypto that was designed to look as much like web TLS as possible. Chaning your exit policy doesn't really help this. 2. IDSs could prevent attacks This would be a great idea in theory, if it ever worked. In practice, IDSs end up being censorship devices for security mailinglists, exploit advisory info, and other information on computer security. We've actually already BadExited quite a few of these types of nodes, because our exit scanner detects the censorship. 3. Plausible deniability due to eliminating additional TLS fingerprints This is an interesting one, and I think I misread what he meant when he first said it, but if it means not having the additional TLS fingerprints of tor client traffic so that your TLS traffic doesn't stand out in the Tor noise, I don't think this works out for you. You end up being obvious because your node would not exit to any TLS ports. At any rate, because the Exit Policy has changed, I've personally updated my authority to remove the BadExit. I believe we're still waiting on one of Roger or Peter. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp1tsUugpdRp.pgp Description: PGP signature
Re: Scroogle and Tor
Thus spake Matthew (pump...@cotse.net): On 13/02/11 19:09, scroo...@lavabit.com wrote: I've been fighting two different Tor users for a week. Each is apparently having a good time trying to see how quickly they can get results from Scroogle searches via Tor exit nodes. The fastest I've seen is about two per second. Since Tor users are only two percent of all Scroogle searches, I'm not adverse to blocking all Tor exits for a while when all else fails. These two Tor users were rotating their search terms, and one also switched his user-agent once. You can see why I might be tempted to throw my block all Tor switch on occasion -- sometimes there's no other way to convince the bad guy that he's not going to succeed. For the less than knowledgeable people amongst us (e.g me) who want to learn a bit more: what was the rationale for those two Tor users doing what they did? What do they get from it? I second this. Daniel, If you can find a way to fingerprint these bots, my suggestion would be to observe the types of queries they are running (perhaps for some of their earlier runs from when you could ban them by user agent?). One of the things Google does is actually decide your 'Captchaness' based on the content of your queries. Well, at least I suspect that's what they are doing, because I have been able to more reliably reproduce torbutton Captcha-related bugs when I try hard to write queries like robots that are looking for php sites to exploit. I would love to hear more about the types of scrapers that abuse Tor. Or rather, I would like to see if someone can at least identify rational behavior behind scrapers that abuse Tor. Some of it could also be misdirected malware that is operating from within Torified browsers. Some of it could also be deliberately torified malware. Google won't tell us any of this, obviously ;). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpVxq8YphoPj.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake morphium (morph...@morphium.info): So, with everything said, could we now please Un-BadExit the nodes that were affected? Sure, dude. Since you've read everything that was said, I take it you're volunteering to contact the other node operators and ask them to give reasons for why they chose their exit policy? Let us know their preferred email addresses when you're done. But they'll have to survive a challenge and response round proving they can modify their contact info field ;). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgprFx9XcJnz7.pgp Description: PGP signature
Re: Scroogle and Tor
Thus spake scroo...@lavabit.com (scroo...@lavabit.com): My efforts to counter abuse occasionally cause some programmers to consider using Tor to get Scroogle's results. About a year ago I began requiring any and all Tor searches at Scroogle to use SSL. Using SSL is always a good idea, but the main reason I did this is that the SSL requirement discouraged script writers who didn't know how to add this to their scripts. This policy helped immensely in cutting back on the abuse I was seeing from Tor. Now I'm seeing script writers who have solved the SSL problem. This leaves me with the user-agent, the search terms, and as a last resort, blocking Tor exit nodes. If they vary their search terms and user-agents, it can take hours to analyze patterns and accurately block them by returning a blank page. That's the way I prefer to do it, because I don't like to block Tor exit nodes. Those who are most sympathetic with what Tor is doing are also sympathetic with what Scroogle is doing. There's a lot of collateral damage associated with blocking Tor exit nodes, and I don't want to alienate the Tor community except as a last resort. Great, now that we know the motivations of the scrapers and a history of the arms race so far, it becomes a bit easier to try to do some things to mitigate their efforts. I particularly like the idea of feeding them random, incorrect search results when you can fingerprint them. If you want my suggestions for next steps in the arms race for this, (having written some benevolent scrapers and web scanners myself), it would actually be to do things that require your adversary to implement and load more and more bits of a proper web browser into their crawlers for them to succeed in properly issuing queries to you. Some examples: 1. A couple layers of crazy CSS. If you use CSS style sheets that fetch other randomly generated and programmatically controlled style elements that are also keyed to the form submit for the search query (via an extra hidden parameter or something that is their hash), then you can verify on your server side that a given query also loaded sufficient CSS to be genuine. The problem with this is it will mess with people who use your search plugin or search keywords, but you could also do it in a brief landing page that is displayed *after* the query, but before a 302 or meta-refresh to actual results, for problem IPs. 2. Storing identifiers in the cache http://crypto.stanford.edu/sameorigin/safecachetest.html has some PoC of this. Torbutton protects against long-term cache identifiers, but for performance reasons the memory cache is enabled by default, so you could use this to differentiate crawlers who do not properly obey all brower caching sematics. Caching is actually pretty darn hard to get right, so there's probably quite a bit more room here than just plain identifiers. 3. Javascript proof of work If the client supports javascript, you can have them factor some medium-sized integers and post the factorization with the query string, to prove some level of periodic work. The factors could be stored in cookies and given a lifetime. The obvious downside of this is that I bet a fair share of your users are running NoScript, or prefer to disable js and cookies. Anyways, thanks for your efforts with Scroogle. Hopefully the above ideas are actually easy enough to implement on your infrastructure to make it worth your while to use for all problem IPs, not just Tor. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpDQruQ8zLhC.pgp Description: PGP signature
Re: Scroogle and Tor
Thus spake Robert Ransom (rransom.8...@gmail.com): On Mon, 14 Feb 2011 20:19:50 -0800 Mike Perry mikepe...@fscked.org wrote: 2. Storing identifiers in the cache http://crypto.stanford.edu/sameorigin/safecachetest.html has some PoC of this. Torbutton protects against long-term cache identifiers, but for performance reasons the memory cache is enabled by default, so you could use this to differentiate crawlers who do not properly obey all brower caching sematics. Caching is actually pretty darn hard to get right, so there's probably quite a bit more room here than just plain identifiers. Polipo monkey-wrenches Torbutton's protection against long-term cache identifiers. I hate polipo. I've been trying ignore it until it fucking dies. But it's like a zombie that just won't stop gnawing on our brains. Worse, a crack smoking zombie that got us all addicted to it through second hand crack smoke. Or something. But hey, it's better than privoxy. Maybe? I was under the impression that we hacked it to also be memory-only, though. But you're right, if I toggle Torbutton to clear my cache, Polipo's is still there... -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpgDTEhULdw5.pgp Description: PGP signature
Re: Problem with downloading attachments in torbrowser for osx
Thus spake M (moeedsa...@gmail.com): It would be helpful if you can add information such as your - Operating system version - Tor version - Polipo or Privoxy version - Torbutton version - Firefox version - Torbrowser or Vidalia bundle version. ok It sounds like you're describing a problem that only you have. Usually when this happens, it is because of a Firefox addon conflict. You can try a couple of things: 1. Use Tor Browser Bundle: https://www.torproject.org/projects/torbrowser.html.en It is a preconfigured Tor Browser that should work right out of the box without conflicts. If it *still* has the problem, then next place to look is your Antivirus software. If not, you can either keep using it, or try to diagnose your addon conflict by trying the following: 2. Start firefox with a fresh profile If you run firefox as firefox -P, you can create a blank profile, install torbutton in it, and verify it is OK. Then, gradually add in all the Firefox addons you have until you notice the problem again. 3. Post your list of addons to this mailinglist or to that bug for someone else to try to reproduce the issue. and does it work if you use Save As instead? cant save as with attachments... And what about this (and also the link provided by Roger: https://trac.torproject.org/projects/tor/report/14??? This link works for me using Tor + Torbutton. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpd73NTt5Rwe.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake grarpamp (grarp...@gmail.com): Exit policy is currently at the operator's pleasure, need and design. If exit policy mandates will help solve some Tor scalability or attack vector issues, in a substantive way, from an engineering standpoint, fine. But please, don't claim it makes users any more 'safe' from sniffing. I've already addressed the rest of your points. For the record, you're just strawmanning here. I never made the claim this was safer. I cited several engineering reasosn why this type of exit policy is a pain for us. I've also made the claim that there is no rational reason to operate an exit in this fashion, other than to log/monitor/censor traffic or because of undesirable network conditions, and no one has disputed that claim. Morphium gave us a reason, even if it was rather petty and irrational, so he won't be getting the badexit flag. But for my vote in the process, any other relay that does not give a reason for this policy, or that can not give us one because of no contact info, will be getting the flag. The same goes for exits that we detect RSTing 443, or censoring 443, or throttling 443, or doing anything else to TLS connections. But I only have one vote out of three. Roger and Peter are free to change their minds. Perhaps we should bring more people on board in this process, too. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpG9O9HmMzFj.pgp Description: PGP signature
Re: Design Change Causing More Traffic?
Thus spake Jim (jimmy...@copper.net): I am on dialup and so I am very sensitive to the amount of traffic overhead in the operation of Tor. Lately that seems to have increased significantly. Assuming I am not just imagining it (I have no objective measurements to back this up) is this just because of the build-out of the network or has then there been a design change that would cause this? I've just realized that this could be more people adopting the Reduced Exit Policy, which takes up a ton more space in the Tor router directory than does the Default Exit Policy: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/ReducedExitPolicy I bet Karsten could tell us for sure, using the descriptor archive set. We need to standardize a more succinct way to represent this policy, once we converge on a set of ports that we like for it. Either that, or create a way to represent the policy in the consensus just once, and have nodes declare their conformity to that policy by only specifying the token for it from the consensus... -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpKyWf7NgC3f.pgp Description: PGP signature
Re: Blocked from yelp.com?
Thus spake David Carlson (carlson...@sbcglobal.net): I am forbidden to access the server yelp.com. Is that because I am a Tor exit node? To hell with yelp. It's not clear if the bans are intentional - if they just believe that selling user's privacy against their will is their official business model, or if it's just a DoS detection mechanism gone haywire. Given that *residential* exits are showing up as banned, I'm guessing it's not the latter... Go them. Use Google Maps (aka Places on mobile). It aggregates yelp and a handful of other sites, and does not ban tor. It occasionally gives you a captcha, but this is better than a ban. P.S. Just to open myself up to a fun libel suit, I've heard rumors that yelp takes bribes to filter ratings in various ways. I'm sure the filters are only beneficial, and help to remove spam posts and other malicious content. In the face of rumors like these, it really is better to get your information elsewhere, especially from an aggregator. http://www.tech-ex.net/2009/02/yelp-accused-of-asking-for-bribes-to.html http://www.switched.com/2010/02/25/yelp-embroiled-in-bribery-extortion-and-defamation-dispute/ -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpR2GsFF2Gmh.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake Curious Kid (letsshareinformat...@yahoo.com): - Original Message From: Gregory Maxwell gmaxw...@gmail.com To: or-talk@freehaven.net Sent: Mon, January 31, 2011 6:47:37 PM Subject: Re: Is gatereloaded a Bad Exit? There are legitimate reasons why tor supports an operator controlled exit policy, but no real suggestion has been made for a _legitimate_ reason to allow 80 and block 443. Is it possible that some people operate in a port-restricted environment or that port 443 is throttled by some ISPs? These people should not be Tor nodes. A good portion of the public network is on port 443. If you can't reach that port, lots of circuits clients try to build through you will fail. Failed circuits have a negative impact on latency, esp if they were not pre-launched predicted circuits. Byzantine circuit failures also make it difficult to differentiate between overloaded, CPU-bound nodes, malicious nodes, and just plain janky nodes - all of which we would like to be able to take into account for future load balancing decisions. Ex: https://trac.torproject.org/projects/tor/ticket/1984 My real question concerns the scenario in which a user happens upon an exit that blocks HTTPS and uses that exit to access a website that uses a combination of HTTP and HTTPS. The HTTPS portion would be forced through a different exit, and the server may be programmed to notice the difference and break by design. For example, say you want to login somewhere, and the server notes that you appear to be logging in from France. The HTTPS portion appears to come from the United States. That disparity triggers an I'm sorry... message. This is an excellent point, and yet another reason why we should not allow asinine exit policies unless there is good reason for them. So far there is still no rational reason posted why you should allow 80 and not 443 and still be considered a desirable Tor node to use. Just a lot of handwaving about the freedom to be a jerk, and fears over shunning volunteers who run fast exits to grab passwords. Moreover, I strongly believe that we should be working on converging our choices of exit policy down to fewer options for many practical engineering and usability reasons. Exit policies already take up an absurd amount of capacity in terms of descriptor and even networkstatus storage. If we can standardize on a group or groups of ports (such as the Vidalia GUI attempts to do), we can describe sane exit policies using much fewer bytes. And we can load balance more intelligently among exits with standard policies, as I mentioned before. So to me, there are plenty of reasons to do this, and not a whole lot of reasons not to do it, other than handwavy notions that it shouldn't matter, when in fact as you have pointed out, it does matter. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpAQeXL2YOCP.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake t...@lists.grepular.com (t...@lists.grepular.com): On 31/01/2011 13:11, Jan Weiher wrote: Assuming the worse, and disregarding volunteer exit bandwidth without some proper investigation, doesn't sound like a good approach to me... Nobody does that, but I think its fair to say that if you want that somebody can contact you about your node, you publish your contact details in the directory. And if you enter wrong contact infos, you made clear that you dont want to be contacted. I don't think you can make that assumption. Maybe they just didn't want their email address to be public for spam bots to harvest. Maybe they're just used to not publishing their email address unless they really have to. Safest course of action: Figure out how to contact them, and ask them. 3/5 of the nodes provide contact info. 2/5 are run by Joe Blow, and the other is run by nobody at example.com Just for grins, I did in fact send an email to Mr. Blow's gmail address. It of course bounced. Which means it is available on gmail if he wanted it, but he didn't even bother to create it. He's obviously real intent on being a member of the community. But don't worry, at some point Mr. Blow et al will realize that their packet captures stopped grabbing passwords and are only seeing encrypted middle and guard node traffic. They'll probably show up then, proclaiming their innocence from the rooftops, demanding they be allowed to help the network. But do feel free to spend your time going above and beyond, trying to track our 4 heroes down before then. I'm sure they're well worth your time and effort to outreach. Pick a nice Saturday afternoon and spend it calling ISPs and NOCs trying frantically to get in touch with our unjustly punished martyrs here... Heck, take a day off work! I think marking them as bad and waiting for the admin to show up is the easiest way to go. Lets call it a cry-test. Just wait until someone shows up and cries. It's the easiest, but the least efficient route. Somebody mentioned 6% of Exit bandwidth. How much effort would be spent trying to increase the capacity of the network by 6% via coding and/or publicity? Probably a lot more effort than would be required to try and contact these Exit owners and maybe retain the bandwidth. You make it sound as though running an Exit node is a privilege and that people who run them somehow owe the Tor project? They're volunteering bandwidth, for the benefit of the network. If you don't treat volunteers well, they will go elsewhere, and the people who lose out are the people who use the Tor network, not the people who previously ran Exit nodes. Exit bandwidth is a scarce and valuable resource, and should be treated as such. It's not true exit bandwidth here. It's janky bandwidth with lots of bad properties, such as the tendency to break mixed-mode websites as Curious Kid pointed out, and the load balancing issues I mentioned. We should do the same for all http-but-not-https exits for this reason. Again, non-bittorrenting exits have a real hard time attracting enough 80+443 traffic. All of our metrics indicate they are not overloaded the vast majority of the time, and tend to end up pushing half of the bytes/sec as their bitorrent-supporting peers. There is plenty of spare port 80 capacity. The network is bottlenecked in other ways (probably actually in the queues of overloaded middle and guard nodes, which these jerks would be more directly assisting). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpV80CfRkECf.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake t...@lists.grepular.com (t...@lists.grepular.com): But don't worry, at some point Mr. Blow et al will realize that their packet captures stopped grabbing passwords and are only seeing encrypted middle and guard node traffic. They'll probably show up then, proclaiming their innocence from the rooftops, demanding they be allowed to help the network. The above may or may not be true. Would be nice to see some evidence. Or at least some evidence of somebody trying to find the truth. The truth here is that these nodes are not behaving in a way that encourages trust in their usage. All we ask is that they adjust their exit policies to allow encryption, but there is no way to ask them this, so they are badexited until such time as there is a way to communicate with them. They will remain valid middle and guard nodes until they rekey with policy supporting encryption (and the Exit flag). But do feel free to spend your time going above and beyond, trying to track our 4 heroes down before then. I'm sure they're well worth your time and effort to outreach. Pick a nice Saturday afternoon and spend it calling ISPs and NOCs trying frantically to get in touch with our unjustly punished martyrs here... Heck, take a day off work! Do you find that being condescending is a good way to get people to agree with you? I tend to find it fosters disrespect. You're right. I apologize for my tone to you. I am merely frustrated with the amount of mental energy devoted to what so plainly appears to me as a simple policy: If you carry the unencrypted version of the service, you should carry the encrypted version. I am just getting frustrated with the length of this thread and still the lack of any valid, rational reason why this policy itself is an unjust one. It seems pretty plain to me that we're actually worried about offending the sensibilities of people who for some unknown (but rationally obvious) reason refuse to carry encrypted exit traffic. So the idea that we should devote yet more effort to catering to people whose motivations are extremely suspect (and who seemingly have no real interest in being members of our community) is causing me to balk. Exit bandwidth is a scarce and valuable resource, and should be treated as such. It's not true exit bandwidth here. It's janky bandwidth with lots of bad properties, such as the tendency to break mixed-mode websites as Curious Kid pointed out, and the load balancing issues I mentioned. We should do the same for all http-but-not-https exits for this reason. If exiting port 80 but not port 443 causes problems for Tor, then Tor should be updated so you can't offer one without the other. This is a problem with Tor, not with Tor exit operators. Sure. Perhaps we will include such a patch as part of https://trac.torproject.org/projects/tor/ticket/2395. Or, perhaps it will just be a second-order effect that means you're just not used as often because you're not a true Exit (which is already the case for these nodes to some extent). But again, I think this is more of a long-term idea. In the meantime, we can enforce this policy with code on the exit scanning end, by emailing everyone with valid contact info who exits to 80 but not 443, to start (as that is the most obviously broken case). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp3Q4FGYxP93.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake morphium (morph...@morphium.info): 2011/1/30 Damian Johnson atag...@gmail.com: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian That was really dumb, as it puts a lot more load on the Nodes that support encryption, and, as was mentioned before, _every_ operator could sniff. There is no rational reason to carry the unencrypted version of a service but not the encrypted version, except to log data. So unless these 5 nodes were all just playing their favorite lotto numbers in their exit policy, they were being jerks. I am aware that every operator can sniff regardless of policy. Every operator can do a lot of things. The fact that even good exit policies can do bad things is not a necessary condition for allowing bad exit policies. Frankly, this in-your-face selfishness of *only* accepting the unencrypted data because fuck it, that's the only data I want to log just rubs me the wrong way. Not one of those 5 had legit contact info. Two of them actually bothered to fill out the field, but filled it in with a fake email address. All of them just wreak of disrespect for us, for the network, and for our users. Essentially, it's that disrespect that earned them the BadExit flag. If this means that sending the message to them means we take out a few irrational actors in the process, that's fine. I don't much want people playing lotto in their exit policies either. They can stick to middle node and put their lotto numbers in their contact info. I promise that it will work just as well. I will change my Exit Policy now to something like 80, 6667, 21 and if you BadExit it, you'll loose another fast node. *sigh*. And so the cat herding begins. Are you really protesting this policy decision with civil disobedience? Really? Fighting for Great Justice everywhere, eh? Do you have a rational reason why we should allow people to carry the unencrypted version of a service but not the encrypted one, other than Well, they could be bad actors even with a good policy! Or is it just because you feel that someone told to do something and you don't much like being told what to do, regardless of the reasoning? I forbid you from jumping in the nearest lake! I also forbid you from taking your freshly-gimped exit node in for a swim with you! -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpmdWraSdf96.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake Gregory Maxwell (gmaxw...@gmail.com): On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote: I dont see how to recognize if the traffic is recorded? Various research groups occasionally experiment with using side channels for detecting recording exits. Their results are not usually reproducible, though (no source code, poor design, poor quality control, too easy to mitigate, etc). :/ They do occasionally find interesting stuff. But then they either publish, or get rejected, and then shut down their code and forget about it. Instead, I think that nodes which exit _only_ to the unencrypted version of a service (e.g. 80 but not 443) should be excluded from operating as exits entirely (except as enclaves). In this way these nodes would be force to pay their way. We can't stop them from sniffing, but at least we can make them carry traffic they can't sniff as part of the cost of doing their evil business. They could do things like severely throttle encrypted traffic, but that is activity that testing could detect. As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. I agree. We already have scripts to detect this, we just have not yet decided to actually use them yet. I believe we should. Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I believe we hould ban these 5 immediately, and consider banning the other 50 after issuing the appropriate announcements. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpE4kMVVEmo8.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake Mike Perry (mikepe...@fscked.org): Thus spake Gregory Maxwell (gmaxw...@gmail.com): As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. I agree. We already have scripts to detect this, we just have not yet decided to actually use them yet. I believe we should. Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I believe we hould ban these 5 immediately, and consider banning the other 50 after issuing the appropriate announcements. Sorry, the 5 are: NOTICE[Sat Jan 29 20:56:43 2011]:Nodes allowing plaintext but not secure: ElzaTorServer=009E71AED2C5580E942AC1743D1C440C5B2C459E QuantumSevero=4BF2F90E6E1905E2FB4F371E471422150D722A93 gatereloaded=550CC9724FA77C7F9260B93989D22A70654D3B92 oompaloompa=775DF6B8CF3FB0150A594F6E2B5CB1E0AC45D09B oompaloompa2=BABBF0694251E5AFF7BF3A0A02EFDC12CB99B05F -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpCgx8xgRqZn.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake Eddie Cornejo (corn...@gmail.com): Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm missing something. Yeah, I believe you're missing the fact that these ports also contain plaintext passwords than can be used to gain access to information on these and other accounts that may or may not have ever traveled over tor. That is the difference. Finally there is no way that an exit node can directly affect the mode choices by a client. Ie, apart from a particular node existing, there is no way that a node could force a user to use it. See above. Therefore I submit that having these nodes, whether they are overtly recording traffic or not, does not result in any harm to the TOR network. In fact, their presence lessens the burden on the TOR network as they are providing much needed bandwidth. We don't need bandwidth that bad. So, what's the threat? Why are you considering banning these nodes when, by all accounts, I cannot see them having a negative impact on the network as a whole (in fact, it's probably a positive influence) I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpAhAbyOuyIb.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake Eddie Cornejo (corn...@gmail.com): I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. Ok, I accept that this might send a message to 50ish nodes (if you ban all 50+) but if someone was so inclined they could still do this by allowing encrypted traffic and throttling it/blocking it outside of TOR (transparent proxy perhaps?) I predict this is worse as the user client will believe node A will honestly relay encrypted traffic and will select it on this basis, only to find their connection is slow or doesn't fully connect. Admitedly, this won't be a huge problem unless a good number of nodes started doing this. We can detect nodes that fail encrypted connections. We currently scan for failure of port 443. We also detect throttling by virtue of our bw authorities measuring using 443. 443 is the second-most trafficed port by byte on the Tor network, occupying only ~1% of the traffic. If stingy exit nodes really want to waste hours to pinch pennies from their malicious exit policy, they can try crafting a throttling policy that we can't detect. Seems like there are better ways to spend their time. Like reading other people's email. So no, I'm not terribly concerned about second-order effects of this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. My argument is that you're not identifying wolves. If you were serious about identifying wolves then could I suggest you create some dummy accounts, send your password through all exit nodes individually and see which of your accounts are accessed. This would positively identify wolves. All you're achieving by soley looking at exit policies is identifying things that may or may not be wolves and ignoring the larger body of exit nodes that may or may not include wolves. I submit your testing is flawed. We're not trying to identify wolves. We are sending a message to the community. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. I'm not sure I'm comfortable with dictating how an exit nodes exitpolicy should be defined. Each policy should be up to the exit node owner to decide. Just my 2c Not really. In reality, it's up to those who write the code to decide what is available and how it works ;). Welcome to The Golden Path. At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpFPYPp83NMq.pgp Description: PGP signature
Re: How to use Google Gadgets with Tor? - Is this possible?
Thus spake M (moeedsa...@gmail.com): On Sat, Jan 15, 2011 at 7:02 PM, Mike Perry mikepe...@fscked.org wrote: You could also install an addon to observe the requests your browser uses in both non-Tor and Tor accesses of this gadget to see if the requests appear different for some reason. That may help diagnose the cause: https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/ https://addons.mozilla.org/en-US/firefox/addon/tamper-data/ On a side note, i had asked the group before about the google gadgets and whether if there is some security issue with using it wit TOR I receive the response that it had not really been tested before. Should i understand its safe now? Google gadgets that rely on Google browser plugins such as Google Gears are not safe, because we canot protect against them. However, Torbutton's normal protections for the web should keep Google gadgets that use plain AJAX safe, from a privacy point of view. Of course though, you are probably not private to Google at this point, esp if you are logged in to a gmail account. But I assume you're aware of that and what this means in terms of privacy consequences, and are comfortable with that tradeoff. We do *not* recommend disabling Torbutton to get your Google gadgets to work. Then you become signifcantly less private, both to Google and to the rest of the web. If we can't get to the bottom of this and it seems likely that Torbutton is actually the cause, please file a bug report at https://trac.torproject.org/projects/tor/report/14. But so far it seems like there is some other issue which we have not yet gotten to the bottom of. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpouQCpY0reB.pgp Description: PGP signature
Re: How to use Google Gadgets with Tor? - Is this possible?
Thus spake Matthew (pump...@cotse.net): To cut a long story short after having removed TorButton, NoScript, and HTTPS-Everywhere and therefore leaving just Tor I still cannot get Twitter to work from Gmail. I am using Firefox. The Twitter icon and drop-down box partially loads (but not as normal when I am not using Tor). Clicking on it appears to load some Twitter functions e.g. transfering data from twittergadget.appspot.com but Twitter does not load. Eventually all loading messages just stop and the screen stays as Gmail. I've noticed that some mashup services mysteriously break when Google decides to give them/you a captcha. This could be happening to you. You could try to solve a google captcha by issuing some queries and/or using Google maps first, to see if this makes any difference. Usually once you have the cookies for a session that solves a captcha, Google does not make you solve another. You could also install an addon to observe the requests your browser uses in both non-Tor and Tor accesses of this gadget to see if the requests appear different for some reason. That may help diagnose the cause: https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/ https://addons.mozilla.org/en-US/firefox/addon/tamper-data/ -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpeLNswVxLSQ.pgp Description: PGP signature
Re: geeez...
Thus spake Mitar (mmi...@gmail.com): This is related to the if you remove Tor from the world, you're not really reducing the ability of bad guys to be anonymous on the Internet idea. This could be then analog argument as saying that if you remove one weapon factory from the world, that there would be no difference? But one after another and there will be. I cannot buy an argument saying that because situation is bad there should be no small improvements where there could be. That's not what we're saying, but I suspect you may just be trolling. You're certainly straw-manning... various other techniques people have developed over the years to deal with abuse. Then tell me which techniques have we developed which prevent pedophiles to use hidden Tor services? Which techniques have we developed which prevent somebody to blackmail somebody else over Tor network and stay anonymous? Which techniques have we developed which can help found out which are other people in terrorist group and trace their communication, once we discover they use Tor? The same techniques that law enforcement use when these same sophisticated adversaries use black market compromised botnets: http://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_tools.html http://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_digital_forgeries.html http://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_distributing_your.html In these cases, police need to do police work: gathering technical data and examining content for evidence to aid in the investigation; and infiltrating groups and performing stings (for which they often use Tor). It depends where your jerks are coming from. If your jerks are all obeying every law and showing up from their static non-natted IP address, then yes, routing address is definitely related to identity. But if your jerks have ever noticed this doesn't work so well for them, they may start using other approaches and suddenly you're back needing to learn about application-level mechanisms Because current protocols were done just to solve technical problems and not also law or other society problems. For example, HAM operators and their networks had, before they started their packets networks, already laws in place requiring them that each packet should also contain call-sign of responsible person/station. OK, in this particular case (as far as I know) this is not cryptographically enforced (but this is a technical thing) but it still shows that laws like this can work. So if countries (like they cooperate on ACTA) would declare that it is illegal to send or route or relay any packet without information about responsible person for it things would be much different. You think criminals obey the law? Both China and South Korea have instituted fully authenticated internet drivers licenses, and not only has cybercrime not vanished, it continues to flourish and profit from new markets that trade in these credentials and the use of authenticated connections through proxy. Even a fully cryptographically secured and authenticated Internet would still be *just* as vulnerable to abuse, all other things being equal. Grandma could even be required to have her iris scanned before entering her bunker to use her military-grade encrypted, authenticated PC that is otherwise disconnected from the Internet while her iris is not available. But as soon as she scans her iris, the malware on her machine would wake up and inform its masters that it is ready to do their bidding. The only way to really curtail these social problems is to properly address their root causes. Taking freedoms away seems like an easy quick fix, but in reality, there is no gain, only more insecurity. This is why Tor is not part of the problem. In fact, its use by law enforcement for stings, infiltration, and investigation indicates it is also part of the solution. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp8yzAPfXBDT.pgp Description: PGP signature
Re: geeez...
Thus spake Timo Schoeler (timo.schoe...@riscworks.net): Some of us are also compiling abuse response templates. The goal for abuse responses is to inform people about Tor, and to suggest solutions for their security problems that involve improving their computer security for the Internet at large (open wifi, open proxies, botnets), rather than seeking vengeance and chasing ghosts. The difference between these two approaches to abuse is the difference between decentralized fault-tolerant Internet freedom, and fragile, corruptible totalitarian control. Is there any place (e.g. in a wiki) where one could find or even upload his own 'response template', as I might assume that they will be very specific to the country's law they're issued? Here's the (freshly updated) set of abuse complaints that reflects what myself and a handful of others have dealt with over the past 6 months or so: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorAbuseTemplates Notably absent from that list is a DMCA response, but the EFF provides one for that case: http://tor.eff.org/eff/tor-dmca-response.html.en -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpyJRZRGOuuW.pgp Description: PGP signature
Re: geeez...
Thus spake Mike Perry (mikepe...@fscked.org): Is there any place (e.g. in a wiki) where one could find or even upload his own 'response template', as I might assume that they will be very specific to the country's law they're issued? Here's the (freshly updated) set of abuse complaints that reflects what myself and a handful of others have dealt with over the past 6 months or so: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorAbuseTemplates I've also gone ahead and updated the blog post with new tips for exit node operators: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment The two main changes are links to the ARIN registration pages and forms, and tips on forming an LLC to run your node for civil liability protection in the US. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpo4WbFzON4K.pgp Description: PGP signature
Re: Gmail saying cookies are turned off but they are not
Thus spake Praedor Atrebates (prae...@yahoo.com): I am using my usual tor button + firefox to access a gmail account. I have generally had no problems but lately I try to log in and get a cookies are turned off and that I need to turn them on. Cookies are NOT turned off, they are set to be treated as session cookies and they get wiped whenever I shut off firefox. Perhaps there is a setting hidden away somewhere that I can check, whether in the tor button settings or firefox? This is is a bug in Torbutton. It is caused by the hidden setting: extensions.torbutton.xfer_google_cookies. This setting was introduced to reduce the number of captchas that google presented, so that you would only have to solve a captcha once, instead of once per country code domain. It seems to be interfering with gmail logins when your country code changes. Setting this hidden pref to false in about:config will fix the issue for you. See ticket #2377 for info on patches/fixes: https://trac.torproject.org/projects/tor/ticket/2377 Also, please read the archives more closely. This was *just* discussed in a different thread. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpJWxUU79Aig.pgp Description: PGP signature
Re: geeez...
Thus spake Dirk (noi...@gmx.net): ok... since this mailing list is not able to give at least some tips for running a tor exit node except: What do you want to know exactly? In many countries, running an anonymizing service is definitely not illegal. This stuff: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment reads all like How not to get caught. The tips in the blog post are not how not to get caught. In fact, every one of them is about telling people as early in the process what is going on, and who to contact if there are issues. This is done because at scale (gigabit speeds), abuse complaints happen way more frequently. With the default exit policy, you will get about 50 automated DMCA complaints per day at gigabit speeds. With the bittorrent-resistant reduced exit policy from that post, you get about 5 per week. So it is entirely about reducing your work load for managing your exit, and keeping the noise away from your ISP. As previous threads indicate, law enforcement can and does still contact you. The goal again is making this easy, so no one needs to kick in any doors. Some of us are also compiling abuse response templates. The goal for abuse responses is to inform people about Tor, and to suggest solutions for their security problems that involve improving their computer security for the Internet at large (open wifi, open proxies, botnets), rather than seeking vengeance and chasing ghosts. The difference between these two approaches to abuse is the difference between decentralized fault-tolerant Internet freedom, and fragile, corruptible totalitarian control. But I wan't a legally binding statement from a lawyer or an official (BSI) that running TOR exit nodes in germany is legal. I'm not a lawyer, but our largest exit (blutmagie) has run in germany for the past 4 years or so. And then I wan't to sink that little money I have into running as many of such servers as I can. We have discovered that the most effective way to run tor servers is in bulk, because smaller providers are not willing to put up with occasional abuse complaints that do get through to them, because doing so costs them human resources and dollars. Bandwidth also is considerably cheaper in bulk than it is at residential or even shared hosting/VPS prices. Consider donating to http://www.torservers.net/, or setting up your own similar project and collecting donations to leverage the economies of scale inherent in bandwidth prices. Obviously, the more people doing this the better (for distributed trust). See also the thread at: http://www.mail-archive.com/or-talk@freehaven.net/msg14159.html for some insight into the arcane technical details involved in running high capacity tor relays. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpWMTLlwF1UR.pgp Description: PGP signature
Re: Cookie Mismatch when using Gmail.
Thus spake Matthew (pump...@cotse.net): I login to Gmail as normal. I go to Settings / Accounts and Import / Change Account Settings - Google Account Settings. When I click on that link the URL changes to https://www.google.com/accounts/CookieMismatch and the screen shows. We've detected a problem with your cookie settings. Vidalia + NoScript does not present any cookie issues. I can access Account Settings. The problem is when TorButton is used. I then used TorButton's preferences to remove all the protections by unticking as much as possible (effectively making TorButton worthless). I still get the same error! I rebooted and cleaned the cache and cookies and still I cannot access the Account Settings aspect of Gmail. It is as if TorButton per se is the issue irrespective of any security settings it uses. In my Firefox cookie section I have cookies for mail.google.com that read: GX, GXSP, gmailchat, TZ, GMAIL_AT, and S. Yet Gmail still claims that cookies are not installed. I did an about:cache and then searched for torbutton. There were about 100 entries which include: extensions.torbutton.regen_google_cookies;false extensions.torbutton.reset_google_cookies;false extensions.torbutton.xfer_google_cookies;true Try changing this last setting (extensions.torbutton.xfer_google_cookies) to false. It is designed to try to move your google cookies from one domain to another to avoid requiring you to solve captchas for every google country domain. It could be breaking something in the signon process, especially if you get redirected to/from a country domain during login (by using a german exit, for example). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp37IP4lHjb8.pgp Description: PGP signature
Re: Tor uses swap?
Thus spake andr...@fastmail.fm (andr...@fastmail.fm): I'm running Ubuntu 10.04 and Tor browser bundle with scripts forbidden. Does any of my web search results or web pages (or anything else during the web session) I look at get sent to or put on the SWAP partition of my machine? This is a good question. Tor has a torrc option that is off by default to disable all swap activity *by the tor process itself*: 'DisableAllSwap 1'. However, this is not all you need. Your web browser can still be swapped arbitrarily to disk. Unfortunately, this is difficult for us to control for two reasons: 1. It is not possible to access the system calls relevant to this from Torbutton until Firefox 4 (which provides JS-Ctypes to addon developers) is in common use. 2. Even if we do this with a custom TBB build, most operating systems require root/administrator priviledges to disable swap activity. The other alternative is to set up encrypted swap. The Ubuntu documentation on encryption is pretty sad and disorganized: https://help.ubuntu.com/community/EncryptedFilesystems https://help.ubuntu.com/community/EncryptedFilesystemHowto But I think there should be an option to set up encrypted swap during the installation process. There certainly is on other modern distros like Fedora and even CentOS. That is to say- is there any data on my computer I should shred after a Tor session? (yes, I understand other than what I knowingly download like a PDF or music) Other than swap, Torbutton should be blocking all history writes by Firefox in Tor mode by default. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpazZ4VMGVmt.pgp Description: PGP signature
Torbutton 1.3.1-alpha released
Torbutton 1.3.1-alpha has been released at: https://www.torproject.org/torbutton/releases/torbutton-1.3.1-alpha.xpi This release features a fix for the nasty pref dialog issue in 1.3.0 (bug #2011), as well as Firefox 4.0 support. Thanks to new APIs in Firefox 3.5 and better privacy options in Firefox 4, Torbutton has now been simplified as well. While we still provide a number of XPCOM components, the number of native Firefox components we replace has shrunk from 5 to just one. However, the amount of changes involved in supporting Firefox 4 were substantial, and it is likely that these changes as well as the removal of old code has introduced new bugs. I've done my best to test out operation on Firefox 3.6 and 4.0, but I have not tested Firefox 3.0, and I may have missed other issues as well. Please report any issues you notice on our bugtracker: https://trac.torproject.org/projects/tor/report/14 Here is the complete changelog: * bugfix: bug 1894: Amnesia is now called TAILS (patch from intrigeri) * bugfix: bug 2315: Remove reference to TorVM (patch from intrigeri) * bugfix: bug 2011: Fix preference dialog issues (patch from chrisdoble) * bugfix: Fix some incorrect log lines in RefSpoofer * new: Support Firefox 4.0 (many changes) * new: Place button in the nav-bar (FF4 killed the status-bar) * misc: No longer reimplement the session store, use new APIs instead * misc: Simplify crash detection and startup mode settings -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpdhTsZGYy3V.pgp Description: PGP signature
Re: 27C3 on Tor
Thus spake Roc Admin (onionrou...@gmail.com): Found the presentation at least and watching it now. You have to skip to 3:30 for the actual presentation. http://www.youtube.com/watch?v=crMInOosdBkfeature=related Here's a direct link to the relevant section: http://www.youtube.com/watch?v=crMInOosdBk#t=31m38s The work seems to be pretty thorough, but it would be nice to have a paper and/or the source to their classifier. The 27c3 website doesn't seem to list much: http://events.ccc.de/congress/2010/Fahrplan/events/4140.en.html The results aren't very specific in the video. It looks like they covered the major pitfall of timing attack research (the Base Rate Fallacy) with their presentation of the True Positive rate and the False Positive rate, but it's not 100% clear, because there's only a single slide with the results: http://www.youtube.com/watch?v=crMInOosdBk#t=46m20s The other detail that's not clear is if you train your detector for 5 interesting websites, and 2000 uninteresting ones, what happens if the target is browsing sites outside of those 2000 uninteresting ones? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpYtE1yggSIT.pgp Description: PGP signature
Re: Fwd: Re: DMCA Infringement Notification: Copies of 14 complaints
Hrmm. You probably shouldn't be running an exit router on your home Internet connection, either. To my knowledge, no one has ever had their door kicked in in the USA for running an exit router, but there have been phone calls and visits. In other countries, people have had all of their computing equipment seized, and in rare cases, have had charges brought against them for copyrighted or other material found that was completely unrelated to Tor. It's best to keep your home connection running as middle or bridge only, unless you are fully prepared for the risks of increased attention to your home. Thus spake scar (s...@drigon.com): Dmca violations are treated seriously by Qwest and if they continue you will lose your DSL service. You mentioned you were operating a Tor exit router which normally is used for the purpose of hiding ip addresses. If you are allowing people on the internet to hide their ip addresses by routing through your DSL Tor exit router, then you are violating your DSL service agreement with Qwest. You can find the Qwest DSL service agreement at http://www.qwest.com/legal/highspeedinternetsubscriberagreement. Under 7. Service Conditions it state that your residential DSL service is only for the use of your pcs within your home. You cannot allow others, outside your house, to use it for the purpose of hiding their ip addresses. You also are responsible for any harmful or illegal traffic that comes from your DSL modem. The fact that your Tor service is a configured to block the most common ports associated with abuse does not release you from this responsibility. If you are charging money for the use of the Tor service then you are violating the terms of both your residential phone service and your residential DSL service with Qwest as you are not allowed to use either for running a business. -BEGIN PGP SIGNATURE- iEYEAREIAAYFAk0M+34ACgkQXhfCJNu98qBphwCfQzABR7l1WlvWVPHx26RQUBYL FeEAoPZdlpdemE4Otc10qOpI7yLcxg9F =X4Nf -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ -- Mike Perry Mad Computer Scientist fscked.org evil labs pgprwSitlCH8x.pgp Description: PGP signature
Re: Torbutton, CSS3 and window size
Thus spake Just A. User (just_a_u...@justemail.net): http://what-is-my-ip-address.anonymous-proxy-servers.net are able to discover the browser's window inner dimensions accurately. The font downloading attack (@font-face based) from that test is also successful. The short answer here is that new CSS3-based fingerprinting attacks are currently not possible to fully defend against through extension-land, and that while we do take them seriously, we don't have a lot of options to truly protect against them in the short term. JonDoNym is performing a bit of slight of hand on its users wrt to these attacks. It only protects against these attacks by requiring that Javascript be disabled, but this is not a full defense. The CSS3 Media Queries allow you to select entire stylesheets to be loaded on the basis of screen resolution and display information: https://developer.mozilla.org/En/CSS/Media_queries Thus, media queries are quite capable of inducing element loads based on screen resolution and font information, which can be used to ping a server with information about your resolution without the need for Javascript. The mechanisms for this are similar to the CSS-only history attack that does not require Javascript and works on Firefox 2.x and 3.x: http://ha.ckers.org/weird/CSS-history-hack.html The JonDoNym test is only using the Javascript versions of these attacks, and therefore the JonDoFox profile they provide is given a green pass against them, even though a dedicated adversary could extract the same information with CSS3 alone. When I run Torbutton with Javascript disabled, I get very similar results to the JonJoFox profile on their test (are you sure you had javascript fully disabled?) But again, the reality is this is not the whole story. We are currently actively trying to get people at the W3C and inside Google and Mozilla to address these issues, because short of us patching the browsers directly, there is not much we can do here. We may end up patching our Tor Browser Bundle builds if it doesn't appear that any of these groups are taking these new fingerprinting vectors seriously. This places us in an interesting legal situation with Mozilla, because technically such a patch means that we can no longer use the trademark Firefox to describe the browser we provide in this case. Our goal for the W3C is to get them to define a common subset of rendering behaviors that all browsers can adhere to while in private browsing mode. I believe the timeline for adoption of this standard would be measured in multiple years, though. Our goal with the browsers is to convince them to provide us with some kind of API to interact with CSS and the rendering system. For Chrome, their release cycle is faster and this process would be measured in months (if we had all the other APIs we needed, see https://blog.torproject.org/blog/google-chrome-incognito-mode-tor-and-fingerprinting). But for Firefox, their release cycle is slower, and this time period is probably still measuted in years. So to sum it up, lots of rocks, and lots of hard places :/ -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpiUS2lO0Gyt.pgp Description: PGP signature
Re: Chrome and Safari IP leak
Thus spake Roger Dingledine (a...@mit.edu): On Tue, Dec 07, 2010 at 11:12:37PM +, John Case wrote: Wait, what about lynx ? I can't be safe by running lynx inside of a jail with no routable IP ? (10.10.10.10) Sorry, I've been talking to too many ordinary users lately. :) I don't know of any problems with lynx. I think you'll still want to think about topics like cookies and whether your http headers make you recognizable. Take a look through https://www.torproject.org/torbutton/design/ for more topics to think about. Web browsers like 'wget' should also be pretty safe in general. But somebody needs to analyze them in more detail. Turns out that wget can be 302d between schemes to cause you to bypass proxy settings. For example, if you have the $HTTP_PROXY environment variable set but nothing for $HTTPS_PROXY, a 302 to an https url will cause you to bypass proxy. I wouldn't be surprised if the same could happen for an ftp url. So the answer is Just because you think your program is simple doesn't mean it is. We haven't fully audited anything other than Firefox, but we do know most of it isn't safe. Robert Hogan *has* audited a few more apps, but only in conjuction with his 'torsocks' utility: http://code.google.com/p/torsocks/ It looks like wget also has a note there about unsafe HTTP headers.. Not sure exactly what it is sending. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpcAKE6upAiT.pgp Description: PGP signature
Re: Chrome and Safari IP leak
Thus spake Karsten N. (tor-ad...@privacyfoundation.de): a warning for using Google Chrome, Safari or other Webkit based browsers with Tor. Because of a bug in the FTP proxy settings user can deanonymized by FTP links. As Roger said, Chrome is not yet supported. We're working with Google to change this: https://blog.torproject.org/blog/google-chrome-incognito-mode-tor-and-fingerprinting But thanks for reporting this bug. Turns out it already has a ticket in Chrome's bug tracker, but I wasn't aware of it: https://code.google.com/p/chromium/issues/detail?id=11227 I've added it to our list of Chrome issues at: https://trac.torproject.org/projects/tor/ticket/1925 I will also ping the lead developer for Chrome proxy settings. Unfortunately, they are currently on leave until early next year I believe. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpP9L0mv6t4Q.pgp Description: PGP signature
Re: Very low performance in CriptolabTORRelays*
Thus spake Daniel Franganillo (dani...@dilmun.ls.fi.upm.es): Our ISP wont say nothing about their filters (It seems to be a Top Secret issue :P). As I said before there's no problem reported at debug.log except for the frequent: [debug] TLS error: unexpected close while reading (SSL_ST_OK) Another way to do this is to try to use Tor as a client. Does that work? Nope. How about using a client with bridges. Do they work? https://www.sesawe.net/Using-Tor-with-Bridges.html Nope. Transfer rates are equally ridiculous. Tried in windows, same. Great! Now we're getting somewhere. Now, your question isn't How do I run a relay at a censored ISP it's Please help me use Tor at a censored ISP. That is a question we are prepared to at least *try* to answer :) Can you access the following page: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/BlockingDiagnostics If it too is blocked, blocked, it is also available via the ssl-encrypted proxy link on ixquick: https://us2.ixquick.com/do/metasearch.pl?q=TheOnionRouter+BlockingDiagnostics Similarly it is in the Google Cache, which is now available over SSL. https://webcache.googleusercontent.com/search?q=cache:wDewL-f-g9gJ:https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/BlockingDiagnostics+cd=1hl=enct=clnkgl=us If you feel you can follow those instructions, can we meet on IRC? Can you access #tor-dev on irc.oftc.net? Port 6697 is SSL, if you suspect keyword filtering too. Specify a time and we can give you a private bridge IP and try to diagnose exactly how your ISP is blocking access to Tor. P.S. The above goes for anyone who knows anyone having trouble *accessing* the Tor network from anywhere else. Please contact me or show up on #tor-dev. We are in desperate need of people inside China to help us with this. So far we have zero people there who can help us diagnose what is going on. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpasY5OZXx1e.pgp Description: PGP signature
Re: Help me diagnose my Tor blocked/censored ISP!
Actually, let's break this thread off into a new one with new subject, too. Sorry about the double-post. Just want to make sure this hits the search engines. Thus spake Daniel Franganillo (dani...@dilmun.ls.fi.upm.es): Our ISP wont say nothing about their filters (It seems to be a Top Secret issue :P). As I said before there's no problem reported at debug.log except for the frequent: [debug] TLS error: unexpected close while reading (SSL_ST_OK) Another way to do this is to try to use Tor as a client. Does that work? Nope. How about using a client with bridges. Do they work? https://www.sesawe.net/Using-Tor-with-Bridges.html Nope. Transfer rates are equally ridiculous. Tried in windows, same. Great! Now we're getting somewhere. Now, your question isn't How do I run a relay at a censored ISP it's Please help me use Tor at a censored ISP. That is a question we are prepared to at least *try* to answer :) Can you access the following page: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/BlockingDiagnostics If it too is blocked, blocked, it is also available via the ssl-encrypted proxy link on ixquick: https://us2.ixquick.com/do/metasearch.pl?q=TheOnionRouter+BlockingDiagnostics Similarly it is in the Google Cache, which is now available over SSL. https://webcache.googleusercontent.com/search?q=cache:wDewL-f-g9gJ:https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/BlockingDiagnostics+cd=1hl=enct=clnkgl=us If you feel you can follow those instructions, can we meet on IRC? Can you access #tor-dev on irc.oftc.net? Port 6697 is SSL, if you suspect keyword filtering too. Specify a time and we can give you a private bridge IP and try to diagnose exactly how your ISP is blocking access to Tor. P.S. The above goes for anyone who knows anyone having trouble *accessing* the Tor network from anywhere else. Please contact me or show up on #tor-dev. We are in desperate need of people inside China to help us with this. So far we have zero people there who can help us diagnose what is going on. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp5os6zu7PZD.pgp Description: PGP signature
Re: Very low performance in CriptolabTORRelays*
Thus spake Daniel Franganillo (dani...@dilmun.ls.fi.upm.es): El 29/11/10 16:27, Daniel Franganillo escribió: Hi, I'm the admin of CriptoLabTorRelays[1][2][3][4] As you can see at [1][2][3][4] our relays are having almost no transfer rate (3KB or so) It started on Monday 14 of November and after some testing we came to a conclusion... Our Univeristy (our workplace) somehow filtered Tor without us noticing. I think no one is answering your mail because of this statement. If the Tor network is blocked by your ISP, you can't exactly expect to run a relay... Did you confirm the block? Did you try connecting to some of the other public tor relays? A simple way to do this is to just use Firefox and type in https://random.tor.node.ip and see if you get a cert warning or not. Another way to do this is to try to use Tor as a client. Does that work? How about using a client with bridges. Do they work? https://www.sesawe.net/Using-Tor-with-Bridges.html -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpFqlH8oZYMa.pgp Description: PGP signature
Re: Active Attacks - Already in Progress?
Thus spake Theodore Bagwell (torus...@imap.cc): On Sun, 28 Nov 2010 17:54 -0800, Mike Perry mikepe...@fscked.org wrote: Rather than cripple the network by forcing more clients to use slower nodes more often, we have opted to try to document the process of running a high capacity Tor exit node: http://archives.seul.org/tor/relays/Aug-2010/msg00034.html In my research (posted earlier to this list), I did not find an issue with exit relays. The relays which were reliably chosen as part of my circuit were often the first or second relay in my circuit - not the exit relay. In this case, you are experiencing your guard nodes. This is a protective measure where the Tor client remembers a set of 3 live nodes and tries to use them for up to 2 months for its 1st hop... This is done to protect against a wide variety of traffic analysis attacks. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpyfEcctkRwv.pgp Description: PGP signature
Re: Simulator for slow Internet connections
Thus spake John Case (c...@sdf.lonestar.org): On Wed, 1 Dec 2010, Maciej Zbierski wrote: I was going through the Coding Projects site the other day and spotted that Tor is in need of a simulator for slow connections. I have written something similar as a part of my M.Sc., so I thought I could contribute by adapting my code to Tor's needs. First of all, has there been any progress on the subject (so that I don't double someone's work)? Why is this a coding project ? Why don't they just use FreeBSD with dummynet ? I've personally used Linux's NetEM for testing my Tor Circuit Build Timeout learning code: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem It worked well but it has a major drawback in that if you use netem on the same machine as your code is running, you can't do real packet loss simulations because the Linux networking stack hints to the TCP layer that the loss was artificial so that window sizes are not adjusted as they would be in reality: https://www.linuxfoundation.org/collaborate/workgroups/networking/netem#Caveats Getting a patch to disable this behavior would be a great help. Otherwise, I think we need to revise this task on our website to say that we're looking for a Tor network simulator, not a slow network simulator. Easy mistake, I guess ;) -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpL7cD7wyDha.pgp Description: PGP signature
Re: Active Attacks - Already in Progress?
Thus spake Theodore Bagwell (torus...@imap.cc): I don't take issue with these particular nodes, nor the method in which they are multiplied. What concerns me is that any single entity (person/organization) is capable of convincing my Tor client to use it in the majority of circuits I build. The clusters I pointed out before have been vouched for by the community, and that's fine, let's assume they're not evil. But the fact remains that nobody - good or evil - should be capable of making themselves a party in my circuit with such reliability. Unfortunately, Exit bandwidth is really hard to maintain if it is not centralized, and all bandwidth is much much cheaper in bulk. It is very hard to convince an ISP to put up with the noise, attacks, and abuse complaints if you are a low budget node: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment Rather than cripple the network by forcing more clients to use slower nodes more often, we have opted to try to document the process of running a high capacity Tor exit node: http://archives.seul.org/tor/relays/Aug-2010/msg00034.html We have to do the best with the situation we actually have. Trying to force the network to route as if it were the network we *wish* we had will only make it completely unusable. Please help us to create the network we *wish* we had. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpR0O77gJTaV.pgp Description: PGP signature
Re: Hints and Tips for Whistleblowers - their comments on Tor and SSL - I don't understand.
Thus spake Seth David Schoen (sch...@eff.org): Hi, I don't understand, too and in my opinion, this is utter nonsense. I'm not aware of any negative impacts on privacy due to the usage of https://, Session resumption can be used to recognize an individual browser that connects from different IP addresses, or even over Tor. This kind of recognition can be perfect because the resumption involves a session key which is large, random, and could not legitimately have been known to any other browser. :-( This is not true if the user is using Torbutton. See the paragraph about security.enable_ssl2 in: https://www.torproject.org/torbutton/en/design/#browseroverlay This hack causes us to clear all TLS session ID and resumption state. It's bloody, but it works. Firefox has also created an official API for us to do this the right way that we will begin using in 1.2.6: https://trac.torproject.org/projects/tor/ticket/1624 Torbutton also has code to isolate custom stored client and server certificates, but this code tends to crash Firefox because of refcounting issues in the TLS cert manager, so it is disabled by default. We're waiting on this bug to be fixed to enable it: https://bugzilla.mozilla.org/show_bug.cgi?id=435159 In other words, like we do with everything else, we have spent quite a bit of effort in dealing with TLS privacy issues, and the Whistleblower howto link in question is almost 100% nonsense that the author seemingly made up on the spot based on incorrect assumptions that they didn't bother to verify or investigate... -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpss0CKXmIHg.pgp Description: PGP signature
Re: Ubuntu Privacy Remix 10.04r1 out
Thus spake Eugen Leitl (eu...@leitl.org): On Fri, Oct 15, 2010 at 02:44:59PM -0700, Mike Perry wrote: Thus spake Eugen Leitl (eu...@leitl.org): https://www.privacy-cd.org/index.php?option=com_contentview=articleid=66Itemid=89 https://www.privacy-cd.org/en/no-network I suppose that's one way to address the problem of the network adversary... Sure looks like this means this post has nothing to do with Tor, though. Yes, it doesn't have to do with Tor directly, should have pointed that out. However, there's at least some overlap between Tor users and higher paranoia-level folks, and the environment is complementary to Tor in that regard. There may be some overlap, but all of those people are doing it wrong. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp42d3QDerBx.pgp Description: PGP signature
Re: Ubuntu Privacy Remix 10.04r1 out
Thus spake Eugen Leitl (eu...@leitl.org): https://www.privacy-cd.org/index.php?option=com_contentview=articleid=66Itemid=89 https://www.privacy-cd.org/en/no-network I suppose that's one way to address the problem of the network adversary... Sure looks like this means this post has nothing to do with Tor, though. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpeeX8Nq6hWF.pgp Description: PGP signature
Re: Tor network connections constantly building / failing
Thus spake Joe Btfsplk (joebtfs...@gmx.com): What I'm seeing is completely ABnormal from what I've seen for 1 - 2 yrs, over several Tor / Vidalia versions. I often looked at network maps - was never like this. 1) What I described about connections constantly (RAPID fire - dozens, one after another) building, then immediately after 90% of connections 1st pop up - showing building - they immediately fail. Problem is, so many fail so quickly (in seconds), fair amount of time, there aren't 3 good (open, stable) connections. Therefore, d/l seems to drop to zero during that time. 2) ** Currently, this behavior does NOT level off. It continues as long a Tor / Polipo are running (even a day or more). Regardless, in past if I ran Tor for 1 hr, I NEVER saw anything close to this. I don't leave Tor running (for normal browsing) for days at a time. Never have. 3) Now, my speeds never pick up (for any length of time). Your ISP may be blocking connections to the Tor network. What type of internet connection is this? Work/school/library/home? What country are you in? Have you tried other networks/open wifi to see if you get the same result? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpqQYh42LLti.pgp Description: PGP signature
Re: 0.2.2.17 issue?
Thus spake Udo van den Heuvel (udo...@xs4all.nl): Hello, 0.2.2.15 ran fine on my Fedora 13 box. 0.2.2.17 has exited twice without much reason... Any ideas why? Did you build from source, or are you using packages? If so, which packages? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpymW0iO6fJR.pgp Description: PGP signature
Re: Are these torrc entries necessary?
Thus spake Matthew (pump...@cotse.net): Probably well over a year ago Tor seemed really slow and I wanted to speed it up. These settings were recommended (I can't find the website now). CircuitBuildTimeout 30 NumEntryGuards 6 KeepalivePeriod 60 NewCircuitPeriod 15 Are these valid today? AIUI Tor is way faster than it was a year or so ago? If you run tor 0.2.2.17+, the CircuitBuildTimeout is now automatically learned, and typically results in a value around 3-5s for broadband connections. The other options I think were hacks to try to help make this lower hardcoded timeout value give you more benefit. I wouldn't use them with the new code. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpsW8bpdAd3Y.pgp Description: PGP signature
Re: Torbutton 1.3.0-alpha: Community Edition!
Thus spake Drake Wilson (dr...@begriffli.ch): Heh, it turns out this has the same problem, at least with Pidgin. torhttp://link.com still creates an http hyperlink that when clicked on directly would be loaded outside of Tor. httptor://link.com does not create a hyperlink, though.. Nor does http+tor://link.com. Dear gods. Okay, I suppose that probably means that horse has already bolted. This is sad. I tentatively retract my suggestion in light of that. Well I think that specifying that urls are technically officially supposed to be http+tor://, but that the http+ can be omitted gives us the best of both worlds. These urls seem to be then treated mostly correctly by dumb link parsers, because they will just become tor:// links if parsed, which would then work as normal. The exception is that https+tor:// may then be treated as just a tor:// url by a link parser, which effectively converts it into a torrified http url, dropping vital ssl support. Hence, I think we should also provide tors:// as an unofficial backup scheme for these cases. So no, your suggestion wasn't totally busted. It just required lots of attempts to make it actually be practical. :) -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpRxL1EIgQhj.pgp Description: PGP signature
Re: Torbutton 1.3.0-alpha: Community Edition!
Thus spake David Bennett (dbennett...@gmail.com): On 09/30/2010 08:36 PM, Drake Wilson wrote: This release features tor:// and tors:// urls that will automatically enable Tor before loading the corresponding http or https url. Ick. This sort of layer-mixing is the sort that forces people to use a certain protocol for no actual reason. ... Is there a reason not to use something like tor+http and tor+https for the schema, thus opening up the space for (as a facetious example) tor+nntp or analogous usages later? Drake is correct, I don't think that scheme transport swap method is a great idea. That being said, the ability to bookmark a site securely is advantageous. Plus, relative URL's referenced on a host would inherit the scheme. This is not the case. The way the featur works is that Firefox instantly converts the url to the real scheme after enabling Tor and before loading the page. I do understand why it was implemented this way. Scheme stacking would be much more difficult to pull off given current browser technology. To the best of my knowledge, there are no browsers that would easily support this. This rears its head in a lot of other places. For example, try emailing, IMing or posting these urls to google groups. If you specify tor:// as the prefix, worst case the url is not converted to a hyperlink, but best case it is, and the user can just click on it. However, all places I have tried to specify tor+http://link.com, the http://link.com portion of the url is transformed into a hyperlink by the software, but the tor+ part is lost. This leaves room for user error and also makes things inconvenient. Intuition also tells me that tor:// and tors:// urls will be easier to use, understand, and remember by the general public.. Can you give some examples/reasons why just using these schemes actually prevents us from doing this scheme layering idea for other protocols in the future (when it is supported)? In otherwords, why can't we just do both? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgppcha8WnMM3.pgp Description: PGP signature
Torbutton 1.3.0-alpha: Community Edition!
Release early and release often is the motto, or so I'm told.. Well
I never liked getting up early, but maybe we can at least try for
often with this one. But probably not..
Despite these shortcomings of mine (among others), Torbutton
1.3.0-alpha is the first release of Torbutton where most of the code
has come from our community members!
This is great, because after many long years of Torbutton development,
I barely have enough time and sanity remaining to maintain bugfixes on
1.2.x. Not that I started with very much of either in the first place,
I suppose[1]...
And with that, it gives me great pleasure to announce Torbutton
1.3.0-alpha! Due to limitations of addons.mozilla.org, the alpha
series will only be available at the Tor website:
https://www.torproject.org/torbutton/releases/torbutton-1.3.0-alpha.xpi{,.asc}
This release features tor:// and tors:// urls that will
automatically enable Tor before loading the corresponding http or
https url. Useful for bookmarks of your tor sites, or sharing urls
with other Torbutton users to ensure that they load them safely
through Tor. It also features a cookie manager that attempts to allow
you to protect specific cookies that you want to preserve between Tor
modes, as well as intelligent referrer spoofing.
All three of these features were written by Kory Kirk, for his 2009
GSoC summer of code project. (What did I say about early?)
It also features support for a Transparent Proxy or Tor router (or
your regular connection), where Torbutton's protections can be enabled
without using any proxy. This feature was written by Jacob Appelbaum
and Kory Kirk.
These features should be regarded as *experimental*. In particular,
the cookie manager needs testing, to ensure that it is actually
properly protecting and deleting the right cookies, without leaking
them from state to state. Someone should also pay close attention to
the referrer behavior to ensure it is behaving sanely.
What little time I have for Torbutton development will be devoted to
supporting Firefox 4, and trying to work through this neverending set
of bugs for 1.2.x: https://trac.torproject.org/projects/tor/report/14
However, it would be great if we could drum up some more community
interest in developing these and other features, too. In particular, I
think it would be really swell if the cookie manager could be extended
into providing a New Identity button, complete with an optional
timer to run periodically. There's tons of other potential features
waiting to be implemented in the Enhancements section of that trac
report, too.
Here is the complete ChangeLog for 1.3.0-alpha:
* new: Support for transparent proxies in settings
(patch from Jacob Appelbaum and Kory Kirk)
* new: tor:// and tors:// url support to auto-toggle into tor mode
(patch from Kory Kirk)
* new: Cookie manager to allow individual Cookie protection
(patch from Kory Kirk)
* new: Add referrer spoofing based on modified same origin policy
(patch from Kory Kirk)
* new: Add DuckDuckGo.com as a Google captcha redirect destination
(patch from aiden tighe)
* bugfix: bug 1911: Fix broken useragent locale string on debian
(patch from lunar)
* bugfix: Fix captcha detection for encrypted.google.com
[1]. http://archives.seul.org/or/talk/Mar-2007/msg00417.html
--
Mike Perry
Mad Computer Scientist
fscked.org evil labs
pgp7g0wnUDodv.pgp
Description: PGP signature
Re: The best way to run a hidden service: one or two computers?
Thus spake coderman (coder...@gmail.com): however, if an attacker has access to read this locally they've already compromised you to a degree that random mac affords no protection... Is this really true? One of the things I've wondered about here is plugins, but since Torbutton disables them for other reasons I haven't really looked into it. For insance, I know Java can create a socket, and query the interface properties of that socket to get the interface IP. Why not mac address? And if not java, can one of flash, silverlight, pdf-javascript, or others do this? Already we have location features built in to the browser based on nearby Wifi MACs... The Java trick to get the interface IP does not require special privs, so a randomized MAC would in fact help this scenario, if it were somehow possible. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpbuCnlxvSEj.pgp Description: PGP signature
Re: The best way to run a hidden service: one or two computers?
Thus spake Robert Ransom (rransom.8...@gmail.com): On Sat, 25 Sep 2010 17:04:14 -0700 Mike Perry mikepe...@fscked.org wrote: Thus spake coderman (coder...@gmail.com): however, if an attacker has access to read this locally they've already compromised you to a degree that random mac affords no protection... Is this really true? If you are running a hidden service, on a computer with no network access except through Tor, no -- you might not be hosed just by an attacker being able to run a shell command, but leaking an actual MAC address from an actual NIC might get you tracked down. (An attacker with shell access can read your MAC address on Linux just by running ifconfig, even as an ordinary user.) Hah, yah, I forgot the context of this thread was hidden service threats. This thought popped into my head a day after reading coderman's original post and thinking about securing plugins in Google Chrome. But yes, your statement about command injection is absolutely true. In fact, in some cases commands that run may even be restricted by an AppArmour or SELinux policy (if you run Ubuntu 10 or Centos 5), but an attacker still could run some socket syscalls and commands with these limited privs. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpdIfxx8b5aZ.pgp Description: PGP signature
Google Chrome Incognito Mode and Tor
(I'm cross-posting to or-dev and or-talk. Please remove one of the Cc's as appropriate, depending upon the nature of your reply.) For the past couple months, I've been doing a lot of work reviewing and summarizing the major issues remaining before we can safely write a Tor Incognito Mode extension for Google Chrome. I've been using this ticket group on trac to track my progress: https://trac.torproject.org/projects/tor/ticket/1770 I've also written a prototype Chrome extension that is functionally incomplete and unsafe to use, but could use some review by any Javascript ninjas out there: https://trac.torproject.org/projects/tor/ticket/1816 The work has also been summarized in this blog post: https://blog.torproject.org/blog/google-chrome-incognito-mode-tor-and-fingerprinting -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpJrJrOOSMKH.pgp Description: PGP signature
Re: How does Gmail know my local time zone (therefore ignoring the time zone of the Tor exit node) and what else can it see?
Thus spake Matthew (pump...@cotse.net): On 05/09/10 21:11, Geoff Down wrote: Did you select a time zone when you set up the account? I assume you are using Torbutton, which blocks Javascript being used to read your local clock. GD AIUI, Gmail uses JavaScript to detect the time zone (but not the time) on the client machine. When I use NoScript with Gmail as untrusted, Gmail cannot use JavaScript. Changing the time zone settings (for example to something five hours behind my real time zone) does not then change the time at which e-mail appears to arrive in the Gmail inbox since this requires JavaScript which is not used since Gmail is considered untrusted. Please actually use Torbutton instead of speculating about what protections it provides, trying to compensate with ad-hoc homebrew approaches, and then complaining to the list when the results aren't what you expect. https://www.torproject.org/torbutton/design/#adversary Noscript can have all sorts of surprising results when you allow javascript from other domains. However, since many websites do require JavaScript, whether or not one is using NoScript and / or TorButton, my question was: If Gmail can get the time zone via JavaScript (when the client is using Tor) then why can it not get the real IP also via JavaScript (when the client is using Tor)? I don't think it can get the real IP since I have used various tests including http://www.decloak.net/ and Tor with JavaScript does not reveal the real IP. But why not? Javascript cannot unmask your IP. The attacks on decloak and elsewhere are all about causing plugins and external applications to launch, which NoScript does not protect against. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpx1qJKydLEv.pgp Description: PGP signature
Re: Tor seems to have a huge security risk--please prove me wrong!
Thus spake Paul Syverson (syver...@itd.nrl.navy.mil): For those who want more background, you can read more at item #1 on https://www.torproject.org/research.html.en#Ideas (I hoped to transition https://www.torproject.org/volunteer.html.en#Research over to that new page, but haven't gotten around to finishing) Yes. Exploring defensive techniques would be good. Unlike correlation, fingerprinting seems more likely to be amenable to traffic shaping; although the study of this for countering correlation (as some of us recently published at PETS ;) may be an OK place to build on. Personally I still think trust is going to play a bigger role as an effective counter than general shaping, but one place we seem to be in sync is that it all needs more study. Yeah, though again I want to point out that what we are actually looking at when we intuitively believe fingerprinting to be easier to solve than correlation is the event rate from the base rate fallacy. Otherwise, they really are the same problem. Correlation is merely the act of taking a live fingerprint and extracting a number of bits from it, and adding these bits to the number of bits obtained from a window of time during which the event was supposed to have occurred. Or, to put it in terms of event rates, it is merely the case that much fewer potentially misclassified events happen during the very small window of time provided by correlation, as opposed to the much larger number of events that happen during a dragnet fingerprinting attempt. Any classifier needs enough bits to differentiate between two potentially coincident events. This is also why Tor's fixed packet size performs better against known fingerprinting attacks. Because we've truncated the lower 8 bits off of all signatures that use size as a feature in their fingerprint classifiers. They need to work to find other sources of bits. Personally, I believe that it may be possible to develop fingerprint resistance mechanisms good enough to also begin to make inroads against correlation, *if* the network is large enough to provide an extremely high event rate. Say, the event rate of an Internet-scale anonymity network. For this reason, I think it is very important for academic research to clearly state their event rates, and the entropy of their feature extractors and classifiers. As well as source code and full data traces, so that their results can be reproduced on larger numbers of targets and with larger event rates, as I mentioned in my other reply. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp4G3BRZVD7p.pgp Description: PGP signature
Re: Tor seems to have a huge security risk--please prove me wrong!
Thus spake Paul Syverson (syver...@itd.nrl.navy.mil): On Sun, Aug 29, 2010 at 12:54:59AM -0700, Mike Perry wrote: Any classifier needs enough bits to differentiate between two potentially coincident events. This is also why Tor's fixed packet size performs better against known fingerprinting attacks. Because we've truncated the lower 8 bits off of all signatures that use size as a feature in their fingerprint classifiers. They need to work to find other sources of bits. I disagree. Most of what you say about base rates etc. is valid and should be taken into account, but that is not the only thing that is going on. First, you have just stated one reason that correlation should be easier than fingerprinting but then tried to claim it as some sort of methodological flaw. Truncating the lower 8 bits does have a significant impact on fingerprinting but little impact on correlation because of the windows and datasets, just like you said. But way more importantly, fingerprinting is inherently a passive attack. You are sifting through a pile of known fingerprints looking for matches and that's all you can do as an attacker. But its easy to induce any timing signature you want during a correlation attack. (It seems to be completely unnecessary because of point 1, but it would be trivial to add that if you wanted to.) Tor's current design has no mechanism to counter active correlation. Proposed techniques, such as in the recent paper by Aaron, Joan, and me, are clearly too expensive and iffy at this stoge of research. This is totally different for fingerprinting. One could have an active attack similar to fingerprinting in which one tries to alter a fingerprint to make it more unique and then look for that fingerprint. I don't want to get into a terminological quibble, but that is not what I mean by fingerprinting and would want to call it something else or start calling fingerprinting 'passive fingerprinting', something like that. Then there is the whole question of how effective this would be, plus a lot more details to say what this is, but anyway I think we have good reason to treat fingerprinting and correlation as different but related problems unless we want to say something trivial like They are both just instances of pattern recognition. Ah, of course. What I meant to say then was that passive fingerprinting really is the same problem as passive correlation. I don't spend a whole lot of time worrying about the global *active* adversary, because I don't believe that such an adversary can really exist in practical terms. However, it is good that your research considers active adversaries in general, because they can and do exist on more localized scales. I do believe that the global external passive adversary does exist though (via the ATT secret rooms that splice cables and copy off traffic in transit), and I think that the techniques used against passive fingerprinting can be very useful against that adversary. I also think a balance can be found to provide defenses against the global external passive adversary to try to bring their success rates low enough that their incentive might switch to becoming a local internal adversary, where they have to actually run Tor nodes to get enough information to perform their attacks. This is definitely a terminological quibble, but I think it is useful to consider these different adversary classes and attacks, and how they relate to one another. I think it is likely that we are able to easily defeat most cases of dragnet surveillance with very good passive fingerprinting defenses, but that various types of active surveillance may remain beyond our (practical) reach for quite some time. Personally, I believe that it may be possible to develop fingerprint resistance mechanisms good enough to also begin to make inroads against correlation, *if* the network is large enough to provide an extremely high event rate. Say, the event rate of an Internet-scale anonymity network. For this reason, I think it is very important for academic research to clearly state their event rates, and the entropy of their feature extractors and classifiers. As well as source code and full data traces, so that their results can be reproduced on larger numbers of targets and with larger event rates, as I mentioned in my other reply. We don't have the luxury of chemistry or even behavioral stuff like population biology of some species of fish to just hand out full traces. There's this pesky little thing user privacy that creates a tension we have that those fields don't. We could also argue more about the nature of research and publication criteria, but I suspect that we will quickly get way off topic in such a discussion, indeed have already started. In most cases, we pretty intensely frown on these attacks on the live Tor network, even for research purposes, so I don't think anyone is asking for live user traces
Re: Tor seems to have a huge security risk--please prove me wrong!
Thus spake Gregory Maxwell (gmaxw...@gmail.com): On Sun, Aug 29, 2010 at 3:54 AM, Mike Perry mikepe...@fscked.org wrote: [snip] Any classifier needs enough bits to differentiate between two potentially coincident events. This is also why Tor's fixed packet size performs better against known fingerprinting attacks. Because we've truncated the lower 8 bits off of all signatures that use size as a feature in their fingerprint classifiers. They need to work to find other sources of bits. If this is so??? that people are trying to attack tor with size fingerprinting but failing because of the size quantization and then failing to publish because they got a non-result??? then it is something which very much needs to be made public. According to the research groups Roger has talked to, yes, this is the case. Not only might future versions of tor make different design decisions with respect to cell size, other privacy applications would benefit from even a no-result in this area. The problem though is that it's hard to publish a no-result, unless its pretty a pretty surprising no-result, or at least a quantifiable no-result. It's not terribly surprising that existing fingerprinting techniques do not work well out of the box against Tor, because a lot less information is available during a Tor session, and there is a lot more noise (due to more than just the 512-byte cell size). If someone actually worked hard and took all these things into account, and still had a result that said Fingerprinting on Tor does not usually work unless you have fewer than than X numbers of targets and/or event rates below Y, it still probably would belong more in a tech report than a full academic paper, unless it also came with information-theoretic proofs that showed exactly why their implementation got the results it did. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpMoFK8glL4M.pgp Description: PGP signature
Re: Tor seems to have a huge security risk--please prove me wrong!
Thus spake Roger Dingledine (a...@mit.edu): On Sat, Aug 28, 2010 at 11:20:41AM -0400, Paul Syverson wrote: I keep talking to professors and grad students who have started a paper showing that website fingerprinting works on Tor, and after a while they stop working on the paper because they can't get good results either way (they can't show that it works well, and they also can't show that it doesn't work well). The real question I want to see answered is not does it work -- I bet it can work in some narrow situations even if it doesn't work well in the general case. Rather, I want to know how to make it work less well. But we need to have a better handle on how well it works before we can answer that harder question. Yes. This is the approach we need to solve this problem. However, one of the problems with getting it out of most academics is the bias against easy reproducibility. In order for any of this research to be usable by us, it must be immediately and easily verifiable and reproducible in the face of both changing attacks, and changing network protocols (such as UDP-Tor and SPDY). This means source code and experimental logs and data. Most computer science academia is inherently biased against providing this data for various reasons, and while this works for large industry with the budget and time to reproduce experiments without assistance, it will not work for us. I believe it is the main reason we see adoption lag of 5-10 years for typical research all over computer-related academia. My guess is Tor not have this much time to fix these problems, hence we must demand better science from researchers who claim to be solving Tor-related problems (or proving attacks on Tor networks). I've gone into a little more detail on this subject and the shortcomings of timing attacks in general in my comments on Michal Zalewski's blog about regular, non-Tor HTTPS timing attacks: http://lcamtuf.blogspot.com/2010/06/https-is-not-very-good-privacy-tool.html#comment-form -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpqV53J20YXO.pgp Description: PGP signature
Re: Google and Tor.
Thus spake Orionjur Tor-admin (tor-ad...@orionjurinform.com): This should be fixed in Torbutton 1.2.6. When you plan to release it? Well the current plan is to add support for FF4 and fix a smattering of bugs, including this one, in the 1.2.6 release. However, I am also trying to help fix bugs in 0.2.2.x, and help improve the Google Chrome APIs to allow for a Chrome Tor mode (https://trac.torproject.org/projects/tor/ticket/1770), amongst a few other things that I feel are rather important in the near term. In fact, I've been so busy lately that I haven't even fixed the issue in git or my copy of Torbutton, so rest assured that I feel the pain as much as you do. But it still may be a while. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpLcjr3A4Mhl.pgp Description: PGP signature
Re: Google and Tor.
Thus spake Robert Ransom (rransom.8...@gmail.com): On Wed, 25 Aug 2010 20:04:01 -0700 Mike Perry mikepe...@fscked.org wrote: I also question Google's threat model on this feature. Sure, they want to stop people from programmatically re-selling Google results without an API key in general, but there is A) no way people will be reselling Tor-level latency results, B) no way they can really expect determined competitors not to do competitive analysis of results using private IP ranges large enough to avoid DoS detection, C) no way that the total computational cost of the queries coming from Tor can justify denying so many users easy access to their site. If Tor exit nodes were allowed to bypass Google's CAPTCHA, someone could put up a low-bandwidth Tor exit node and then send their own automated queries directly to Google from their Tor exit's IP. Good point. However I wasn't advocating whitelisting Tor exits, I was advocating more intelligent treatment of all high user-count IP addresses, and better mechanisms of rate limiting in general. It's my understanding that a lot of NATed users also run into these captchas during search. To reduce scraping by suspect IPs, their servers could perform all sorts of browser tests to ensure that there is a full working DOM supported by javascript, which can be computationally costly to deploy by scrapers. They can also serve javascript code that performs semi-large integer factorization in the background and post the factors back with queries to rate limit scrapers computationally, or at least tip the cost ratios more in favor of just paying for an API key. Perhaps more effective, they could use various metrics to indirectly estimate the number of humans behind an IP. There are plenty of Google services and applications they provide that aren't really usable by bots. The rate of use of these non-search services per IP should provide a strong indicator of human activity behind that IP. Again, the impression I got was that if they had done the analysis on the captcha solve rate vs the query rate per IP, the cost/benefit analysis of the DoS mechanisms they apply, or the cost vs effectiveness vs user impact of alternatives, they certainly weren't willing to discuss any of this with us. They also seemed disinclined to meet to explore any realistic alternatives we could jointly develop in both Torbutton and the DoS side to help reduce the captchas and 403s experienced by our users. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpNrwJkzXL5G.pgp Description: PGP signature
Re: How to Run High Capacity Tor Relays
I should have said this in my first post, but I believe that all subsequent replies should go to tor-relays. This should be the last post discussing technical details of relay operation on or-talk. Thus spake coderman (coder...@gmail.com): net.ipv4.tcp_keepalive_time = 1200 ^- who uses keepalive? :) Hrmm, Tor does its own application-level keepalive. Perhaps that's how this got merged in by confusion. Or maybe, like many of these, it was just a blanket cut+and+paste move out of desperation to try to increase capacity. The whole superset of voodoo thing. net.netfilter.nf_conntrack_tcp_timeout_established=7200 net.netfilter.nf_conntrack_checksum=0 net.netfilter.nf_conntrack_max=131072 net.netfilter.nf_conntrack_tcp_timeout_syn_sent=15 ^- best to just disable conntrack altogether if you can. -J NOTRACK in the raw table as appropriate. you're going to each up lots of memory with a decent nf|ip_conntrack_max ( check /proc/sys/net/ipv4/netfilter/ip_conntrack_max , etc ) Will this remove the ability to do PREROUTING DNAT rules? I know a lot of Tor nodes forward ports and even IPs around. Good suggestion though. Perhaps we should mention both options in the final draft. [...] some dupes in here? net.ipv4.ip_forward=1 ... net.ipv4.conf.default.forwarding=1 net.ipv4.conf.default.proxy_arp = 1 ^- BAD! this should not be enabled by default unless you're actually routing specifically to guest vm's or between interfaces or something. if you enable forwarding by default, someone may use you to relay some malicious traffic. Oh shit, that is a relic of Mortiz's config. He is also planning to provide VPN and VPS services. Good catch. Also, does DNAT count as forwarding for the ip_forward option? == Did I leave anything out? == Well, did I? i'd love to see an sca6000 accelerated node. been working with these recently but unfortunately they're allocated for other work... (most of the other crypto hw is going to be bus / implementation limited to less than what a beefy 64bit modern server can provide, so of little utility in this context.) I'd love to hear Roger and Nick's comments on this, but isn't it possible this might also bottleneck well before 1Gbit? I am worried it may depend largely on the architecture of the card and our use of openssl. Their docs claim up to 1Gbit but this could be using highly parallelized processing, which tor cannot really do, as I understand it. Personally I think the hyperthreading option is the lowest hanging fruit for maxing out a single Tor relay process for lowest cost. Also, afaik, zero people in the wild are actively running Tor with any crypto accelerator. May be a very painful process... I'm not really interested in documenting it unless its proven to scale by actual use. I want this document to end up with tested and reproduced results only. You know, Science. Not computerscience ;) -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpUMXxamWLCJ.pgp Description: PGP signature
Re: The team of PayPal is a band of pigs and cads!
Thus spake David Carlson (carlson...@sbcglobal.net): On 8/23/2010 2:05 PM, Andrew Lewman wrote: They are correct, https://cms.paypal.com/us/cgi-bin/?cmd=_render-contentcontent_ID=ua/UserAgreement_fulllocale.x=en_US Section 9.1, j. Apparently they don't want you as a customer if you want to protect yourself from unscrupulous marketing or local ISP surveillance. I'll start a conversation with them. Thanks for bringing this up. I am a newbie here. Since they use SSL, isn't it overkill to route your connection through Tor? I know it is a pain to switch Tor on and off when multitasking, but it would seem that Tor button could do that. There have already been lots of excellent paypal-specific answers here, but the more general problem is that any company on the web is, or at least eventually will conider, making money of of your information, any way they can. Using the Firefox addon RequestPolicy really makes you aware of this. For example, I've seen facebook domains sourced in my airline ticket purchase windows. When I happen to be wearing my paranoid hat (pretty often -- it's rather stylish), I am convinced this is facebooks' way of getting to ground-truth on an identity they have a profile for, because plane ticket use is strongly authenticated. I'm sure the same thing can happen with any bank, or even online merchant. Once they get a purchase with a cookie set and IP, they not only know your location, but they can correlate it with the rest of the marketing data they have on you, and if you dont clear your use Tor+Torbutton, they can infer a list of the rest of the websites you visit. In this case, they of course, are the voracious advertising companies[1]. In fact, because so many users are actually clearing cookies these days, marketing companies have begun developing fingerprints to track you even if your cookies and IP change: https://wiki.mozilla.org/Fingerprinting. Torbutton blocks most of these, but work needs to be done to block more. So for me, Tor is about cutting that crap off at the bud. If I must be strip-searched at the airport (digitally or not), and have my airline ticket purchase IP recorded at the DHS[2], at the very least they will not correlate that with my other Internet activity. In fact, you could take the paypal conspiracy one further, in that they also don't like many forms of prepaid gift card use. They are simply not interested in collecting information that contains any noise what-so-ever... 1. http://techcrunch.com/2009/11/06/zynga-scamville-mark-pinkus-faceboo/ 2. http://current.newsweek.com/budgettravel/2008/12/whats_in_your_government_trave.html -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpzw9LklxVjT.pgp Description: PGP signature
Re: Google and Tor.
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. There are numerous ways we could improve this situation without requiring blanket exemptions for Tor Exits (such as client side puzzles, or more intelligent rate limiting algorithms that are more tolerant of our typically cookieless but legitimate users coming in large masses from the same IP). Unfortunately the DoS team at Google is unwilling to work with us to find alternate ways of limiting these captchas at the moment. Tor has many friends inside Google, but sadly the DoS team is independent enough from the rest of Google that regardles of Google's opinion of Tor or censorship circumvention, the DoS team is unwilling to devote any development resources to improving this problem, and have declined even meeting with us directly :( Astute students of human nature will note that this is the result you expect when you place a small group of people in a position of unassaillable control of a resource for security reasons... Our current solution is to automatically redirect Google Captcha requests to alternate search engines such as ixquick, scroogle, yahoo, or bing. This feature was introduced in Torbutton 1.2.5 and uses ixquick by default. However, Google's recent switch to using encrypted.google.com for SSL search caused our captcha detection code to break in Torbutton. So if you are using encrypted search and/or HTTPS Everywhere, your captchas will no longer be seamlessly redirected. This should be fixed in Torbutton 1.2.6. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpNcDwOSw9Vh.pgp Description: PGP signature
Re: Google and Tor.
Thus spake Aplin, Justin M (jmap...@ufl.edu): 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. Various horrible behaviors have come and go with this captcha system over the past 3 years or so. Sometimes you just get a 403 with no captcha, sometimes you have to solve a captcha, sometimes 2 captchas, sometimes infinite captchas, and sometimes it forgets your query and you have to start the whole process over again from a Google landing page. My point is that the whole system is problematic on a number of levels. I also personally believe that there are better ways of rate limiting and screening queries from high-user count IPs that do not involve cookies or captchas. I also question Google's threat model on this feature. Sure, they want to stop people from programmatically re-selling Google results without an API key in general, but there is A) no way people will be reselling Tor-level latency results, B) no way they can really expect determined competitors not to do competitive analysis of results using private IP ranges large enough to avoid DoS detection, C) no way that the total computational cost of the queries coming from Tor can justify denying so many users easy access to their site. This is why I'd love a chance to meet with the DoS team to discuss some of these points. However, I get the strong impression it is a very secretive group that is especially wary of discussing their methods, reasoning, or analysis and with anyone else, and is generally given a blank check to enact policy without proper in-depth cost/benefit analsysis because its actions are for security. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpGvcbwzdUPv.pgp Description: PGP signature
Re: Police raid in Erfurt, Germany on Perfect Privacy, a commercial anon-service
English version: https://blog.perfect-privacy.com/2010/08/20/perfect-privacy-staff-member-gets-house-search/ Appears to be possibly related to their SSH/VPN service, not their Tor nodes. As far as I can tell, they've run no Tor exits recently, only Guards. Thus spake heidenh...@attac.de (heidenh...@attac.de): 'Perfect Privacy', a commercial anon-service (25 Euros/month) for encrypting your Internet and keep your identity and privacy protected from prying eyes was raided on friday in Germany. http://www.perfect-privacy.com/index.html Niklas https://forum.perfect-privacy.com/showthread.php?t=2183 Heute, Freitag, dem 20. August 2010, kam es zwischen rund 7:00 und 8:00 Uhr morgens MESZ zu einer Hausdurchsuchung bei einem von Perfect Privacys Administratoren, der als Kontaktperson für Perfect Privacys Server in Erfurt, Deutschland, fungiert. Der Durchsuchungsbeschluß gründet sich auf den Verdacht, daß über die Privatsphärenserver in Erfurt von unbekannten Verdächtigen strafrechtlich relevante Kommunikationen geroutet wurden. Im Zuge der Hausdurchsuchung wurden insgesamt fünf Rechner samt Festplatten und Speichermedien beschlagnahmt. Sofern die Rechner für administrative oder sonstige Tätigkeiten rund um Perfect Privacy eingesetzt wurden, sind sie allesamt vollverschlüsselt. Der geschätzte Schaden beträgt ungefähr EUR 6.000,00 bis EUR 6.500,00. Perfect Privacy hat bereits mit einem Rechtsanwalt Kontakt aufgenommen, der unter anderem Akteneinsicht beantragen wird. Perfect Privacys Server in Erfurt sind zur Zeit des Verfassens dieses Schreibens nach wie vor online, können gepingt werden, und Perfect Privacy besitzt weiterhin die root- und Verwaltungsrechte. Die Server wurden soweit nicht beschlagnahmt. Wir haben uns allerdings dazu entschlossen, vorübergehend alle Dienste in Erfurt (OpenVPN, PPTP VPN, L2TP/IPSec VPN, SOCKS5, SQUID) zu deaktivieren, um jenen unser Mitglieder, die erhöhte Sicherheitsbedürfnisse haben, Zeit zu geben, diese Ankündigung zu lesen und eine Risikoevaluierung vorzunehmen. Uns ist nicht bekannt, ob in Erfurt von behördlicher Seite Maßnahmen wie eine Telekommunikationsüberwachung eingeleitet wurden. Weitere Details folgen in den nächsten Tagen. Mit freundlichen Grüßen Perfect Privacy Administration 20. August 2010, 10:30 MESZ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpYyYiv3DEmR.pgp Description: PGP signature
How to Run High Capacity Tor Relays
61000 net.ipv4.tcp_synack_retries = 3 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_max_syn_backlog = 10240 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_keepalive_time = 1200 net.netfilter.nf_conntrack_tcp_timeout_established=7200 net.netfilter.nf_conntrack_checksum=0 net.netfilter.nf_conntrack_max=131072 net.netfilter.nf_conntrack_tcp_timeout_syn_sent=15 net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.ip_local_port_range = 1025 65530 net.core.netdev_max_backlog=30 net.core.somaxconn=20480 net.ipv4.tcp_max_tw_buckets=200 net.ipv4.tcp_timestamps=0 vm.min_free_kbytes = 65536 net.ipv4.ip_forward=1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_synack_retries = 2 net.ipv4.conf.default.forwarding=1 net.ipv4.conf.default.proxy_arp = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.all.send_redirects = 0 EOF # XXX: ethtool wibbles # You may also have to tweak some parameters with ethtool, possibly # also enabling some checksum offloading or irq coalescing options to # spare CPU, but for us this hasn't been needed yet. == Setting up the Torrc == Basically you can just read through the stock example torrc, but there are some as-yet undocumented magic options, and options that need new defaults. # NumCPUs doesn't provide any benefit beyond 2, and setting it higher # may cause cache misses. NumCPUs 2 # These options have archaic maximums of 2-5Mbyte BandwidthRate 100 MB BandwidthBurst 200 MB == Waiting for the Bootstrap and Measurement Process == Perhaps the most frustrating part of this setup is how long it takes for you to acquire traffic. If you are starting new at an ISP, I would consider only 200-400Mbit for your first month. Hitting that by the end of the month may be a challenge, mostly because their may be dips and total setbacks along the way. The slow rampup is primarily due to limitations in Tor's ability to rapidly publish descriptor updates, and to measure relays. It ends up taking about 2-3 days to hit an observed bandwidth of 2Mbyte/sec per relay, but it can take well over a week or more (Moritz, do you have a better number?) to reach 8-9Mbyte/relay. This is for an Exit node. A middle node will likely gather traffic slower. Also once you crash, you lose it. This bug is about that issue: https://trac.torproject.org/projects/tor/ticket/1863 There is also a potential dip when you get the Guard flag, as our load balancing formulas try to avoid you, but no clients have chosen you yet. Changes to the authority voting on Guards in Tor 0.2.2.15 should make this less drastic. It is also possible that your observed bandwidth will be greater than without it. However, it will still take up to 2 months for clients to choose you as their new Guard. == Running temporary auxiliary nodes == One way to shortcut this process and avoid paying for bandwidth you don't use is to spin up a bunch of temporary nodes to utilize the CPU and quickly gather that easy first 2MB/sec of observed bandwidth. But you need the spare IPs to do this. == Monitoring == Personally, I prefer console-based options like nload, top, and Damian's arm (http://www.atagar.com/arm/) because I don't like the idea of running extra services to publish my monitoring data to the world. Other people have web-based monitoring using things like munin and mrtg. It would be nice to get a script/howto for that too. == Current 1-Box Capacity Record == Our setup has topped at 450Mbit, but averages between 300-400Mbit. We are currently having uptime issues due to heat (melting, poorly ventilated harddrives). It is likely that once we resolve this, we will continually increase to our CPU ceiling. I believe Moritz and Olaf also push this much capacity, possibly a bit more, but with less nodes (4 as opposed to our 8). I hear Jake is also ramping up some Guard nodes (or maybe I didn't? Did I just betray you again Jake?) == Did I leave anything out? == Well, did I? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpsMuGfuekKi.pgp Description: PGP signature
Re: Bigger Thinking [was: Tor Project 2008 Tax Return]
Thus spake Al MailingList (alpal.mailingl...@gmail.com): And what about Microsoft? I think someone should be targeting/lobbying them to include a Tor client and default bridge relay in every version of Windows 8 or 9. Find out what it would take to get them to do this, Sorry, what's in this for Microsoft? Being a good corporate citizen? From a business point of view, including a peer to peer style client BY DEFAULT in an operating system has PR nightmare written all over it, but they will take the risk of lost revenue for being a good corporate citizen? I find it unlikely... Actually there are several large-userbase companies that want to include Tor by default in their product, either as a client, a relay, or a bridge. Unfortunately, the only answer we have for them in the immediate term is For the love of goddess don't do that, you'll destroy Tor. Our immediate concern is making it possible to support at least a fraction of one of these userbases in either the relay or the bridge roll. The relay role will require a significant update to Tor's directory mechanisms, and we are trying to drive academic research forward in these areas. The bridge roll may be more immediately doable, but we're not sure that bridgedb wouldn't just fall over yet either. of having a European voice in all this. That means another $20M a year in funding please. At least. Then there is law enforcement and the military and intelligence agencies - for f*ck sakes if someone at the Tor Project can't see them as low hanging fruit then I will start to cry. Right... so in the case of law enforcement, you are going to ask law enforcement to fund a project that (this is not my opinion, this will be theirs) allows people to access illegal content anonymously and makes their job that much harder? That's low hanging fruit? Hate to hear what the high hanging fruit will involve :) Actually, most competent law enforcement agents realize that what gets them the most points are sting operations that topple entire distribution rings, gangs, or bot herders. These sorts of stings require heavy use of Tor. Roger and Andrew actually spend a good amount of their time talking with law enforcement and giving presentations about what Tor is and how they can use it to anonymize their investigative activity. I think if you want a job at the tor project, you should just ask :P And maybe just provide them with past results you've obtained for similar organisations or in a lobbyist role, as opposed to getting frustrated on mailing lists :) Actually almost all of the people working for Tor today started out on the mailinglists, frustrated with some aspect of Tor or other :). Of course, they also tended to naturally step in to some sort of volunteer capacity along their areas of interest, as a result of this frustration. Tor tends to care about this level of passion way more than resumes or interviews. The Tor Project is trying most of the things Julie has suggested. It just takes time, effort, communication, and people. We don't mind letting our consistently passionate volunteers talk to people about Tor in official capacity, either. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpiblWx40FaN.pgp Description: PGP signature
Re: THE GLOBAL ADVERSARY [was: Tor Project 2008 Tax Return]
Thus spake Mike Perry (mikepe...@fscked.org): So if you were the Global Traffic Analysis Adversary then you would distract, delay, deny and defend lack of protection from your analysis. If you also funded the project then that would make that task easier. Don't forget all the University professors and grad students doing Tor research independent of the Tor Project. They are paid off to keep quiet, too. Most of them have island beachfront property (but under black ops front company names, of course). It's a pretty sweet gig. Since my first revelation, several people have emailed or messaged me privately about how they can start working towards their beachfront property. It warms my heart that there are so many interested in taking The Adversary up on His generous offer! The Tor Volunteer page actually lists Tor-related research problems at the very top of its Research section at the bottom of: https://www.torproject.org/volunteer The first three are directly relevant to the Global Adversary problem and have been present at the top of this list for years. They've actually been solved numerous times. Each time the result is buried and the author gets their own beachfront black-ops resort. If you believe you have a solution, simply pick up your phone and clearly say Attention: NSA. Attention: NSA. I have a solution to subvert the Global Adversary into the mouthpiece. That, or email tor-assista...@torproject.org. They'll get it either way, and they will ensure you are... taken care of. There have also been several near-solutions in the past year or two that did not qualify for beachfront property, and thus were still published. Namely the 3 at PETS this year (sorry guys, better luck next time!). These still need to be added to anon-bib, reviewed, and evaluated. One of the major problems with all this attack and defense work is that each paper uses different metrics and a different adversary model. This makes it hard to tell which attacks would still be able to thwart which defense, and thus it is increasingly hard for The Adversary to determine exactly which papers He needs to Unpublish. In fact, a thorough academic review of all timing attack and defense papers to date under common adversary and performance models is at least enough to get you a beachfront black-ops time-share. The Adversary has informed me that Steven Murdoch was looking into developing these models, but he may be willing to coauthor to split the time-share with you if you help evaluate attacks and defenses using his models. Something to consider... -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpvku2RlpRoe.pgp Description: PGP signature
Re: TLS NPN (Next Protocol Negotiation)
Thus spake Seth David Schoen (sch...@eff.org): Much of the debate centers around the idea that NPN will make it harder for network operators to know what protocols users are using over TLS and hence to block particular protocols while permitting others. One of the proponents (Adam Langley, who has been doing a lot of other fantastic work on making TLS better and more ubiquitous) mentioned the idea that Tor is an intended use case for this behavior, although there hasn't been any other explicit discussion of this. It does seem like something we would try to use, but only if it were deployed widely enough so that we weren't the only ones using it. I'm tempted to reply pointing out that _all_ uses of TLS represent at least potential support for a threat model in which a network operator is the adversary whom users are trying to defend against. So there's not much conceptually new about having TLS reduce network operators' control over traffic, although some of the people in the discussion seem to feel there is a qualitative difference between, say, keyword filtering and protocol filtering. The point I would make is that its very likely that most services will continue to operate on their traditional tcp ports, regardless of NPN. Administrators hoping to be able to block protocols by a TLS fingerprint seem to be barking up the wrong tree. Anyone wishing to subvert their controls will use a custom TLS/stunnel bridge on an acceptable port as defined by their policy. I think this indicates that you are right. The more effecive way I have seen to do these sorts of controls is by policy enforcement on the software that the machines themselves can run, rather than on the network. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgprBA6gSIQVj.pgp Description: PGP signature
Re: Tor Project 2008 Tax Return Now Online
Thus spake Jonathan D. Proulx (j...@csail.mit.edu): While I do think it's good to see the funding there are two points that are important to remember. 1) this is a freesoftware project the code is there for all to see, hopefully clueful people other than the US Government are reading it. Yes. The larger threat is that funders can stear funding in a general direction. Say, by prioritizing performance over censorship resistence, or censorship resistence over anonymity research. So far however, it appears that everyone involved is on the same page, and believes that performance, usability, censorship resistence, and general anonymity research are *all* important to our goal. 2) no matter who's funding it the US gov't could read the code (see above) and would continue to (potentially) have a near global view of internet traffic. To a large extent freesoftware defends agains the worst abuses funders can demand (1), but I wouldn't fully trust TOR against China either (2) As an aside, while a global adversary is not something the Tor research and development community feels it is currently capable of defending against in general, there are limits to the ability of even a global adversary to perform accurate dragnet analysis of all Tor traffic. This is primarly due to the Base Rate Fallacy: https://conspicuouschatter.wordpress.com/2008/09/30/the-base-rate-fallacy-and-the-traffic-analysis-of-tor/ http://archives.seul.org/or/dev/Sep-2008/msg00016.html In other words, the average Tor user doesn't have a lot to fear, IMO. However, once you are targeted specifically by a global adversary, or if you are visiting sites that are targeted by a global adversary, your odds of escaping detection do go down drastically. The big problem that Tor faces is that most schemes to protect against this sort of adversary are either costly, unproven, or both. There were a couple of promising papers at PETS this year, but they need to have a bit more time to be reviewed by the research community. They also add non-negligible overhead. http://petsymposium.org/2010/program.php -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpFyv4Sfv9w8.pgp Description: PGP signature
Re: Tor Project 2008 Tax Return Now Online
Thus spake Anon Mus (my.green.lant...@googlemail.com): 1) this is a freesoftware project the code is there for all to see, hopefully clueful people other than the US Government are reading it. Unfortunately, whilst there are clueful people watching the software, no one has yet decided to publically produce and share a modified version of this code which protects from a Global Adversary who is analyzing the traffic (real time or.not). I await that day, but believe it will not be soon, because it would be foolish to take on such a task, only to have the Tor project themselves then radically change the code and so as to make the unofficial modification obsolete. You're right, that's exactly why the work hasn't been finished yet. Everyone smart enough to do it realized that we'd just cause git conflicts with their work. They'd be foiled once and for all. ONCE AND FOR ALL! It has nothing to do with realizing that the best designs for these sorts of networks to date still aren't certain to be foolproof or fast, or that completing and proving such a design to be secure and scalable under a useful threat model would be at least a master's thesis. It has nothing to do with realizing that any naive padding solution would be instantly broken, providing a unique fingerprint for everyone using it, while *still* not providing substantial actual protection of their traffic. It has everything to do with the fact that the conspiracy is SO VAST AND OPPRESSIVE that everyone smart enough to do this project realizes that we'd just break their commits and there would be NOTHING THEY COULD DO ABOUT IT. Tor: 1, You Guys: 0. It's great being on the inside. 2) no matter who's funding it the US gov't could read the code (see above) and would continue to (potentially) have a near global view of internet traffic. Well its obvious that who funds it get to make the decision as to what anonymity protection gets put in. I see you've been reading between the lines on our monthly status reports, our roadmap docs, our trac projects, our specifications, our proposal process on or-dev, our TODO files, and so on. Very clever of you. For those not as swift as our detective here, the evidence (with full revision history) is hiding in plain sight at: https://svn.torproject.org/svn/projects/todo/ https://svn.torproject.org/svn/projects/roadmaps/ https://gitweb.torproject.org/tor.git/tree/HEAD:/doc/spec/proposals https://trac.torproject.org/projects/tor/wiki/sponsors https://blog.torproject.org/category/tags/progress-report/ The conspiracy is really too obvious in retrospect, especially if the likes of you were able the figure it out. We should be more careful with our future conspiracies. This has been noted in our files. So if you were the Global Traffic Analysis Adversary then you would distract, delay, deny and defend lack of protection from your analysis. If you also funded the project then that would make that task easier. Don't forget all the University professors and grad students doing Tor research independent of the Tor Project. They are paid off to keep quiet, too. Most of them have island beachfront property (but under black ops front company names, of course). It's a pretty sweet gig. So whilst there is no protection in Tor (by official policy) from the Global Traffic Analysis Adversary (aka US -GOV) then you can expect to unmasked for every usage you make of Tor. Unless of course, you were the US -GOV in which case you can add that protection into your Tor nodes and Tor clients. Correct. Of course, you could add that same protection in too. But, then, of course, we'd break your commits. This is the one advantage of sponsoring Tor. The US Gov't quickly realized that otherwise, we'd break their commits too. They had no choice, really. It really is the best revenue model for Open Source Development yet. We should write a book, if it weren't so damn secret... For instance if I were US - GOV (i.e. it was my job to spy on your traffic) I would, at the very least, [ REDACTED ] You know too much, Mr. Anon Mus. The Adversary has been alerted. Prepare to be silenced (if we're lucky). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpPKj6m8cjZc.pgp Description: PGP signature
Restricted Exit Policy Port Suggestions?
It's become clear that it is almost impossible to run an exit node with the default exit policy in the USA, due to bittorrent DMCA abuse spambots. I believe this means that we should try to come up with one or more standard, reduced exit policy sets that allow use of the majority of popular internet services without attracting bittorrent users and associated spam. Using previous threads, I have an initial sketch of such a policy at: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment It includes the following ports: 20-22, 53, 79-81, 110, 143, 443, 465, 563, 587, 706, 873, 993, 995, 1863, 5190, 5050, 5222, 5223, 8008, 8080, . While looking over the Vidalia settings, I just noticed that IRC is missing from this list: , 6667, 6697. However, IRC is also a common source of abuse and DDoS attacks, and is often forbidden by ISP AUP. Because of this, I was thinking we should probably define 3 or 4 levels of Exit Policy: 1. Low Abuse (above list, possibly minus 465, 587 and 563) 2. Medium Abuse (above list, plus IRC) 3. High Abuse (default exit policy) Now the question is, what other ports should we add or subtract from this list? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpUROdGntQNx.pgp Description: PGP signature
Re: Restricted Exit Policy Port Suggestions?
Thus spake and...@torproject.org (and...@torproject.org): On Wed, Aug 11, 2010 at 03:05:24AM -0700, mikepe...@fscked.org wrote 1.8K bytes in 55 lines about: : It's become clear that it is almost impossible to run an exit node : with the default exit policy in the USA, due to bittorrent DMCA abuse : spambots. I believe this means that we should try to come up with one : or more standard, reduced exit policy sets that allow use of the : majority of popular internet services without attracting bittorrent : users and associated spam. Giving in to the automated accusations of DMCA violations is a sad statement on the contemporary Internet. It seems the chilling effects of the DMCA are so palpable, no one wants to fight back any more, not users and not ISPs. See http://chillingeffects.org/ for more analysis and options on how to respond. Are there no ISPs/datacenters left in the USA willing to defend the First Amendment of the US Constitution and the user's legal protections under patent/trademark/copyright laws? Yeah, unfortunately what this means in practice is voting with your feet and leaving ISPs that simply do not want to devote the staff and the stress to dealing with this spam for you, regardless of the law. The problem is this drastically changes the effective market for bandwidth for Tor. Bandwidth costs are plummeting, and exit node operators (and thus the Tor network as a whole) are faced with a choice: you can pay less than $1/Mbit and go with an ISP that is less than ideal, but will still allow you to exit to most Internet services, or you put your foot down and end up moving your node every few months until you finally end up paying $20/Mbit with the RBN. Or, you shop around for non-US bandwidth. Sometimes, you just need to pick your battles. If you believe the DMCA is bullshit and want a full exit policy, I think the practical answer is Go outside the US for bandwidth. Or, be prepared to provider-hop for a good, long time. : 1. Low Abuse (above list, possibly minus 465, 587 and 563) : 2. Medium Abuse (above list, plus IRC) : 3. High Abuse (default exit policy) I wouldn't call them varying levels of abuse, as the name alone implies exiting Tor traffic generates abuse. It doesn't. Many exit nodes run without incident for years. We could probably better study/poll exit node operators and ask how many abuse complaints or dmca notices they receive over time to get more data on this topic. And of course, everyone forgets their Tor exit relay will transmit TB of normal traffic without incident. Yeah, perhaps that's not what we should call the options in the UI, but that is really what it boils down to. You can run an exit node for much longer without a complaint if you don't allow any form of IRC, SMTP, or NNTP. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpryUeGXmW6o.pgp Description: PGP signature
Re: Restricted Exit Policy Port Suggestions?
Thus spake Mike Perry (mikepe...@fscked.org): Thus spake and...@torproject.org (and...@torproject.org): Yeah, unfortunately what this means in practice is voting with your feet and leaving ISPs that simply do not want to devote the staff and the stress to dealing with this spam for you, regardless of the law. The problem is this drastically changes the effective market for bandwidth for Tor. Bandwidth costs are plummeting, and exit node operators (and thus the Tor network as a whole) are faced with a choice: you can pay less than $1/Mbit and go with an ISP that is less than ideal, but will still allow you to exit to most Internet services, or you put your foot down and end up moving your node every few months until you finally end up paying $20/Mbit with the RBN. Or, you shop around for non-US bandwidth. Sometimes, you just need to pick your battles. If you believe the DMCA is bullshit and want a full exit policy, I think the practical answer is Go outside the US for bandwidth. Or, be prepared to provider-hop for a good, long time. Now, what we *should* be doing is turning on the default first, and then reducing it back to the restriced policy *after* complaints arrive and the ISP refuses the budge. They are not going to cancel service immediately, and if you argue with them for a bit, you can at least try to educate some people (and maybe make it easier for the next relay they get). This is what I've done with my nodes, and this is what Moritz did too. So far though, ISPs have insisted that either bittorrent goes, or we go. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpXY8EmEgf2T.pgp Description: PGP signature
Re: Problem with Torbutton on OS-X PowerPC
torbutton-logger.js is the Torbutton message log system. It is used for development and debugging. Normally it shouldn't even be active. Based on this message and your previous one, its possible you have somehow changed it to report way more than it should. If you check the about:config url, and enter a search string of loglevel you should see the value extensions.torbutton.loglevel. If it is set to a value other than 4, you should reset it, and probably also go into your Torbutton settings and click Restore Defaults. Thus spake bao song (michaelw...@yahoo.com.au): When trying to read (and post anonymously) to the New York Times, I keep getting this error message below. I'm not sure where to send it. Sometimes, it comes up, but sometimes it crashes Firefox. clip here-- A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpLFPjTNE1a0.pgp Description: PGP signature
Re: Torbutton Documentation - Adversary Capabilities.
Thus spake Matthew (pump...@cotse.net): So to go back to the OP's question (my question)what do people think of my questions about JavaScript being able to obtain non-Tor IPs when wiping the cache? If you are also restarting the browser, or closing all windows, you are probably safe from most direct javascript attack vectors. The main danger is in leaving pages open after changing proxy settings. Then direct unmasking is possible. Identifiers can be stored in the page javascript itself. However, Javascript still has quite a bit of ability to fingerprint you based on your desktop resolution, user agent, timezone, any many other things. Torbutton does a good job of blocking a lot of the fingerprintable attributes, which make it hard to correlate your non-tor browser fingerprint to your tor browser fingerprint. More work still needs to be done here, but we do handle quite a bit of the major fingerprinting sources. See also: https://wiki.mozilla.org/Fingerprinting -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpshLOWegVQY.pgp Description: PGP signature
Re: Automated threat messages force limitation of Exit Policy (Softlayer)
Thus spake Moritz Bartl (t...@wiredwings.com): Please get back to us in a week or so with info on your abuse complaint rate with the new policy. I'll update https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment with the policy if it does in fact drastically reduce your abuse complaint raint. It does. There are still some old complaints by MediaSentry and BayTSP being forwarded, but the timestamp clearly show dates before I changed exit policy. Ok, I've updated https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment with this information. Let me know if there is anything else you think might be helpful, too. I will soon set up a (b)log about all incidents. I'll also talk to a lawyer (and friend of mine) if I am allowed to publish all complaints. A blog would be great. Another option besides publishing the actual complaints would be to draft template response letters for various cases and publish those. I'm sure other potential exit operators would greatly benefit from such a collection, and it would be a great thing to link to in that post. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpwIvGADh3YU.pgp Description: PGP signature
Re: Automated threat messages force limitation of Exit Policy (Softlayer)
Thus spake Moritz Bartl (t...@wiredwings.com): On 27.06.2010 04:17, Mondior Folimun wrote: I also allow 465 and 563. Those are used by authenticated SMTPS and NNTPS. There's also the chat ports: 1863 (MSN), 5190 (aim), 5050 (yahoo), 5222- 5223 (xmpp/gchat). Those haven't given me any problems either. Thanks. I have added them to the exit policy. Please get back to us in a week or so with info on your abuse complaint rate with the new policy. I'll update https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment with the policy if it does in fact drastically reduce your abuse complaint raint. (Though I suspect the SWIP will also help greatly. I am beginning to believe that these abuse-bot companies deliberately pick on new hosters who do not have their own IP allocation specified to bully them off the net). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpUwdiZEx6bI.pgp Description: PGP signature
Re: Automated threat messages force limitation of Exit Policy (Softlayer)
Thus spake Moritz Bartl (t...@wiredwings.com): BayTSP/MediaSentry/etc have heard all the excuses, including when they tagged my printer as serving up movies; they don't care. I fully expect they don't even read the responses, just check that a response was received. The response is probably then catalogued for some future court case. I'm not sure it was the most clever thing to do, but I wanted to have this cleared up. After sending a mail to five different BayTSP addresses, they finally came back to me, asking for my DMCA Designated Agent form filing with the US Copyright Office. They also said my counter notification doesn't meet the legal requirements... Can you post a copy of your counter-notification? Did they say in specific why they believe it doesn't meet the requirements? Also, are you familiar with chillingeffects? They catalog DMCA-related correspondence and provide some legal FAQs for counter-notice procedures. This is the section that should be relevant: http://www.chillingeffects.org/dmca512/faq.cgi#QID564 -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpgtyJnbLFGH.pgp Description: PGP signature
Re: Automated threat messages force limitation of Exit Policy (Softlayer)
Thus spake Moritz Bartl (t...@wiredwings.com): After running our 300MBit/s Tor node for less than a week, the US data center Softlayer has forced me to limit our exit policy to well-known ports after receiving 25 automated Torrent DMCA complaints this weekend and again more than 20 in the last two days. I hope that now that the policy is restricted they will allow the node to stay up. Out of curiosity, what exit policy are you now using? Perhaps we want to standardize on a policy that is effective at reducing these complaints. All these complaints list pretty much the same Torrents, have been issued by MediaSentry or BayTSP, and each offers to get back to them on changing email addresses and through a web form. For each single abuse case, I have tried to reach them to tell them about the node and its background, including the offer to block on IP/Port basis and the URL to EFF's legal page, but they didn't get back to me and didn't stop the spamming. I even filed a counter notification with written signature etc. I'm not a lawyer, but as a common carrier/service provider, you should be specifically exempt from these noticies, as you're not hosting content and are not the infringing party. If you've filed the counternotice, maybe suggest your ISP just blackhole future mails from the abuse sender? Did they SWIP you the IP block? Back in 2005, the EFF was actively looking for a test case to demonstrate that Tor exit nodes and other service providers are exempt via safe harbor provisions: http://archives.seul.org/or/talk/Oct-2005/msg00208.html As far as I know, they never got their test case. We can check to see if they are still looking for one, and what it might take for your situation to develop into a good test case for them. The abuse senders may actually have to initiate legal action against you first, which is unlikely. Being able to tell your ISP that the EFF will defend you in this unlikely situation might also help your position with them. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpJBxluNk2yd.pgp Description: PGP signature
Re: Downloading attachments with Tor - is this secure?
Thus spake Matthew (pump...@cotse.net): When you are go into for example Yahoo webmail (without Tor) and download an attachment (say a Word document or a photo) then your browser asks you where on your hard drive you wish to save that attachment. Then do the same thing using Tor (and Polipo). I assume the attachment downloads from Yahoo Mail (or whatever) through the three Tor nodes before being unencrypted at the final node and then is downloaded to my computer. In other words: the attachment (or for that matter any file downloaded in the same way) is never downloaded outside the Tor system - that is directly from the website to me bypassing the Tor nodes? Yes, if you use Torbutton, the attachment itself will be downloaded only via Tor. If you do not use Torbutton, your browser may autolaunch a plugin or helper application to download the attachment and display it, which may *not* happen via Tor. See https://www.torproject.org/torbutton/design/#SingleStateTesting for example exploits against non-Torbutton users. Also, when you open your attachment after downloading it (either via Tor or not), the program that opens it may be induced into making a network connection outside of Tor. For example, .doc files, .pdf files, .torrent files, and many many others can reference images, urls, IP addresses, and other content from the Internet, which causes the application that opened them to connect to a server outside of Tor. 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). This means that the exit node you use can replace or alter your document to unmask you (or worse, exploit your document reader and run arbitrary code). If you need to view these documents in a safe way, your best bet is to use VirtualBox or some other virtualization software to run a VM that you can disconnect from the network while you view the file, and roll back to a safe snapshot after you have viewed the file. Torbutton has a warning to attempt to explain all of this when you download documents handled by external applications, but it is a lot to get across in such a small amount of space. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp1RM2E0FR8T.pgp Description: PGP signature
Re: Hidden Services Hosting and DMCA
Thus spake Moritz Bartl (t...@wiredwings.com): On 12.06.2010 13:13, Marco Bonetti wrote: On 12/giu/2010, at 12.49, Moritz Bartl t...@wiredwings.com wrote: The barrier to create hidden services is quite high. I'm not too sure about this: you can run hidden services on tor clients which do not relay any traffic for the network. Starting a service is not that difficult: an home flat Internet connection and a low power computer are ideal for a small personal hidden service. That machine should be up 24/7, and you still need to maintain (ie. update) it. Actually, the uptime problem is a rather good reason not to consolidate hidden services with your exit node. An anonymous user on the I2P network used to run a public intersection attack on I2P router uptime vs eepsite (hidden service) uptime. It was rather easy to correlate which I2P nodes were running which services with this data. Of course, running hidden services in a separate VM might not have the correlation that using the same Tor process will, but host OS downtimes will still be correlated. If it is known that you are a large provider of hidden services, it becomes useful for an adversary to closely monitor your host OS for downtime to correlate to downtime of hidden services. As a related point, you need to be very careful about your opsec when providing services like this. While US law protects you from incriminating yourself by revealing your own encryption keys (probably), it does not protect you from divulging encryption keys of your users if you have them, nor does it protect you from court orders requiring you to install monitoring software into your user's systems to see what they are doing. Add in the correlation properties for hidden services or other data that may be available due to knowledge of your hosting setup (think apache+php versions, etc), and there may be a sufficient level of cause for such court orders to be binding. Of course, you can try to simply ignore these orders due to the fact that you're German and they're not likely to extradite you over them, but you'll probably lose your server, and you might have trouble entering the US at a later date then. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpfRAgqRsjIQ.pgp Description: PGP signature
Re: HTTPS Everywhere Firefox addon
Thus spake Runa A. Sandvik (runa.sand...@gmail.com): On Fri, May 28, 2010 at 4:34 AM, Mike Perry mikepe...@fscked.org wrote: The eventual idea is to allow an Adblock Plus style model, where users can submit and exchange rule files and eventually create subscriptions for the sites they use that partially support SSL. Have you seen https://crypto.stanford.edu/forcehttps/ ? (I haven't read the paper and I don't know much about it, but it might be worth a look). Yeah, this addon doesn't have a UI. It was a research implementation of the server-specified STS protocol (and the original source of this idea), which allows servers to specify the browser use HTTPS for certain paths. Our code is based on the NoScript implementation of STS, which was also amenable to creating rules. https://secure.wikimedia.org/wikipedia/en/wiki/Strict_Transport_Security -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpfz79S73d4f.pgp Description: PGP signature
Re: HTTPS Everywhere Firefox addon
Thus spake Erik de Castro Lopo (mle+to...@mega-nerd.com): Mike Perry wrote: In the meantime, we'll gladly accept submissions as xml files for inclusion in the extension itself. DuckDuckGo and Startpage.com are two alternative (specifically to google) search engines which promise not to record your IP address : ruleset name=DuckDuckGo rule from=^http://duckduckgo.com/; to=https://duckduckgo.com/ /ruleset ruleset name=Startpage rule from=^http://startpage.com/; to=https://startpage.com/ /ruleset Added. I hope these have been tested ;) -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpR1gKNHSLr2.pgp Description: PGP signature
HTTPS Everywhere Firefox addon
Peter Eckersley of the EFF and I wrote this addon this past week to make it easier to use Google's SSL search feature, among other mixed-mode SSL sites: https://www.eff.org/https-everywhere/ The addon is based on the NoScript STS/HTTPS forcing engine, with improvements in how rules are specified. Rules for our addon are specified as XML files that allow arbitrary URL rewrite substitution via regular expressions and exclude patterns. This allows us to write more complete and less error-prone rules than NoScript's include/exclude model allows. The eventual idea is to allow an Adblock Plus style model, where users can submit and exchange rule files and eventually create subscriptions for the sites they use that partially support SSL. We also hope that NoScript will share our rule format and update mechanisms, so that our rulesets will be interchangeable. Please give it a try and give us feedback. We also will be including the addon in the next alpha release of the Tor Browser Bundle. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpHYAX5TiXtv.pgp Description: PGP signature
Re: HTTPS Everywhere Firefox addon
Thus spake Jon Cosby (j...@jcosby.com): The eventual idea is to allow an Adblock Plus style model, where users can submit and exchange rule files and eventually create subscriptions for the sites they use that partially support SSL. We also hope that NoScript will share our rule format and update mechanisms, so that our rulesets will be interchangeable. Please give it a try and give us feedback. We also will be including the addon in the next alpha release of the Tor Browser Bundle. Very interesting. How will other sites be added? The rule files exist in two locations - the addon installed set, and the user installed set. The addon installed set are in your Firefox profile directory under the following path: ./extensions/https-everywh...@eff.org/chrome/content/rules User supplied files live in ./HTTPSEverywhereUserRules/ in the Firefox profile directory. We plan to have some form of UI to automatically install filters to the user directory from the web, similar to the Adblock Plus subscription list. In the meantime, we'll gladly accept submissions as xml files for inclusion in the extension itself. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpMULsVImz6Q.pgp Description: PGP signature
Re: Tor Exit Node hosting: torservers.net
Thus spake Moritz Bartl (t...@wiredwings.com): I set up a preliminary homepage at http://www.torservers.net/ For the original discussion (Tor Exit Node Sponsorship, looking for partners) see http://archives.seul.org/or/talk/May-2010/msg00058.html Basically it comes down to: I want to run another high bandwidth Tor exit and I am looking for individuals or companies to help sponsor it. To keep the noise down on OR-Talk/Tor-Relays, I have also created a mailing list for hosted tor exit discussion. If you want to stay informed, feel free to subscribe at http://www.freelists.org/list/torservers I am grateful for help, suggestions and other comments. Hi Moritz, I for one thing this is a great idea. I also welcome and encourage others to step up and try to start similar projects, once we have a good pattern down for a model that seems to work. However, a common problem with donation-run projects like this (and non-profits in general) is that everyone expects that the project will succeed because someone else will jump in before them and fund it/save it. Economists often call this the free-rider problem, but I think it is more closely related to Diffusion of Responsibility: http://en.wikipedia.org/wiki/Diffusion_of_responsibility Because of these fundamental aspects of human nature, I think it is very important to set goals such as: We will not start or maintain this project at the target level until/unless we have X months of future funding, where X is around 3 months initially, and ideally 6-12 months or more long term. I think its also very important for people to see what their level of dollar contribution gets them in terms of a percentage slice of exit bandwidth for the Tor network. At the volumes you will likely be purchasing bandwidth at, this is likely to be a very very compelling ratio. This financial data should be very public on your website. If the account balance ever drops below the level that can support roughly this many months of service, you should renegotiate your contract with your ISP to a level of service that you can support, and begin clamoring for more funding. Without this level of public accounting and public announcement of financial requirements, I imagine most people are just going to look at your site and assume Well, that's nice. Best of luck, hope it works out for you! and move on. I know, because that thought has been in the back of my mind (although I already spend quite a bit of my paycheck to support Tor-related infrastructure, so perhaps I am justified :). If instead it's clear to people that if they just donate that $10, $50, or $200, that it will make a significant impact to your service staying online for X amount of time with Y amount of additional capacity, they are way more likely to step forward. For what it's worth, the optimal one-time donation amount to request for addons.mozilla.org addons has been statistically determined to be $10. I'm not sure if the same psychological/political/financial dynamics will apply here, though. Your optimal requested donation amount may be higher or lower, depending upon the impact people believe they will have with that money, and any additional economies of scale you can present to them for donating more/reaching a higher level of total funding. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpnnlbAzLSa0.pgp Description: PGP signature
Re: Tor Exit Node hosting: torservers.net
Thus spake Moritz Bartl (t...@wiredwings.com): Let's look at what the Tor website has to say about its logo: https://www.torproject.org/trademark-faq.html.en If you're making non-commercial use of Tor software, you may also use the Tor onion logo (as an illustration, not as a brand for your products). Please don't modify the design or colors of the logo. You can use items that look like the Tor onion logo to illustrate a point (e.g. an exploded onion with layers, for instance), so long as they're not used as logos in ways that would confuse people. I have also tried to contact the Tor developers through this mailing list about my planned usage, but I guess I should do that more explicitly, and will do that now in a mail to execdir. Sorry. It is very important to me to do this with approval of the Tor community (that's why it started here). The problem is that the Tor developers really don't know - they primarily write software rather than practice law :). Andrew and the Tor Board of Directors typically need to discuss these issues with actual lawyers. One of the sticky issues with trademark protection though is that if you do not defend your mark in all applicable cases, you lose the right to defend it in cases you actually do care about. So please do not take any decisions about your use personally. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpg4zD3zOc18.pgp Description: PGP signature
Re: Tor Exit Node hosting: torservers.net
Cool Story, bro. Thus spake Scott Bennett (benn...@cs.niu.edu): Mike and Moritz, Would you both *please* stop posting each message to multiple lists? Thanks much. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpwX5jpdIrXf.pgp Description: PGP signature
Re: Tor Exit Node Sponsorship - looking for partners
Thus spake Timo Schoeler (timo.schoe...@riscworks.net): I don't want to be a party-pooper, but installing just another big node (like blutmagie) would still mean * relatively simple eavesdropping of exit traffic When speaking in terms of bandwidth, e.g. 150Mbps, then I'd rather spread it across n machines with 150Mbps/n each. The counterpoint is that scale really works in our favor the other way, along a number of different fronts: 1. Bandwidth will be significantly cheaper in bulk 2. ISPs take larger customers more seriously A. This means you're much more likely to get SWIP/ARIN 'whois' allocation to better handle abuse complaints. B. The ISP be much more likely to tolerate the occasional abuse complaint that makes it back to them. 3. There probably really aren't that many super-friendly yet affordable ISPs to begin with. I feel like all this means that the answer here is for us to try to create as many consolidated exit nodes like Olaf's and Moritz's as we can, rather than nickle and diming it with a lot of small time nodes that aren't going to last very long because ISPs don't want to deal with them. In fact, #3 especially underscores this point, because really, what is the point of creating 'n' small time nodes at one tor-friendly ISP? Anyone interested in surveilling that traffic will just watch the ISPs uplink either way.. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpxlZwDQKeEn.pgp Description: PGP signature
Re: opening up (exit policy) a bit ...
Thus spake John Case (c...@sdf.lonestar.org): So I am indeed an exit... This is totally incorrect. Tor uses exit nodes in the middle and possibly even guard position, depending on flags and general scarcity of guards. Ok, that was the answer to my first question. My follow-up questions were: If that is the case, is the distribution random ? Or is there some expected ratio I should see between non-exit relay traffic and port 80 exit traffic ? As of Tor 0.2.2.11-alpha, the ratios used by clients is listed in the consensus[1]*. See sections 3.2 and 3.4.3 of dir-spec.txt https://gitweb.torproject.org//tor.git?a=blob_plain;f=doc/spec/dir-spec.txt;hb=HEAD Have I complicated that ratio by having a very restrictive exit policy, or doesn't that matter ? (FWIW, I picked port 80 just as an example) You have, sort of. Because you do not exit to enough ports to get the 'Exit' flag, you will be treated as a middle or Guard-only node, depending upon your uptime. This means the following weights will apply to you in each of the three positions: Guard: Wgg (if you are a Guard, otherwise 0) Middle: Wmg (if you are a Guard, otherwise Wmm) Exit: Weg (if you are a Guard, otherwise Wem) In the current weight implementation we Handle bridges and strange exit policies: Wgm=Wgg, Wem=Wee, Weg=Wed This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. As to the ratio of your exit to non-exit load, that depends heavily on if you have the Guard flag, if you are a Directory Mirror, what percentage of the exit traffic actually flows over port 80, and how many clients have upgraded to the new algorithm vs the old. *[1]. If there is a bug or other issue, these weights may be temporarily absent from the consensus. Currently, Bug 1294 is causing us to drop weights when there are no Guard+Exit flagged nodes, which can happen when Exits are scarce. When weights are absent, clients fall back to the previous client-based weighting algorithm. By not having an actual 'Exit' flag, you will be treated as a non-scarce Guard or middle node for purposes of this old algorithm too, and should see more load accordingly. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpBTg3WwcQ17.pgp Description: PGP signature
Re: opening up (exit policy) a bit ...
Thus spake Mike Perry (mikepe...@fscked.org): This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. On second thought, this is not fully correct. You will in theory get slightly more load than if you were just a Guard/Middle node. Since we do not currently balance among different exit port classes, you might still get less load than a full-on Exit when Exits are scarce, because 80 might not carry that much traffic in terms of bytes as other ports. Not an easy question to answer in either case. Having good answers to these questions might help us refine our load balancing algoriths further. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpgktUvYXvIV.pgp Description: PGP signature
Re: opening up (exit policy) a bit ...
Thus spake John Case (c...@sdf.lonestar.org): On Sat, 8 May 2010, Mike Perry wrote: This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. On second thought, this is not fully correct. You will in theory get slightly more load than if you were just a Guard/Middle node. Since we do not currently balance among different exit port classes, you might still get less load than a full-on Exit when Exits are scarce, because 80 might not carry that much traffic in terms of bytes as other ports. Not an easy question to answer in either case. Having good answers to these questions might help us refine our load balancing algoriths further. Thanks. So, it's hard to say, but I can assume there will be significant exit traffic, even with just one TCP port valid for exit... I suppose I could see the ratio of actual connections by simply running 'netstat', yes ? If my orport and dirport are 9001/9030, and I am allowing port 80 exit, then all netstat connections showing port 80 are exit connections, so I could (roughly) calculate these numbers myself, right ? Yes. Though this brings up the other approxmiation of the load balancing algorithms, which is that we balance per-connection, which have non-uniform bandwidth use across ports and protocols. According to http://www.cs.washington.edu/homes/yoshi/papers/Tor/PETS2008_37.pdf, 92.5% of the connections through Tor are HTTP, accounting for 58% of the traffic. So you should see a much larger number of TCP connections (and possibly also total traffic) as comparted to if you also added port 443 and/or 6667 to gain the Exit flag. Especially if you are a Guard. The extra data that we would need beyond that published in the paper above is a data rate per connection by port, in addition to connection duration information. Gathering this data in a safe fashion, and figuring out how to use it are open questions (though probably not terribly difficult ones). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp5pRVfNmmWm.pgp Description: PGP signature
Re: Tor configs
These are controlled by Torbutton's Preferences-Security Settings-Headers-Don't send referer during Tor usage option, which sets the appropriate Firefox settings. Thus spake zzzjethro...@email2me.net (zzzjethro...@email2me.net): Hello. I don't remember who originally sent me the link to cross check config settings for Firefox with Tor. I have been doing that cross checking fort my Mac, and noticed these two that are not there. They are as follows: I have -network.http.sendRefererHeader 0 and -network.http.sendSecureXSiteRefererfalse These values are both changed to 2 and true when I enable Torbutton. Aren't these configurations ways that web sites log and track users and shouldn't they remain 0 and false to keep one safe and anonymous? Thanks -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpKQshBs2DHd.pgp Description: PGP signature
Re: circuit construction timeout values
Thus spake Scott Bennett (benn...@cs.niu.edu): I've noticed something odd in info-level log messages that show circuit build timeout values being set. Given that the maximum length of circuit construction time history of 5000 construction times has already been reached, it seems weird to see huge jumps in the timeout values from one such message to the next. Here are two examples. So I'm wondering what is going on here. If the timeout being set is supposed to reflect some sort of smoothed values of a time series of circuit construction time, where the smoother is 5000 values wide, how can such jumps occur? I guess I don't understand what algorithm is being used here. Any clarification would be appreciated. Thanks in advance! Hi Scott. There are a couple bugs in the algorithm used. One of the problems is that the Xm pareto value needs to be chosen a bit more intelligently to deal with samples coming from multiple guards. The other problem is that synthetic timeouts need to be clipped to a lower value. The algorithm is defined at https://gitweb.torproject.org//tor.git?a=blob;f=doc/spec/proposals/151-path-selection-improvements.txt;h=363eebae8423e4c25310dc28b6f2c232cf20e533;hb=HEAD (don't you love our nice, short, easy-to-understand-and-predict gitweb urls? ;) The bug to track this is at: https://trac.torproject.org/projects/tor/ticket/1335 If you could upload the state file from that Tor to that ticket (after stripping out the EntryGuard info), that would give me another datapoint to test against, and to ensure that these are in fact the problems you are seeing. Even 65 is a bit high for a circuit timeout, so I suspect you are actually seeing both issues here. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp4b3bBEHPFH.pgp Description: PGP signature
Re: Torbutton 1.2.5 Released
Thus spake Mike Perry (mikepe...@fscked.org): This release provides the ability to automatically redirect to an alternate search engine when Google presents you with a captcha. The options are ixquick, bing, yahoo, and scroogle. In addition, potentially identifying information (such as language, OS version, and Firefox version) will be stripped off of Google Search Box queries by default. This release will also only update Torbutton via Tor by default, to address concerns with data retention by addons.mozilla.org, as well as potential issues with Tor users being revealed via their Torbutton update requests. I've written a bit more on the reasoning behind these two changes at: https://blog.torproject.org/blog/torbutton-release-125-google-captchas-and-addonsmozillaorg -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpNAjz4Gu7PJ.pgp Description: PGP signature
Torbutton 1.2.5 Released
Torbutton 1.2.5 has been released at https://www.torproject.org/torbutton/ This release provides the ability to automatically redirect to an alternate search engine when Google presents you with a captcha. The options are ixquick, bing, yahoo, and scroogle. In addition, potentially identifying information (such as language, OS version, and Firefox version) will be stripped off of Google Search Box queries by default. This release will also only update Torbutton via Tor by default, to address concerns with data retention by addons.mozilla.org, as well as potential issues with Tor users being revealed via their Torbutton update requests. Here is the complete changelog entry for 1.2.5: * bugfix: bug 1169: Fix blank popup conflict with CoolPreviews * bugfix: bug 1246: Fix IST and other HH:30 timezone issues. * bugfix: bug 1219: Fix the toggle warning loop issue on settings change. * bugfix: bug 1321: Fix a session restore bug when closing the last window * bugfix: bug 1302: Update useragent to FF3.6.3 on WinNT6. * bugfix: bug 1157: Add logic to handle torbutton crashed state conflicts * bugfix: bug 1235: Improve the 'changed-state' refresh warning message * bugfix: bug 1337: Bind alert windows to correct browser window * bugfix: bug 1055: Make the error console the default log output location * bugfix: bug 1032: Fix an exception in the localhost proxy filter * misc: Always tell a website our window size is rounded even if it's not * misc: Add some suggestions to warning about loading external content * new: Add option to always update Torbutton via Tor. On by default * new: Redirect Google queries elsewhere on captcha (default ixquick) * new: Strip identifying info off of Google searchbox queries -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpgNHvQzivR0.pgp Description: PGP signature
Re: Torbutton 1.2.5 Released
Thus spake Programmer In Training (p...@joseph-a-nagy-jr.us): On 04/09/10 21:26, Mike Perry wrote: Torbutton 1.2.5 has been released at https://www.torproject.org/torbutton/ This release provides the ability to automatically redirect to an alternate search engine when Google presents you with a captcha. The options are ixquick, bing, yahoo, and scroogle. In addition, snip Is it impossible to use Startpage in this manner? I have a search widget for both their normal and https site in FF and I like them better than ixquick. What is the difference between StartPage and Ixquick? I thought startpage was just another domain ixquick happened to own? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpqJpRxRSWjV.pgp Description: PGP signature
Re: google gears
Thus spake M (moeedsa...@gmail.com): If one is running a wordpress blog using TOR, will installing Google gears in order to speed up the process compromise anonymity in any way? Will it bypass the proxy settings or anything? Google Gears has not been fully audited for anonymity, so we don't yet know the specific answer to this, but the outlook isn't good. Gears components can store arbitrary data from websites, and the current Gears implementation does NOT obey private browsing mode in either Firefox or Chrome to conceal gears data. Gears data is also not cleared when you clear private data in either browser. I believe it does use Firefox's network stack, so proxy settings should most likely be obeyed. However, it is possible it can phone home to update its component cache or to ping your gears websites at any time, regardless of your current Tor mode. It is also likely that gears data can be transfered over http as opposed to https, which would mean that any exit node can spoof google gears urls and probe your installation for gears data, which may include authentication information or unique identifiers. Risky business. I would recommend against it unless you're prepared to audit it with wireshark first. If you do, please report back! -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpKBNn2zLBrc.pgp Description: PGP signature
