Re: [tor-talk] CloudFlare
On Fri, 19 Apr 2013 00:35:58 +, grarpamp wrote: ... > > you are coming off as a clueless jerk. ... > However the recent direct name calling and abuse amongst > people on this list needs to stop right now. You failed to demonstrate an understanding of the specific situation of wikipedia which makes the response in question not entirely unappropriate. > Yes, it's a hard human problem. One for which I think there > are better solutions than just IP based blocking. Now, what would they be in this case? As I understand the problem we have very few people that are so toxic to the wikipedia community that they simply need to get blocked. If you don't block tor just like any other IP range those jerks appear from then you need either a way to identify those jerks (obviously impossible given tor's properties), or identify the good guys coming in via tor (which is something we might not want to, re anonymity). The only idea that comes to my mind is a reputation system, but how do you tell apart the cooperative newbie from the fivehundert accounts of the jerk initially? (Reputation needs to be built into a site, see stackoverflow.com, i guess. Reputation is also 'I already have an account', but the question how to allow to get one via tor without opening up for the bad guy.) > My problem is with simple IP blocking, especially when you take > out an entire shared access system such as Tor with it. It's crude > and takes the ham with the spam. Wikipedia obviously thinks different - that spam is too poisonous to accept with the ham. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
Matthew Finkel: > On Thu, Apr 18, 2013 at 09:57:06PM +, Jacob Appelbaum wrote: >> Matthew Finkel: >>> On Thu, Apr 18, 2013 at 09:01:21AM +, Matt Pagan wrote: > They're based in San Francisco, along with Craigslist (which > is another misguided arbitrary blocker of Tor exits). > Any other SF based companies that could benefit from > a visit or hackerspace talk about why they should not > be blocking Tor? Yelp is based in San Francisco. So is Pinterest. Getting the Wikimedia Foundation (also based in San Francisco) to come over would be a huge victory, IMO. >>> >>> Wikimedia is actually willing to discuss an alternative setup if a >>> usable one is found. Their current implementation is not really >>> acceptable, but there also isn't really a working/implemented alternative >>> solution, at this point (and it's not exactly at the top of their list >>> to implement their own). >> >> I was involved in writing the DNSBulkExitList program specifically for >> Wikipedia at the request of Tim S. At the time, I believe that it was >> better than simply blocking every Tor node - it only blocks exit nodes >> that allow exiting to Wikipedia. >> > > Interesting, I assume this was before Onionoo was around. I understand > why it was/is necessary. Isn't it still being used? > >> It is possible to request a special flag on a Wikipedia account that is >> granted by way of some special handshake. It is possible to take an >> already created account and use it for edits as the flag overrides the >> Tor block. >> > > Yes, and it's a good solution, assuming one already has an account. The > real issue is creating an account anonymously and then gaining the > privilege to edit with that account...and... Right - that and the general class system that it promotes - "hey, you know someone, cool, you can have anonymity" - whoops. Talk about liability? One wonders... > >> A workable solution would be to continue to use such a list to detect >> Tor usage and then to ensure that we now allow new accounts to be >> created over Tor. The MediaWiki should ensure that HSTS is sent to the >> user and that the user only ever uses HTTPS to connect to Wikipedia. >> > > Yes, I completely agree. How do we make this happen? > >> I think we should ensure that Wikipedia understands that the account was >> created with Tor and that the user may be using this to circumvent >> censorship, to protect what they are reading or editing from their local >> network censors or surveillance regime as well as to protect IP address >> information that the US currently doesn't really protect (see USA vs. >> Appelbaum; re: my Twitter case). Since the US can see a lot of the >> traffic to Wikipedia, I'd guess that this is important worldwide. >> > > Again, I agree. Is there a general disagreement about these points in the Wikipedia community? > >> If the user is abusive and an IP block would normally apply, Wikipedia >> would not block by IP but would rather use the normal Wikipedia process >> to resolve disputes (in edits, discussions, etc) and if the account is >> just being used for automated jerk behavior, I think it would be >> reasonable to lock the account, perhaps even forcing the user to solve a >> captcha, or whatever other process is used when accounts are abused in >> an automated fashion. >> > > The fear associated with taking this path is that there will be an > overwhelming amount of "jerk behavior" such that it overwhelms the > wikipedia community and therefore discourages volunteers from actually > reviewing edits. The correct course of action is a difficult problem > (which is why this is likely still unsolved). It may be good to also > have a trial period where the user must submit x number of edits that > are not-deemed-to-be-jerk-behavior before they will be able to edit the > live page, just a thought though. I have thought of such things too - I think that a random review partner might be a reasonable purgatory for those that desire privacy - they get security, privacy and anonymity for reading; if they want to edit, it takes a bit of effort. > >> Most of that isn't technical - it is a matter of accepting that some of >> us are not free. Some of us who are not free require systems like Tor to >> participate in the Free Culture community curated by the Wikipedia >> community on Wikipedia. Some of us will then be free to be part of that >> community and perhaps, if we work smartly, other freedoms will follow >> from the knowledge of the community. >> >> All the best, >> Jacob > > I think people (in general) lose sight of this, often, and it's important > that we remember why we do what we do, whether supporting a free and > uncensored internet (and world) or supporting a site that provides a > wealth of content not (freely) accessable anywhere else. > I agree. > With respect to the WikiMedia and Tor communities, it seems as if both > are, understandably, more concernin
Re: [tor-talk] CloudFlare
Gregory Maxwell: > On Thu, Apr 18, 2013 at 2:57 PM, Jacob Appelbaum wrote: >> It is possible to request a special flag on a Wikipedia account that is >> granted by way of some special handshake. It is possible to take an >> already created account and use it for edits as the flag overrides the >> Tor block. > > The flag is called ipblock-exempt > Right - it might make sense to make a second flag - anonymity-allowed and set it to true for everyone until they abuse it. > You can see the the list of uses on english wikipedia that have it here: > > http://en.wikipedia.org/w/index.php?title=Special%3AListUsers&username=&group=ipblock-exempt&limit=500 > (bot accounts and administrators also inherit this ability without the > ipblock-exempt flag) That page is a very predictable side effect of having a flag for people with strong need for privacy. I guess we know which Wikipedia users are valuable or doing something interesting, right? o_0 > > (As an aside, your own account was previously flagged this way, (by > Wikimedia's chairman of the board), but the flag has since been > removed because your account has been inactive: > http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=&page=User%3AIoerror&year=&month=-1&tagfilter= > ) > I did not know that the flag times out - that is rather sad - privacy is automatically removed, even for people who don't abuse it? Is there any way to get it back? Or do I now have to deanonymize myself again and attempt some other secret handshakes? :( > [snip] >> I think we should ensure that Wikipedia understands that the account was >> created with Tor and that the user may be using this to circumvent >> censorship, to protect what they are reading or editing from their local >> network censors or surveillance regime as well as to protect IP address >> information that the US currently doesn't really protect (see USA vs. >> Appelbaum; re: my Twitter case). Since the US can see a lot of the >> traffic to Wikipedia, I'd guess that this is important worldwide. > > I've been generally unable to convince people that surveillance of > Wikipedia access is both happening and actually important. The people > participating in the creation and administration Wikipedia (and > likewise those employed by the Wikimedia foundation) enjoy the > privileged of having the greatest intellectual freedom that has ever > been enjoyed by anyone anywhere. This is unsurprising: People without > substantial freedom of all kinds are not the most likely to go about > assembling a Free Encyclopedia. Like any other privileged it's not > always obvious to the beholder. > I know a few people that work/ed at the Wikimedia and they did not suffer from such blindness. I think though that the best retort to claims that it isn't happening is actually found on the Wikipedia servers themselves: http://meta.wikimedia.org/wiki/XFF_project I seem to remember the full list of proxies: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/TrustedXFF/trusted-hosts.txt > The idea that someone's Wikipedia editing (or, much less _reading_) > habits might be highly private and personal and likely to cause harm > if monitored isn't really appreciated by people who really find that > kind of monitoring hard to believe (even, ironically, when it's > currently happening to them— the illusion of intellectual freedom is > greater than the actual intellectual freedom) > How could anyone suggest that they do not have massive user surveillance with such a huge list of proxies *in their own source code* tree? Here is the list again: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/TrustedXFF/trusted-hosts.txt?view=co > I was unsuccessful in the last major datacenter reworking convincing > the technical staff to adopt an architecture which could reasonably > scale to supporting SSL always on for all readers (one where SSL > wasn't handled by a separate cluster but was instead run in parallel > on the existing non-ssl frontends). > I'm sorry to hear that. > Unfortunately, I think it will probably take someone being killed for > reasons considered unjust by western standards before the considerable > expenditure necessary to HSTS the entire site will be justified. > Pressure on this front needs to come from activists, not from > technology people. I tend to agree. Though I'd be happy to give a talk at a brown bag lunch or something, if it would help. > >> A workable solution would be to continue to use such a list to detect >> Tor usage and then to ensure that we now allow new accounts to be >> created over Tor. The MediaWiki should ensure that HSTS is sent to the >> user and that the user only ever uses HTTPS to connect to Wikipedia. > > Account creation via tor is explicitly and intentionally disabled. I remember, I'm sad to hear that this hasn't changed. > >> If the user is abusive and an IP block would normally apply, Wikipedia >> would not block by IP but would rather use the
Re: [tor-talk] CloudFlare
>> Tor may present a different *class* of abuse than other categories >> of abusable IP's. > There is no particular blocking efficiency gain that comes from using > exitlists relative to other kinds of abuse sources. The skill needed for the masses to download and use Tor for personal style abuse is far less than for them to have formerly attempted old school proxy chains. Would not an analysis of the type of misdeeds carried out via all the various abuseable sources yield at least measurable, if not substantial, weightings for each class of source towards particular classes of misdeeds. Finance/deep crackers use some subsets, packet scanners and flooders some others, data leeches others. >> 'Really? You mean we >> can turn a flag and whack 2^8 at zero cost, sweet, we just eliminated a >> help desk drone's worth of salary from our costs' > You might think you're being only slightly insensitive to other > people's needs, but I am here to tell you that I am inside the both > communities Many of us have hats in both places. I've seen places where IP based whack a mole was phrased pretty much that exact way. Or as 'sweet, now we don't even have to perform the balancing act.' > you are coming off as a clueless jerk. We're all free to debate each other, point out this or that, supply links and so forth. That's all good :) And I even expressed some rare 'fucking' frustration towards general corporatedom / the state of affairs regarding the blocking subject. However the recent direct name calling and abuse amongst people on this list needs to stop right now. > actually hard and it involves real trade-offs. Yes, it's a hard human problem. One for which I think there are better solutions than just IP based blocking. >> Nyms wouldn't be usable by legitimate anons unless they are >> free from linkable properties. > > I suggest you familiarize yourself with the previously proposed > solutions before responding. There may indeed be some that are these days. I can't research and know everything. And if there are, then we can all, as users and advocates, get them wiki'd and/or suggested out to sites as applicable. >> On the other hand, a little development cost by a site can put up some >> pretty big walls against abuse in the form of time delayed accounts, >> captchas now and then, good filters on your i/o, etc. And often cost >> less than whatever service you pay to keep you 'safe'. > > The purpose of any anti-baddness system must be to distinguish between > good and bad users. Sure, some solutions are archaic and non-adaptive/automated, yet still better in certain areas than IP blocking. Etcetera also includes shifting the cost to community moderation, scoring and ranking systems, rollbacks, warnings/appeals for users, anonymous deposit/forfeiture of token funds, combined solutions and so on. There are lots of options beyond simple IP blocking. Particularly on account based systems. My problem is with simple IP blocking, especially when you take out an entire shared access system such as Tor with it. It's crude and takes the ham with the spam. I think the good outweighs the bad. We're all working for something better :) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
> Though I don't think I'd apply a permaban, because whatever IP is bothering > you will eventually get pulled at the source before long. The IP wont' eventually be pulled if it's on rdsnet.ro. ;) In any case, I'm not asking what you would do. I'm telling you what I do. I keep lists of IP ranges whose individual IPs will be permabanned if they fall in that range. I will continue this practice at my hobby sites where I pay for hosting even if you or someone else 'minds the approach'. My opinion is you can implement your policy at sites you pay for and run. I implement mine at sites I pay for and run. > Unless their profits come from spam, bribing Russian officials with cracked > CC's, etc. In fact there seem to be plenty of IPs that do not get pulled at the source as a result of hacking, cracking, scraping, trolling or other behaviors someone running a blog or forum might consider ban worthy. Believe it or not, some anonymizing services who do not take bribes from Russian officials also do not monitor their users and appear to take absolutely no steps prevent those who try to hack, spam, scrape or fingerprint from using their service. Can you imagine that?! Admittedly, the way some of these services work, a specific person scraping, hacking or spamming might have to cycle through a different IP every 10 minutes, but if they are persistent scrapers, they may very well come back on one they used before. There is no guarantee that IP will ever be pulled at the source. In fact, if someone were to complain to the ISP, the person running an exit node might defend the connections on the basis that it's just a TOR node exit, it's not him he has no control over what goes out and basically, it's not his problem. If the ISP is TOR friendly, they may accept that and not pull the IP. An IP that has been observed hacking, scraping, spamming and it doesn't get pulled eventually. Can you even imagine such a thing?!?! TOR aside, I think you are being naive about what happens with particular IPs. Some companies make sell cheap shared hosting; that's their business. It's a perfectly legitimate one. Once such service might have server used by numerous accounts all associated with a particular ip, say 123.123.123.123. A person on one of those accounts could load up a script that permits them to spam, scrape, hack, fingerprint, or set up an open proxy that others could use to spam, scrape, hack, finger print or do whatever they prefer. This person would operate a while before complaints rolled in. Then they might get kicked off and move to another company with cheap shared hosting. Now in principle, 123.123.123.123 is clean. Hurray! Unfortunately, the company's business still provides cheap shared hosting. If the hosting company succeeds in keeping other undesirables off, my blog will see zero traffic from that site. But given their business model, likely as not someone who got kicked off from some other cheap hosting company will sign up and that undesirable person who gets one will load up a script and start hacking, scraping, fingerprinting or setting up an open proxy. Since the IP is associated with a server whose intended service is to serve pages, not visit other pages, when that IP visits my blog, it's generally going to be traffic I find undesirable. Also some dedicated servers provide hosting to scrapers of various sorts. These include seo companies, copyright companies, reputation protection companies and all sorts of other businesses that make a living scraping. Many of those hosts will not cancel a customer account for scraping. There really is no reason to believe that such IPs will be pulled at the source. If one wishes to avoid incurring high costs to help these scrapers carry out their business model, one has to ban them. If the IP is at a colo facility, a dedicated or cheap hosting service, the most practical thing for a one person hobby blogger to do is ban that IP permanently. As far as I can see, there is very little lost banning these IPs indefinitely. For example, a year or so ago I tested an English language based > For example, a year or so ago I tested an English language based > predominantly North American, slightly Euro, dating site against Tor. Though > they had no stated policy to be sure of it, from my tests it appeared that > from English speaking exit countries, Tor worked fine. If I let Tor float or > come in via say Brazil, the account would be silently deleted. This lead to > belief that they utilized the 'unfathomable' policy. Again, their actual > policy is unknown, I could have just been using unlucky IP's. Brazil? Blocking IPs from Brazil may seem unfathomable to you. It's not unfathomable to me! I've blocked the entire country of Brazil from time to time using Cloudflares convenient system that lets me block countries. It took a while to find which of the ranges were the really bad ones, once I did, I blocke
[tor-talk] uscribe
Hi tor-talk I wish to unscribe now. Don raven131, raven...@cox.net 04/18/2013 ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
On Thu, Apr 18, 2013 at 01:45:12PM -0700, Gregory Maxwell wrote: > On Thu, Apr 18, 2013 at 1:01 PM, Matthew Finkel > wrote: > > Wikimedia is actually willing to discuss an alternative setup if a > > usable one is found. Their current implementation is not really > > acceptable, but there also isn't really a working/implemented alternative > > solution, at this point (and it's not exactly at the top of their list > > to implement their own). > > It's the same old story: There are persistent highly annoying trouble > makers— not even many of them— who are effectively deterred by > blocking whatever proxies they use. Eventually they hit tor, and thus > tor must be blocked from editing. This abuse isn't imaginary. > > The various magical nymtoken ideas would probably be acceptable— they > just need to make it so that an unbounded supply of identities is not > any cheaper than it already is— but they need to be implemented and > not have a high deployment or operating cost. > Yeah, the various ideas for nym systems was what I was implying and the "limited resource" aspect of them is definitely hard to specify. > There are some people who hold the position that instant doubling of > identities (w/ and w/o tor) that attackers would get is not acceptable > but with things like > http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2013-04-08/News_and_notes > and Tor's effectiveness at evading censorship I expect that most can > be convinced that it's worth it. Harder would be the fact that > English Wikipedia (and many other larger Wikipedias) blocks most data > centers and VPS services with large rangeblocks as they get used as > account multipliers by socks and an obvious nym implementation would > partially defeat that. And I think given the current situation this is an understandable action, however it should not be necessary and sadly this is most detrimental to the users who rely on Tor to reach the uncensored internet. - Matt ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
On Thu, Apr 18, 2013 at 09:57:06PM +, Jacob Appelbaum wrote: > Matthew Finkel: > > On Thu, Apr 18, 2013 at 09:01:21AM +, Matt Pagan wrote: > >>> They're based in San Francisco, along with Craigslist (which > >>> is another misguided arbitrary blocker of Tor exits). > >>> Any other SF based companies that could benefit from > >>> a visit or hackerspace talk about why they should not > >>> be blocking Tor? > >> > >> Yelp is based in San Francisco. So is Pinterest. Getting the Wikimedia > >> Foundation (also based in San Francisco) to come over would be a huge > >> victory, IMO. > >> > > > > Wikimedia is actually willing to discuss an alternative setup if a > > usable one is found. Their current implementation is not really > > acceptable, but there also isn't really a working/implemented alternative > > solution, at this point (and it's not exactly at the top of their list > > to implement their own). > > I was involved in writing the DNSBulkExitList program specifically for > Wikipedia at the request of Tim S. At the time, I believe that it was > better than simply blocking every Tor node - it only blocks exit nodes > that allow exiting to Wikipedia. > Interesting, I assume this was before Onionoo was around. I understand why it was/is necessary. > It is possible to request a special flag on a Wikipedia account that is > granted by way of some special handshake. It is possible to take an > already created account and use it for edits as the flag overrides the > Tor block. > Yes, and it's a good solution, assuming one already has an account. The real issue is creating an account anonymously and then gaining the privilege to edit with that account...and... > A workable solution would be to continue to use such a list to detect > Tor usage and then to ensure that we now allow new accounts to be > created over Tor. The MediaWiki should ensure that HSTS is sent to the > user and that the user only ever uses HTTPS to connect to Wikipedia. > Yes, I completely agree. > I think we should ensure that Wikipedia understands that the account was > created with Tor and that the user may be using this to circumvent > censorship, to protect what they are reading or editing from their local > network censors or surveillance regime as well as to protect IP address > information that the US currently doesn't really protect (see USA vs. > Appelbaum; re: my Twitter case). Since the US can see a lot of the > traffic to Wikipedia, I'd guess that this is important worldwide. > Again, I agree. > If the user is abusive and an IP block would normally apply, Wikipedia > would not block by IP but would rather use the normal Wikipedia process > to resolve disputes (in edits, discussions, etc) and if the account is > just being used for automated jerk behavior, I think it would be > reasonable to lock the account, perhaps even forcing the user to solve a > captcha, or whatever other process is used when accounts are abused in > an automated fashion. > The fear associated with taking this path is that there will be an overwhelming amount of "jerk behavior" such that it overwhelms the wikipedia community and therefore discourages volunteers from actually reviewing edits. The correct course of action is a difficult problem (which is why this is likely still unsolved). It may be good to also have a trial period where the user must submit x number of edits that are not-deemed-to-be-jerk-behavior before they will be able to edit the live page, just a thought though. > Most of that isn't technical - it is a matter of accepting that some of > us are not free. Some of us who are not free require systems like Tor to > participate in the Free Culture community curated by the Wikipedia > community on Wikipedia. Some of us will then be free to be part of that > community and perhaps, if we work smartly, other freedoms will follow > from the knowledge of the community. > > All the best, > Jacob I think people (in general) lose sight of this, often, and it's important that we remember why we do what we do, whether supporting a free and uncensored internet (and world) or supporting a site that provides a wealth of content not (freely) accessable anywhere else. With respect to the WikiMedia and Tor communities, it seems as if both are, understandably, more concerning with furthering their cause than figuring out a way to work together (not necessarily the devs of the projects, but the communities as a whole). However, as far as I can tell, if we're both going to be successful in our goals, we're going to need to be able to cooperate and determine a solution that fulfills the needs of both groups - at this point it feels as if Tor users prefer to single out WikiMedia as not being Tor friendly and the WikiMedia community doesn't see the benefit of allowing Tor users to contribute (yes, these are harsh generalizations, sorry). I really think a solution would be a considerable benefit to everyone. - Matt
Re: [tor-talk] Abusing resource:// uri in Firefox Browser
It's in the ticket system as #8725, and I was able to duplicate this bug. Somehow preventing outside resource_uri access or pretending to be a non-firefox browser would obviate this quirk. https://trac.torproject.org/projects/tor/ticket/8725 ~Griffin ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
On Thu, Apr 18, 2013 at 2:57 PM, Jacob Appelbaum wrote: > It is possible to request a special flag on a Wikipedia account that is > granted by way of some special handshake. It is possible to take an > already created account and use it for edits as the flag overrides the > Tor block. The flag is called ipblock-exempt You can see the the list of uses on english wikipedia that have it here: http://en.wikipedia.org/w/index.php?title=Special%3AListUsers&username=&group=ipblock-exempt&limit=500 (bot accounts and administrators also inherit this ability without the ipblock-exempt flag) (As an aside, your own account was previously flagged this way, (by Wikimedia's chairman of the board), but the flag has since been removed because your account has been inactive: http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=&page=User%3AIoerror&year=&month=-1&tagfilter= ) [snip] > I think we should ensure that Wikipedia understands that the account was > created with Tor and that the user may be using this to circumvent > censorship, to protect what they are reading or editing from their local > network censors or surveillance regime as well as to protect IP address > information that the US currently doesn't really protect (see USA vs. > Appelbaum; re: my Twitter case). Since the US can see a lot of the > traffic to Wikipedia, I'd guess that this is important worldwide. I've been generally unable to convince people that surveillance of Wikipedia access is both happening and actually important. The people participating in the creation and administration Wikipedia (and likewise those employed by the Wikimedia foundation) enjoy the privileged of having the greatest intellectual freedom that has ever been enjoyed by anyone anywhere. This is unsurprising: People without substantial freedom of all kinds are not the most likely to go about assembling a Free Encyclopedia. Like any other privileged it's not always obvious to the beholder. The idea that someone's Wikipedia editing (or, much less _reading_) habits might be highly private and personal and likely to cause harm if monitored isn't really appreciated by people who really find that kind of monitoring hard to believe (even, ironically, when it's currently happening to them— the illusion of intellectual freedom is greater than the actual intellectual freedom) I was unsuccessful in the last major datacenter reworking convincing the technical staff to adopt an architecture which could reasonably scale to supporting SSL always on for all readers (one where SSL wasn't handled by a separate cluster but was instead run in parallel on the existing non-ssl frontends). Unfortunately, I think it will probably take someone being killed for reasons considered unjust by western standards before the considerable expenditure necessary to HSTS the entire site will be justified. Pressure on this front needs to come from activists, not from technology people. > A workable solution would be to continue to use such a list to detect > Tor usage and then to ensure that we now allow new accounts to be > created over Tor. The MediaWiki should ensure that HSTS is sent to the > user and that the user only ever uses HTTPS to connect to Wikipedia. Account creation via tor is explicitly and intentionally disabled. > If the user is abusive and an IP block would normally apply, Wikipedia > would not block by IP but would rather use the normal Wikipedia process > to resolve disputes (in edits, discussions, etc) The blocking of tor (and other IP) addresses is never intended to be a part of the regular "disagreeable behavior for otherwise well meaning and sane contributors" process. It doesn't aid in that process. In theory blocking is really only a measure against people who are malicious or (temporarily?) mentally ill. Wikipedia will try to reason you out of doing something, and if that fails, _tell_ you to stop doing something, and then only block you if you don't listen. > and if the account is > just being used for automated jerk behavior, I think it would be > reasonable to lock the account, perhaps even forcing the user to solve a > captcha, or whatever other process is used when accounts are abused in > an automated fashion. Mostly the really automated behavior is not that huge of an issue— the thousands of wiki administrators have access sophisticated to automated behavioral blocking tools (I think the rule expression language in abusefilter is turing complete), account creation requires solving a captcha... and marketers have discovered that spamming Wikipedia can have certain unexpected negative effects once caught (like completely disappearing from search engine indexes), so only idiot marketers spam overtly. But what is an issue is an issue is _non-automated_ or semi-automated jerk behavior. A single bored kid or irate mentally ill person can easily fully saturate the time of ten or more Wikipedia volunteer editors with a barrage of fake identities making su
Re: [tor-talk] Tor 0.2.4.12-alpha is out
On Thu, Apr 18, 2013 at 2:08 PM, Sebastian G. wrote: > 18.04.2013 14:05, Roger Dingledine: >> [...] >> >> o Major bugfixes (client-side privacy): >> - When we mark a circuit as unusable for new circuits, have it >> continue to be unusable for new circuits even if MaxCircuitDirtiness >> is increased too much at the wrong time, or the system clock jumps >> backwards. Fixes bug 6174; bugfix on 0.0.2pre26. > > Shouldn't this say "mark a circuit as unusable for new streams"? Indeed it should. With luck Roger will make the correction. >> [...] >> o Minor bugfixes (syscalls): >> - Always check the return values of functions fcntl() and >> setsockopt(). We don't believe these are ever actually failing in >> practice, but better safe than sorry. Also, checking these return >> values should please analysis tools like Coverity. Patch from >> 'flupzor'. Fixes bug 8206; bugfix on all versions of Tor. > > Sounds like a feature to me (since nothing was broken). Well I don't > want to put this anywhere else or start a discussion, just adding a > thought. (Since I'm writing anyway) Heh. I think my reasoning for calling it a bugfix was that even though _for all we know_, nothing was broken, that Tor's behavior here was incorrect. (And for all we know, there's some weird platform somewhere where one of our attempts to set CLOEXEC was failing for some odd reason.) > [many awesome changes fell victim to trimming] Thanks, Sebastian! peace, -- Nick ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Abusing resource:// uri in Firefox Browser
Hello Folks: Are you aware of this? http://marcorondini.eu/research/resource_uri/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
On Thu, Apr 18, 2013 at 2:51 PM, grarpamp wrote: > Though sure, I do suggest and accept that Tor may present a > different *class* of abuse than other categories of abusable > IP's. Tor exits were not banned prior to their use for abuse. At the point automated exitlist banning was performed a substantial portion were manually blocked. (Which had the three way bad effect of not completely blocking the trolls, while blocking most use by non-free users, while also blocking ex-exits and punishing people for even trying out being an exit). There is no particular blocking efficiency gain that comes from using exitlists relative to other kinds of abuse sources. The site can and does block /16's all by itself. ( http://en.wikipedia.org/wiki/Special:BlockList?wpTarget=&wpOptions[]=addressblocks&limit=5000 ) >> not have a high deployment or operating cost > I think cost is large what they think about. Just a... 'Really? You mean we > can turn a flag and whack 2^8 at zero cost, sweet, we just eliminated a > help desk drone's worth of salary from our costs'. That's pretty cold. Your approach is why the tor community will make absolutely no progress on this subject. Telling me that you don't think the problem is imaginary doesn't help when everything else you say shows that you believe it is. You might think you're being only slightly insensitive to other people's needs, but I am here to tell you that I am inside the both communities and you are coming off as a clueless jerk. This is actually hard and it involves real trade-offs. This attitude of "oh it's easy and you're just being a reactionary" is embarrassing to people who know better... and to people who care less about enabling access than I do it's so completely misguided that it will just get you ignored. > Nyms wouldn't be usable by legitimate anons unless they are > free from linkable properties. I suggest you familiarize yourself with the previously proposed solutions before responding. [snip] > On the other hand, a little development cost by a site can put up some > pretty big walls against abuse in the form of time delayed accounts, > captchas now and then, good filters on your i/o, etc. And often cost > less than whatever service you pay to keep you 'safe'. The purpose of any anti-baddness system must be to distinguish between good and bad users. Things like time delays actually select for _bad_ users: Good users are unlikely to tolerate the delay. Bad users can just pipeline to hide the latency. That things like this reduce badness is only an artifact of that fact that they reduce everything. > And honestly, if you're so fucking tight that you can't pony up for > a proper abuse desk, then both your business model and you > should expect failure. I'm not sure where to begin here. All I can say is that if the Tor community will allow people to approach this issue with this kind of response it "should expect failure". ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
Jacob Appelbaum: > adrelanos: >> Jacob Appelbaum: >>> adrelanos: > > We already fail this test, no? Not necessarily. This is a difficult question. >>> >>> Tor does not hide that you are using Tor >> >> Yes, but... While making this point up, I saw pluggable transports as a >> tool which can be thrown into the mix and make this a non-issue. > > I don't think so - I also this this is non-trivial. I know. It's absolutely non-trivial. From my distro packager perspective pluggable transports are just some magic boxes to throw into the mix, which get a job done. Great minds do all the thinking and coding. > Some pluggable > transports may seek to obfuscate traffic or to morph it. However, they > do not claim to hide that you are using Tor *in all cases* but rather in > very specific cases. An example threat model includes a DPI device with > limited time to make a classification choice - so the hiding is very > specific to functionality and generally does not take into account > endless data retention with retroactive policing. Ok. >> >> (In theory obfsproxy and alike tools can hide the fact that someone is >> using Tor, which will be required against trying-hard-censurers so or >> so. This assumes, that pluggable transports will win the arms race >> against censors.) > > Perhaps for a time but again - rarely is anyone thinking about say, the > one, five or ten year logging of full packets. Yes. >> >>> and using Tails or Whonix is an >>> example of a system only emitting Tor traffic. >> >> The plan is... >> >> Whonix: >> When using VMs (as most people do), there is still a host operating >> system people start first - so there is not only Tor traffic. Tor usage >> can be hidden by using pluggable transports. > > I would be very careful with that claim. It might be hidden and it might > just be that no one is looking. Yes, I wouldn't claim that in documentation, of course. When I said "Tor usage can be hidden by using pluggable transports." in this very context, I assume, that this magic box is working well. It's very clear to me, that this is a very strong assumption and that this involves a lot work done by other people creating that magic box. (If we wouldn't make that assumption, we probable wouldn't have to talk about fingerprinting issues.) It's all about censorship circumvention. I thought, when we assume that this magic box works reasonable well, it would be a pity if we now added something which could render the achievements by pluggable transports useless. >> >> Tails: >> When this becomes an issue, there are two workarounds: >> - running Tails in a VM (naturally requires starting a non-Tails os >> beforehand) using pluggable transports to hide Tor usage >> - booting a second computer with a non-Tails operating system behind the >> same router, wait a bit, run Tails using pluggable transports to hide >> Tor usage >> >> And one possible fix: boot the amnesic system, simulate "this is Debian" >> (or other mainstream distro) by running it untorified in chroot or in a >> VM; fire up Tor using pluggable transports to hide Tor usage. >> >> The point I wanted to make is, I can very well imagine, not to fail this >> test, i.e. pretending to be a mainstream distribution, having non-Tor >> traffic and obfuscating Tor traffic using pluggable transports. Perhaps >> it can be prevented, that tlsdate introduces new operating system >> fingerprinting possibilities for ISPs. >> > > That's my point - I don't believe that tlsdate introduces anything more > than what any OpenSSL TLS connection would introduce. The main > difference is the host and *that* is currently a set of *extremely* > popular hosts, way way more popular than Tor nodes or some random bridge > or something. Yes, we could use obfsproxy in the mix but that is punting > and a side step. Ok. >>> It depends on your threat >>> model but generally, we'd just making up "someone could" as a network >>> distinguisher. >> >> Yes. >> >>> I assert that someone could watch - see no traffic except >>> encrypted traffic, decide it is Tor and then decide you're running Tails >>> or Whonix. >> >> I tried to picture solutions to that above. >> > > That doesn't solve the fingerprinting issues - attackers can classify > the number of users with different machines behind a NAT and often do so. Well, I failed to describe what I meant with 100% accuracy due to my skills. I cut it here so you don't have to read so much. Just that: our opinions here don't differ at all and I got educated. You understand this topic better than me, the important point "it would be a pity if we now added something which could render the achievements by pluggable transports useless" has been considered, thank you for that. Best, adrelanos ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
> ban the IP then unban 7 days later. If the IP falls in a > pre-identified 'dirty' range, I never unban it. I don't mind this approach too much. At least it leaves some room for legitimate users to find exits. Restores the state to open after some time. And is a bit more mature tool in that, if you don't have accounts (which is better to block by if you do), it's the next best way to terminate a problem in realtime. Though I don't think I'd apply a permaban, because whatever IP is bothering you will eventually get pulled at the source before long. Unless their profits come from spam, bribing Russian officials with cracked CC's, etc. >> We haven't considered a particular feature to bloc TOR access, but I can >> pass on the feedback internally. > As you can see: Not only do they not specifically block TOR, they don't have > a feature that to facilitate users blocking TOR. Yet... > Coffee shops are a bit difficult to block specifically, but why do you think > people who block TOR don't block Romania? I suppose it's possible they do as well. Just that as with any userbase, knowing the effective range of their IP's may be hard. On the other hand, maybe they do block RO indiscriminately because they believe it to be a compellingly overwhelming source of trouble, or simply unfathomable, from their perspective, that a legitimate user would come from there. For example, a year or so ago I tested an English language based predominantly North American, slightly Euro, dating site against Tor. Though they had no stated policy to be sure of it, from my tests it appeared that from English speaking exit countries, Tor worked fine. If I let Tor float or come in via say Brazil, the account would be silently deleted. This lead to belief that they utilized the 'unfathomable' policy. Again, their actual policy is unknown, I could have just been using unlucky IP's. Either way, I'd very much hesitate to recommend them to Tor users who would fear for their legitimate account, and thus any developing relations, against that unknown. Further, people find dating hard enough without having their employer or landlord snooping on how many kids they want, and whoever else generally reading/storing/selling their personal bits. These sites need to respect that. Part of which is to fully and properly enable HTTPS on their servers and to permit their users to come from Tor. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
>> Protecting networks or hosts based on rumors and hearsay is a pretty >> poor way to protect anything. Empirical data should rule the decisions. > > Some people also make decisions based on perception of how likely traffic > is to "convert" into sales or signups. Which is also a very problematic > way to look at things. Let's take bitcoin for a sales example. There are lots of people who would like to find a site that would actually take the sale. Some of those people have needs to trade from work, or school, or to keep their ISP from giving away their profile... Tor does that. So these sites are LOSING business, lots of it, because they're being stupid about where someone *appears* to be coming from and/or whatever else they see from there. I don't know what business school they went to, but in my book you take the sale and stay out of the privates of your customer. And right now there is no law anywhere in the world that says you cannot do business with customer merely for being via Tor. And only a couple situations with banned countries and known agents lists. All of which are addressible by KYC, if you are so regulated, to again permit you to accept business from wherever. With bitcoin, or even any other type of business, actual regulation which you MUST follow by law often doesn't exist... only 'guidance' and broadly applied best practice. Within that realm of always being legal... there is thin and rich with happy customers, all the way to broad and poor with a reputation that minus1's you. I think Amazon takes the sale via Tor :) Hats off to Jeff. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
I use Cloudflare. When I experience hacking, spamming scraping or any other cpu sucking activity, I use Cloudflares API and ban the IP then unban 7 days later. If the IP falls in a pre-identified 'dirty' range, I never unban it. Based on my logs I had the distinct impression Cloudflare did not block TOR. So, I wrote Cloudflare. Their response was: Justin (CloudFlare Support) Apr 18 02:24 pm (PDT) Hi, and thanks for contacting us today. We don't have a particular position on TOR. All IPs are treated the same -- so if suspicious activity was seen from an IP that happens to be a TOR exit node then it'll be challenged by our system before it can access a CloudFlare page. This is no different than any other IP that might be doing something suspicious though. We haven't considered a particular feature to bloc TOR access, but I can pass on the feedback internally. As you can see: Not only do they not specifically block TOR, they don't have a feature that to facilitate users blocking TOR. > My main issue with sites that are Tor aware and then take action > against Tor nodes specifically, is that most seem to say > they get attacks, spam, illegal stuff from Tor. While true, that > is a drop in the pond when compared to from the internet at large. > Yet they don't block the internet, the coffee shops, the cable > ranges, Romania, etc. It's the being dumb about the net and the > kneejerk and the push to privacy destroying phone based auth. > > Hopefully with some group talks maybe some good will happen. Coffee shops are a bit difficult to block specifically, but why do you think people who block TOR don't block Romania? I'm a hobby blogger. I don't block all of RO, but I block rdsnet.ro, fiberlink.ro and a number of other Romanian ranges. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
Matthew Finkel: > On Thu, Apr 18, 2013 at 09:01:21AM +, Matt Pagan wrote: >>> They're based in San Francisco, along with Craigslist (which >>> is another misguided arbitrary blocker of Tor exits). >>> Any other SF based companies that could benefit from >>> a visit or hackerspace talk about why they should not >>> be blocking Tor? >> >> Yelp is based in San Francisco. So is Pinterest. Getting the Wikimedia >> Foundation (also based in San Francisco) to come over would be a huge >> victory, IMO. >> > > Wikimedia is actually willing to discuss an alternative setup if a > usable one is found. Their current implementation is not really > acceptable, but there also isn't really a working/implemented alternative > solution, at this point (and it's not exactly at the top of their list > to implement their own). I was involved in writing the DNSBulkExitList program specifically for Wikipedia at the request of Tim S. At the time, I believe that it was better than simply blocking every Tor node - it only blocks exit nodes that allow exiting to Wikipedia. It is possible to request a special flag on a Wikipedia account that is granted by way of some special handshake. It is possible to take an already created account and use it for edits as the flag overrides the Tor block. A workable solution would be to continue to use such a list to detect Tor usage and then to ensure that we now allow new accounts to be created over Tor. The MediaWiki should ensure that HSTS is sent to the user and that the user only ever uses HTTPS to connect to Wikipedia. I think we should ensure that Wikipedia understands that the account was created with Tor and that the user may be using this to circumvent censorship, to protect what they are reading or editing from their local network censors or surveillance regime as well as to protect IP address information that the US currently doesn't really protect (see USA vs. Appelbaum; re: my Twitter case). Since the US can see a lot of the traffic to Wikipedia, I'd guess that this is important worldwide. If the user is abusive and an IP block would normally apply, Wikipedia would not block by IP but would rather use the normal Wikipedia process to resolve disputes (in edits, discussions, etc) and if the account is just being used for automated jerk behavior, I think it would be reasonable to lock the account, perhaps even forcing the user to solve a captcha, or whatever other process is used when accounts are abused in an automated fashion. Most of that isn't technical - it is a matter of accepting that some of us are not free. Some of us who are not free require systems like Tor to participate in the Free Culture community curated by the Wikipedia community on Wikipedia. Some of us will then be free to be part of that community and perhaps, if we work smartly, other freedoms will follow from the knowledge of the community. All the best, Jacob ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
> It's the same old story: There are persistent highly annoying trouble > makers— not even many of them— who are effectively deterred by > blocking whatever proxies they use. Eventually they hit tor, and thus > tor must be blocked from editing. This abuse isn't imaginary. Of course it isn't imaginary. However this is where kneejerkers are just being dumb... 2^8 exits will *never* ever be anything in comparison to the 2^30 IP's reasonably estimated to be actually in use. Ten square kilo's of your favorite big city has more abusable open IP's than 2^8. Know how many big cities there are? Know how many laptops and wifi and open wallplates there are? Lots. Though sure, I do suggest and accept that Tor may present a different *class* of abuse than other categories of abusable IP's. > not have a high deployment or operating cost I think cost is large what they think about. Just a... 'Really? You mean we can turn a flag and whack 2^8 at zero cost, sweet, we just eliminated a help desk drone's worth of salary from our costs'. That's pretty cold. > The various magical nymtoken ideas would probably be acceptable— they > just need to make it so that an unbounded supply of identities is not > any cheaper than it already is Nyms wouldn't be usable by legitimate anons unless they are free from linkable properties. Whether it's usage and cookies across sites, or back to the anon themself. Even then you must trust the third party nym provider with the nym logs. History proves that trust is always misplaced and broken. On the other hand, a little development cost by a site can put up some pretty big walls against abuse in the form of time delayed accounts, captchas now and then, good filters on your i/o, etc. And often cost less than whatever service you pay to keep you 'safe'. And honestly, if you're so fucking tight that you can't pony up for a proper abuse desk, then both your business model and you should expect failure. The only thing that can truly and properly solve a human problem is humans, not robots. That is a lot of what Tor is all about, solving problems. Those who would blindly swat Tor down are part of the problem. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
Andrew Lewman wrote: > Protecting networks or hosts based on rumors and hearsay is a pretty > poor way to protect anything. Empirical data should rule the decisions. Some people also make decisions based on perception of how likely traffic is to "convert" into sales or signups. Which is also a very problematic way to look at things. ~Griffin -- Please note that I do not have PGP access at this time. OTR: sa...@jabber.ccc.de / fonta...@jabber.ccc.de ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
On Thu, Apr 18, 2013 at 1:01 PM, Matthew Finkel wrote: > Wikimedia is actually willing to discuss an alternative setup if a > usable one is found. Their current implementation is not really > acceptable, but there also isn't really a working/implemented alternative > solution, at this point (and it's not exactly at the top of their list > to implement their own). It's the same old story: There are persistent highly annoying trouble makers— not even many of them— who are effectively deterred by blocking whatever proxies they use. Eventually they hit tor, and thus tor must be blocked from editing. This abuse isn't imaginary. The various magical nymtoken ideas would probably be acceptable— they just need to make it so that an unbounded supply of identities is not any cheaper than it already is— but they need to be implemented and not have a high deployment or operating cost. There are some people who hold the position that instant doubling of identities (w/ and w/o tor) that attackers would get is not acceptable but with things like http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2013-04-08/News_and_notes and Tor's effectiveness at evading censorship I expect that most can be convinced that it's worth it. Harder would be the fact that English Wikipedia (and many other larger Wikipedias) blocks most data centers and VPS services with large rangeblocks as they get used as account multipliers by socks and an obvious nym implementation would partially defeat that. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
On Thu, 18 Apr 2013 15:34:21 -0400 grarpamp wrote: > My main issue with sites that are Tor aware and then take action > against Tor nodes specifically, is that most seem to say > they get attacks, spam, illegal stuff from Tor. While true, that > is a drop in the pond when compared to from the internet at large. > Yet they don't block the internet, the coffee shops, the cable > ranges, Romania, etc. It's the being dumb about the net and the > kneejerk and the push to privacy destroying phone based auth. Right. They only look for the attacks and not the 99% of traffic which is non-attack. If they looked at total traffic from Tor, they'd likely find the normal usage vastly overwhelms the attack traffic. Getting some real data here would be interesting. I'm constantly told by "network security" people with more letters after their names than years of experience that "everyone knows tor is bad traffic", but when you push them on it, they have no idea why or even where their traffic originates at all. And "everyone" turns out to be companies selling products or their certification instructor. Protecting networks or hosts based on rumors and hearsay is a pretty poor way to protect anything. Empirical data should rule the decisions. Cloudflare, google, akamai, and others would have a pretty good view of how much traffic from Tor exits can be classified as good or bad. If only they'd share the data or summarized results. I'm interested in the answer, no matter what it is. -- Andrew http://tpo.is/contact pgp 0x6B4D6475 ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
Maxim Kammerer: > On Thu, Apr 18, 2013 at 1:18 AM, Jacob Appelbaum wrote: >> Whenever a less friendly person gives me a hard time about the obvious >> futility of tlsdate, I think: >> >> "Let me know how your ntp replacement project goes and I'll gladly use >> it when my shitty one trick pony isn't beating the pants off of your arm >> chair hacking." >> >> I'd say I'm kidding but really, we need a secure network time client and >> we need one badly. If we don't have one, we can't hold certain >> assumptions to be correct and entire systems can be broken. There is >> also the attack surface and architecture of other ntp/ntp-like clients. > > There are now apparently enough openly accessible and stable > authenticated NTP servers around to rely on them in a distro. The > problem is that authenticated NTP protocol (more precisely, its > asymmetric crypto Autokey variant) does not support NAT traversal in > either the server *or* the client, since both IP addresses are signed. > I guess the reason is that NTP has no clear distinction between client > and server. > There are a lot of issues with ntp - my favorite is that a basic (eg: shipping with OS X) ntp client will hit the default Apple NTP servers. These servers may be queried by external third parties and the information returned is enough to attack any client who is using the server. The information returned includes the client ip, the udp source port, the udp destination and of course, the attacker knows the server ip. This means that an attacker may now send packets as the server - thus the attacker can even attack ntp clients behind a nat or a stateful firewall. UDP is part of the problem, the lack of the client/server authentication is another part of the problem, the fact that the ntp clients aren't written with security in mind is yet another problem. This says nothing of an attacker who controls the network path - such an attacker has an even larger number of attacks and ntp falls over for nearly all of them. The entire idea of a False Ticker relies on the notion that you have some path to some honest ntp server, so you can have some phase locked loops and determine which of the set is wrong or bad. Good luck without authentication, integrity, confidentiality in syncing that clock... So again, I understand you don't like my hack and I'd just like to be clear - we can't use the current ntp tools to safely, securely or anonymously set our clock in nearly any use case. I'm working on alternative ways to do it and I'm using IETF compliant protocols on the network to ensure that it is actually more than a silly hack that only works for a while. All the best, Jacob ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
adrelanos: > Jacob Appelbaum: >> adrelanos: We already fail this test, no? >>> >>> Not necessarily. This is a difficult question. >>> >> >> Tor does not hide that you are using Tor > > Yes, but... While making this point up, I saw pluggable transports as a > tool which can be thrown into the mix and make this a non-issue. I don't think so - I also this this is non-trivial. Some pluggable transports may seek to obfuscate traffic or to morph it. However, they do not claim to hide that you are using Tor *in all cases* but rather in very specific cases. An example threat model includes a DPI device with limited time to make a classification choice - so the hiding is very specific to functionality and generally does not take into account endless data retention with retroactive policing. > > (In theory obfsproxy and alike tools can hide the fact that someone is > using Tor, which will be required against trying-hard-censurers so or > so. This assumes, that pluggable transports will win the arms race > against censors.) Perhaps for a time but again - rarely is anyone thinking about say, the one, five or ten year logging of full packets. > >> and using Tails or Whonix is an >> example of a system only emitting Tor traffic. > > The plan is... > > Whonix: > When using VMs (as most people do), there is still a host operating > system people start first - so there is not only Tor traffic. Tor usage > can be hidden by using pluggable transports. I would be very careful with that claim. It might be hidden and it might just be that no one is looking. > > Tails: > When this becomes an issue, there are two workarounds: > - running Tails in a VM (naturally requires starting a non-Tails os > beforehand) using pluggable transports to hide Tor usage > - booting a second computer with a non-Tails operating system behind the > same router, wait a bit, run Tails using pluggable transports to hide > Tor usage > > And one possible fix: boot the amnesic system, simulate "this is Debian" > (or other mainstream distro) by running it untorified in chroot or in a > VM; fire up Tor using pluggable transports to hide Tor usage. > > The point I wanted to make is, I can very well imagine, not to fail this > test, i.e. pretending to be a mainstream distribution, having non-Tor > traffic and obfuscating Tor traffic using pluggable transports. Perhaps > it can be prevented, that tlsdate introduces new operating system > fingerprinting possibilities for ISPs. > That's my point - I don't believe that tlsdate introduces anything more than what any OpenSSL TLS connection would introduce. The main difference is the host and *that* is currently a set of *extremely* popular hosts, way way more popular than Tor nodes or some random bridge or something. Yes, we could use obfsproxy in the mix but that is punting and a side step. >> It depends on your threat >> model but generally, we'd just making up "someone could" as a network >> distinguisher. > > Yes. > >> I assert that someone could watch - see no traffic except >> encrypted traffic, decide it is Tor and then decide you're running Tails >> or Whonix. > > I tried to picture solutions to that above. > That doesn't solve the fingerprinting issues - attackers can classify the number of users with different machines behind a NAT and often do so. All the best, Jacob ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
On Thu, Apr 18, 2013 at 09:01:21AM +, Matt Pagan wrote: > > They're based in San Francisco, along with Craigslist (which > > is another misguided arbitrary blocker of Tor exits). > > Any other SF based companies that could benefit from > > a visit or hackerspace talk about why they should not > > be blocking Tor? > > Yelp is based in San Francisco. So is Pinterest. Getting the Wikimedia > Foundation (also based in San Francisco) to come over would be a huge > victory, IMO. > Wikimedia is actually willing to discuss an alternative setup if a usable one is found. Their current implementation is not really acceptable, but there also isn't really a working/implemented alternative solution, at this point (and it's not exactly at the top of their list to implement their own). - Matt ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
> Yelp is based in San Francisco. So is Pinterest. Getting the Wikimedia > Foundation (also based in San Francisco) to come over would be a huge > victory, IMO. I'd bet there is room for some one day presentations in the big corporate cities, sf, nyc, chi and so on. Find the businesses and invite them. >> Noticed a recent surge of sites using CloudFlare. > They don't > block Tor per se, they rate limit connections/request per IP address. I seem to be denied with them, but that could be the apparrent effect of a stern rate limit. So I need to do better and copy the message/screens to the list. I often give up though. > While I don't agree with this model, it seems consistent with how they > treat Tor. I can connect to cloudflare sites by forcing circuits to > exit through non-busy exit relays just fine. Tor is already slow. So though silly, a rate limit is probably better than a universal Tor block. My main issue with sites that are Tor aware and then take action against Tor nodes specifically, is that most seem to say they get attacks, spam, illegal stuff from Tor. While true, that is a drop in the pond when compared to from the internet at large. Yet they don't block the internet, the coffee shops, the cable ranges, Romania, etc. It's the being dumb about the net and the kneejerk and the push to privacy destroying phone based auth. Hopefully with some group talks maybe some good will happen. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cicpa
Thank you joe. On Thu, Apr 18, 2013 at 6:08 PM, Joseph Lorenzo Hall wrote: > Griffin is 100% correct about the leverage you can get from a phone > call rather than other forms of communication with Congrescritters. > > My organization (CDT) has been working heavily on CISPA, along with > our allies EFF, ACLU and others. The bill did just (within the past > hour) indeed pass our House. > > Before the bill moved to the House floor, our National > Security/Cybersecurity lead (one of my bosses, Greg Nojeim) wrote the > following critique of the bill: > > > https://www.cdt.org/blogs/greg-nojeim/1504cispa-moves-house-floor-still-deeply-flawed > > And this week the White House issued a veto threat saying if it comes > to the President's desk in its' current form, he will veto it. The > statement reads exactly like the arguments many of us advocacy > organizations have been making, which is a good sign: > > > http://www.whitehouse.gov/sites/default/files/omb/legislative/sap/113/saphr624r_20130416.pdf > > We doubt much movement will happen in our Senate soon and any bill > will look very different. > > best, Joe > > On Thu, Apr 18, 2013 at 12:17 PM, Griffin Boyce > wrote: > > Andrew F wrote: > > > >> thanks griffin. > >> ... liked... and shared. > >> Crap... I gotta get off facebook! > >> > > > > In situations like these, a phone call is worth five hundred online > > signatures. Congressional reps aren't *that* mean ;-) > > > > ~Griffin > > ___ > > tor-talk mailing list > > tor-talk@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > > > -- > https://josephhall.org/ > ___ > tor-talk mailing list > tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor project creating a replacement for TrueCrypt?
On Apr 18, 2013 2:01 PM, "Anthony Papillion" wrote: > > Hello Everyone, > > Someone I know said that he read that the project was creating a > replacement for TrueCrypt. Can anyone verify this as accurate or not? If > it is accurate, how far along is the work and where can I find more > information? This is the first I've heard about it. (So unless it's a random remark somebody made offhand about a project they'd like to do someday, I'd guess it probably isn't true.) -- Nick ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cicpa
Your INTERNET privacy just took another step toward disappearing, The house voted 288 to 127 Here are the congressman that voted to take away your rights. http://clerk.house.gov/evs/2013/roll117.xml Next is the senate vote. Please call your senators. Ps. ( I thought it had passed the house, already. ) On Thu, Apr 18, 2013 at 4:17 PM, Griffin Boyce wrote: > Andrew F wrote: > > > thanks griffin. > > ... liked... and shared. > > Crap... I gotta get off facebook! > > > > In situations like these, a phone call is worth five hundred online > signatures. Congressional reps aren't *that* mean ;-) > > ~Griffin > ___ > tor-talk mailing list > tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cicpa
Griffin is 100% correct about the leverage you can get from a phone call rather than other forms of communication with Congrescritters. My organization (CDT) has been working heavily on CISPA, along with our allies EFF, ACLU and others. The bill did just (within the past hour) indeed pass our House. Before the bill moved to the House floor, our National Security/Cybersecurity lead (one of my bosses, Greg Nojeim) wrote the following critique of the bill: https://www.cdt.org/blogs/greg-nojeim/1504cispa-moves-house-floor-still-deeply-flawed And this week the White House issued a veto threat saying if it comes to the President's desk in its' current form, he will veto it. The statement reads exactly like the arguments many of us advocacy organizations have been making, which is a good sign: http://www.whitehouse.gov/sites/default/files/omb/legislative/sap/113/saphr624r_20130416.pdf We doubt much movement will happen in our Senate soon and any bill will look very different. best, Joe On Thu, Apr 18, 2013 at 12:17 PM, Griffin Boyce wrote: > Andrew F wrote: > >> thanks griffin. >> ... liked... and shared. >> Crap... I gotta get off facebook! >> > > In situations like these, a phone call is worth five hundred online > signatures. Congressional reps aren't *that* mean ;-) > > ~Griffin > ___ > tor-talk mailing list > tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- https://josephhall.org/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor 0.2.4.12-alpha is out
18.04.2013 14:05, Roger Dingledine: > [...] > > o Major bugfixes (client-side privacy): > - When we mark a circuit as unusable for new circuits, have it > continue to be unusable for new circuits even if MaxCircuitDirtiness > is increased too much at the wrong time, or the system clock jumps > backwards. Fixes bug 6174; bugfix on 0.0.2pre26. Shouldn't this say "mark a circuit as unusable for new streams"? > [...] > o Minor bugfixes (syscalls): > - Always check the return values of functions fcntl() and > setsockopt(). We don't believe these are ever actually failing in > practice, but better safe than sorry. Also, checking these return > values should please analysis tools like Coverity. Patch from > 'flupzor'. Fixes bug 8206; bugfix on all versions of Tor. Sounds like a feature to me (since nothing was broken). Well I don't want to put this anywhere else or start a discussion, just adding a thought. (Since I'm writing anyway) [many awesome changes fell victim to trimming] Regards, Sebastian G. (bastik_tor) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor project creating a replacement for TrueCrypt?
Hello Everyone, Someone I know said that he read that the project was creating a replacement for TrueCrypt. Can anyone verify this as accurate or not? If it is accurate, how far along is the work and where can I find more information? Thanks! Anthony Papillion -- Anthony Papillion Advanced Data Concepts www.adcl.us ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
On Thu, Apr 18, 2013 at 1:18 AM, Jacob Appelbaum wrote: > Whenever a less friendly person gives me a hard time about the obvious > futility of tlsdate, I think: > > "Let me know how your ntp replacement project goes and I'll gladly use > it when my shitty one trick pony isn't beating the pants off of your arm > chair hacking." > > I'd say I'm kidding but really, we need a secure network time client and > we need one badly. If we don't have one, we can't hold certain > assumptions to be correct and entire systems can be broken. There is > also the attack surface and architecture of other ntp/ntp-like clients. There are now apparently enough openly accessible and stable authenticated NTP servers around to rely on them in a distro. The problem is that authenticated NTP protocol (more precisely, its asymmetric crypto Autokey variant) does not support NAT traversal in either the server *or* the client, since both IP addresses are signed. I guess the reason is that NTP has no clear distinction between client and server. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cicpa
Andrew F wrote: > thanks griffin. > ... liked... and shared. > Crap... I gotta get off facebook! > In situations like these, a phone call is worth five hundred online signatures. Congressional reps aren't *that* mean ;-) ~Griffin ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cicpa
thanks griffin. ... liked... and shared. Crap... I gotta get off facebook! On Thu, Apr 18, 2013 at 3:28 PM, Griffin Boyce wrote: > Even if you aren't in the US, you can raise awareness of the issues that > CISPA will cause. Writing op-eds is a good way to bring the issue to local > communities who might otherwise not know about the negative affects this > will have if passed. > > If you *are* in the US or a US citizen/resident living abroad, you should > give your congress critters a call: > https://action.eff.org/o/9042/p/dia/action/public/?action_KEY=9048 > > best, > Griffin Boyce > ___ > tor-talk mailing list > tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] CloudFlare
On Wed, 17 Apr 2013 23:59:45 -0400 grarpamp wrote: > Noticed a recent surge of sites using CloudFlare. Actually, I've talked to cloudflare in the recent past. They don't block Tor per se, they rate limit connections/request per IP address. While I don't agree with this model, it seems consistent with how they treat Tor. I can connect to cloudflare sites by forcing circuits to exit through non-busy exit relays just fine. -- Andrew http://tpo.is/contact pgp 0x6B4D6475 ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cicpa
Even if you aren't in the US, you can raise awareness of the issues that CISPA will cause. Writing op-eds is a good way to bring the issue to local communities who might otherwise not know about the negative affects this will have if passed. If you *are* in the US or a US citizen/resident living abroad, you should give your congress critters a call: https://action.eff.org/o/9042/p/dia/action/public/?action_KEY=9048 best, Griffin Boyce ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor 0.2.4.12-alpha is out
Tor 0.2.4.12-alpha moves Tor forward on several fronts: it starts the
process for lengthening the guard rotation period, makes directory
authority opinions in the consensus a bit less gameable, makes socks5
username/password circuit isolation actually work, and fixes a wide
variety of other issues.
https://www.torproject.org/dist/
Changes in version 0.2.4.12-alpha - 2013-04-18
o Major features:
- Raise the default time that a client keeps an entry guard from
"1-2 months" to "2-3 months", as suggested by Tariq Elahi's WPES
2012 paper. (We would make it even longer, but we need better client
load balancing first.) Also, make the guard lifetime controllable
via a new GuardLifetime torrc option and a GuardLifetime consensus
parameter. Start of a fix for bug 8240; bugfix on 0.1.1.11-alpha.
- Directory authorities now prefer using measured bandwidths to
advertised ones when computing flags and thresholds. Resolves
ticket 8273.
- Directory authorities that have more than a threshold number
of relays with measured bandwidths now treat relays with unmeasured
bandwidths as having bandwidth 0. Resolves ticket 8435.
o Major bugfixes (assert / resource use):
- Avoid a bug where our response to TLS renegotiation under certain
network conditions could lead to a busy-loop, with 100% CPU
consumption. Fixes bug 5650; bugfix on 0.2.0.16-alpha.
- Avoid an assertion when we discover that we'd like to write a cell
onto a closing connection: just discard the cell. Fixes another
case of bug 7350; bugfix on 0.2.4.4-alpha.
o Major bugfixes (client-side privacy):
- When we mark a circuit as unusable for new circuits, have it
continue to be unusable for new circuits even if MaxCircuitDirtiness
is increased too much at the wrong time, or the system clock jumps
backwards. Fixes bug 6174; bugfix on 0.0.2pre26.
- If ClientDNSRejectInternalAddresses ("do not believe DNS queries
which have resolved to internal addresses") is set, apply that
rule to IPv6 as well. Fixes bug 8475; bugfix on 0.2.0.7-alpha.
- When an exit relay rejects a stream with reason "exit policy", but
we only know an exit policy summary (e.g. from the microdesc
consensus) for it, do not mark the relay as useless for all exiting.
Instead, mark just the circuit as unsuitable for that particular
address. Fixes part of bug 7582; bugfix on 0.2.3.2-alpha.
- Allow applications to get proper stream isolation with
IsolateSOCKSAuth. Many SOCKS5 clients that want to offer
username/password authentication also offer "no authentication". Tor
had previously preferred "no authentication", so the applications
never actually sent Tor their auth details. Now Tor selects
username/password authentication if it's offered. You can disable
this behavior on a per-SOCKSPort basis via PreferSOCKSNoAuth. Fixes
bug 8117; bugfix on 0.2.3.3-alpha.
o Major bugfixes (other):
- When unable to find any working directory nodes to use as a
directory guard, give up rather than adding the same non-working
nodes to the directory guard list over and over. Fixes bug 8231;
bugfix on 0.2.4.8-alpha.
o Minor features:
- Reject as invalid most directory objects containing a NUL.
Belt-and-suspender fix for bug 8037.
- In our testsuite, create temporary directories with a bit more
entropy in their name to make name collisions less likely. Fixes
bug 8638.
- Add CACHED keyword to ADDRMAP events in the control protocol
to indicate whether a DNS result will be cached or not. Resolves
ticket 8596.
- Update to the April 3 2013 Maxmind GeoLite Country database.
o Minor features (build):
- Detect and reject attempts to build Tor with threading support
when OpenSSL has been compiled without threading support.
Fixes bug 6673.
- Clarify that when autoconf is checking for nacl, it is checking
specifically for nacl with a fast curve25519 implementation.
Fixes bug 8014.
- Warn if building on a platform with an unsigned time_t: there
are too many places where Tor currently assumes that time_t can
hold negative values. We'd like to fix them all, but probably
some will remain.
o Minor bugfixes (build):
- Fix some bugs in tor-fw-helper-natpmp when trying to build and
run it on Windows. More bugs likely remain. Patch from Gisle Vanem.
Fixes bug 7280; bugfix on 0.2.3.1-alpha.
- Add the old src/or/micro-revision.i filename to CLEANFILES.
On the off chance that somebody has one, it will go away as soon
as they run "make clean". Fix for bug 7143; bugfix on 0.2.4.1-alpha.
- Build Tor correctly on 32-bit platforms where the compiler can build
but not run code using the "uint128_t" construction. Fixes bug 8587;
bugfix on 0.2.4.8-alpha.
- Fix com
Re: [tor-talk] CloudFlare
> They're based in San Francisco, along with Craigslist (which > is another misguided arbitrary blocker of Tor exits). > Any other SF based companies that could benefit from > a visit or hackerspace talk about why they should not > be blocking Tor? Yelp is based in San Francisco. So is Pinterest. Getting the Wikimedia Foundation (also based in San Francisco) to come over would be a huge victory, IMO. -- Matt Pagan matthew.a.pa...@gmail.com PGP key ID: 0xA521D36F ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Is need to install Tor Browser bundle exe on top of obfsproxy exe
Hi, I installed obfs proxy [tor-pluggable-transports-browser- 2.4.11-alpha-2_en-US.exe] from https://www.torproject.org/projects/obfsproxy. While launching this Tor obfs proxy browser, I am getting high light to upgrade this browser with latest Tor browser bundle *2.3.25-6. * Is it necessary to upgrade the latest Tor browser bundle on top of Obfsproxy exe? If so again the traffic from upgraded browswer will get detect by DPI censorship? Regards, Chandramohan On Tue, Apr 16, 2013 at 4:54 PM, Roger Dingledine wrote: > On Tue, Apr 16, 2013 at 03:23:11PM +0530, chandra mohan wrote: > > After Installation of tor-pluggable-transports-browser- > > 2.4.11-alpha-2_en-US.exe from > https://www.torproject.org/projects/obfsproxy, > > I could > > broswer Internet traffic from this browser. > > Am I need to configure obfsproxy client and obfsproxy server > > explicitly? Kindly clarify. > > If it works for you, there's no need to configure anything. This bundle > comes pre-configured to use several obfsproxy servers run by various > volunteers. > > The bundle also comes pre-configured with Flash Proxy, a second pluggable > transport design. So if the Obfsproxy part stops working for some reason, > you might try the Flash Proxy part. To use it, you'll need to enable > port-forwarding (on port 9000 by default) so your system is reachable > from the outside world: > https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto > This step is easy for some people and hard for others (it depends how > much control you have over your Internet connection). That's why the > pluggable transport bundle comes with several options. > > --Roger > > ___ > tor-talk mailing list > tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
