Re: Is "gatereloaded" a Bad Exit?
> I never made the claim this was safer.
Of course, not quoted as such. Plaintext anywhere is risky. Yet
this entire thread is about sniffing. How plaintext-only exits
somehow equate to sniffing. And how badexiting plaintext-only exits
somehow equates to reducing that risk. Both are weak premises. And
said exits were loosely defined as wolves whose only purpose was
to log traffic.
> I cited several engineering reasosn why this type of exit policy
> is a pain for us.
Perhaps after the nodes were waxed on the premise of sniffing and
the thread exploded. (Dethreading might show otherwise so no picking
is intended at all.) It shouldn't matter though as certainly folks
would better support decisions to solve anonymity engineering and/or
performance problems that are causing a non-trivial impact or holdup.
Is Tor really at the point where reducing the exit matrix provides
significant or greater win as opposed to updates in other areas?
Does (or will) Tor bundle 80+443 to the same destination via the
same exit? What about http[s], smtp[s], imap[s], pop[s], submission
grouping? If the user is using different functions or accounts with
different protocols, he likely doesn't want this. Better let him
do his own bundling with MAPADDRESS or some toggles or something
and enhance those tools instead.
> I've also made the claim that there is no rational reason to
> operate an exit in this fashion
People are encouraged to help out however they can. Therefore,
operator fiat and whim is, by definition, sufficient reason. If Joe
operator thinks 6667, 31337, 21, 23, 25, 80, 6969, 12345, 7, 53,
79, 2401, 19, 70, 110, 123 and so on are pretty uber cool, daresay
even silly motivation, and wants to support them, that's his right.
Just as he can disallow www.{un.int,aclu.org}:80. He doesn't have
to announce it with some 'no sniffing, pro rights' policy statement
to those that might believe the paper it's printed on, validate his
social ties, be contacted, or otherwise vetted.
If another example is needed, not that one is; Corporate, edu and
other LAN's sometimes think they can block 'ooo, encryption bad'
ports so they can watch their user's plaintext URL's with their
substandard vendor nanny watch tool of the day. All the while their
staff laughs at them as they happily tunnel whatever they want over
that (perhaps even the client or exit parts of Tor). Yes, this kind
of joke exists :)
And another; In some equally crazy backwards braindead jurisdiction,
being able to say 'hey, we're not hiding our traffic in crypto, we
forbid it, so look mr. authorized gov agent, you can sniff all that
traffic you're getting reports about, and we're not in it, therefore
we're off the hook'. Perhaps even in France, etc, with their strange
crypto laws.
There was also mention of exits to RFC1918 space. No ISP with brains
routes this, especially not for customer facing interfaces. Yet
they could simply be exits so that the operator and others can
access the 1918 space said operator has deployed internally. They
might not care to use a (hidden service OnionCat VPN) for this. Be
it due to config, speed, anonymity or otherwise. Nor might they
wish to overload routable address space as an exit to their local
designs. It's just as crazy. But they're all rational in someone's
mind.
[I haven't actually tried to map 1918 _in_ to Tor yet, just figured
what can be configured not to go out must be capable of going in.]
What about the users that want to reach their peer, via that only
exit in Siberia whose IP isn't blocked before their peer, that only
happens to only be offering port 80, to which their peer can listen.
It's not a question of whether *we* would do such things or see
them as rational. This is network space, any to any, hack to hack.
One man's widget is another man's stinky wicket. It's the tools
that matter. Tor is a network tool, with a nifty anonymity layer.
>> We also detect throttling by virtue of our bw authorities measuring
>> using 443.
> The same goes for exits that we detect ... throttling 443
Thanks, I yield this hack to be mooted by the project, cool.
> 443 is the second-most trafficed port by byte on the Tor network,
> occupying only ~1% of the traffic.
Sniffing was needed to determine this :) And, assuming 80 was found
to be the first-most (which sounds right); then in the 80+443(+rest)
case, a sniffer's cost is only raised, say, sub 10%, not double.
So dropping said nodes truly does nothing useful costwise either.
(A days worth of netflow on a faster open exit would show the port
distribution breakdown, if anyone wants to.)
Node testing methodologies are cool. And what can't be proven
beyond that belongs to userland. Engineering is also cool (and
there are some potentially good reasons to normalize exits there,
beyond the crypto/non-crypto port groups to be sure). And all the
various use cases, examples and whims are cool. So why not start
a new thread exploring the engineering and, if valid and overriding
of same,
Mailing list transition [archives]
Can someone make sure all the new lists get submitted/added to markmail? As official archives in Maildir or Mbox are not yet provided (under the curious guise of spam prevention), some alternative indexes to the ones provided by the list engine would be valuable to the community. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Feedback and Suspicions about Tor...
> You may like: As I look through them, I think I've found at least one answer with these so far. Thanks. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Feedback and Suspicions about Tor...
Simply because every good thing needs checks, balances and feedback. > Thus spoke Msr. Bennett: > The tor project until very lately has always promoted end user > understanding and responsibility. Now the project *appears* to > be undergoing a major philosophical change toward nannying the > tor user community, a direction I find very unappealing, to say > the least. Horrifying might be a more appropriate word. Anonymity systems are potentially disruptive, facilitative of change, etc. People should not be surprised if *any* such system exhibits *any* such odd behaviors or deviations from norms. It would of course be nice if they were spoken. Tor seems to be doing a good job indicating the usefulness and application of anonymity to a wide variety of potential users. Moreso than before. But it does hesitate from suggesting that it can be used as a check and balance within the user's own particular state. Which is certainly an equally valid and worthy use case. Why does Tor not use a fully distributed model? Seems it's allowing itself to be shutdown by shutting down the Directory Authorities. And allowing censorship of any given .onion through the cooperation or coercion of same. Perhaps these are not true, or have been addressed technically elsewhere, for which a link would be welcome. Then again, if they're valid weaknesses, and only a technical change, why not put it on roadmap and do it? Perhaps others have other concerns or thoughts to voice. Nothing untowards, nor trolling, is meant by this thread. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is "gatereloaded" a Bad Exit?
Been a fencesitter on this since posting the note about recording traffic that helped send this thread over the top. For once, I'm in agreement with Scott :) (and others) Badexiting based on exit policy seems rather silly as it will prevent nothing. And because of that, doing so is security theatre. Which sends both the project into questionable practice and the user into misplaced trust. If anything, the user should be educated instead. Nothing keeps an operator from dropping a gig split between 80 and 443. And if you defend against their rate limiting of 443 down to a meg, at best you've doubled their cost per eligible volume. No big deal. And due to typical protocol distribution on the open internet, if you force all operators to a fixed selection of 'ideal' policies, the cost per volume doesn't really change beyond that. It also seems the distribution of traffic around the nodes, operators, and globe won't change either... a broadbase level up is more likely, so there's no win there. Further, take the top fifth of exits by bandwidth, even take them all. No one can provably say whether or not any of them are recording traffic. And only a fool would trust an operator's (or shill's) statements to the contrary. The only way one can be sure is to stand watch over the node itself, in person. And lastly, some hat (or entity) packet groping their exit, or handfull of same, is the least of your worries. They're just a nuisance. It's the PA's and GPA's that one should be worried about. Seems everyone forgot that. They will always follow bandwidth, oppurtunity, interesting things and anomalies. Per the distribution notes above, and the architecture of Tor, exit policy doesn't seem likely to be interesting to a GPA. Badexit should be reserved only for those exits that are physically broken... modification of expected cleartext, corrupted ciphertext, certificate games, packet mischief, dns issues, upstream path issues, etc. The right thing to do with unprovable consipiracy theories such as exit sniffing, is to push it out to userland and provide tools for the user to manage it as desired. Some have suggested various node ranking metrics... Country, 'suspicious' strings in the nickname, 'suspicious' CIDR blocks, PTR's, ISP's etc, the preselected metrics and exit set of the 'badtornodes' guy, Scott and others, node keysigning parties, importable wiki [.onion] node config lists, and so on. 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. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is "gatereloaded" a Bad Exit?
> I dont see how to recognize if the traffic is recorded? I know people who record exit traffic, lots of it. And they do all sorts of things with it too. Does that news trouble you? If so, you need to readjust your thinking. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Fwd: Tor exits in .edu space
Paul is not on the list. Forwarding his reply at his request. Archives: http://archives.seul.org/or/talk/ Thanks Paul! Also, other than picking fqdn's off torstatus, I thought to check the contact fields for edu addresses and/or check ip space. Some might see that as spammy. Perhaps not given the useful and informative responses so far. It would be worthwhile if more insight is desired sometime. -- Forwarded message -- From: Paul Stauffer Date: Thu, 27 Jan 2011 13:32:51 -0500 Subject: Re: Tor exits in .edu space To: grarpamp Cc: or-talk@freehaven.net, timothy.e.ha...@gmail.com, t...@cs.bu.edu On Thu, Jan 27, 2011 at 01:23:02AM -0500, grarpamp wrote: > Just noticed a couple Tor exits in American .edu space. > Wanted to see how that is working for you? > Any issues you have running it? > How do you handle 'abuse' issues? > What your justifications and approaches were to start > and ongoing? On the whole it's been working fairly well for us. We've been running a Tor exit node for about 5 years now. Officially it is a project sponsored by one of the faculty in our department who does research on anonymity, privacy, cryptography, etc, so that has allowed us a bit of leeway with the university administration in the name of academic freedom, which we wouldn't have if this was just someone's personal toy. We did not seek official approval before setting it up, but we did inform the central IT Incident Response Team team of what we were doing, since we realized they'd probably be receiving abuse complaints related to the machine. On a technical level, we're running on old spare hardware; a dedicated machine, but nothing fancy. It's completely stand-alone, and doesn't have any dependency or relationship to any other system of ours; this was originally done out of paranoia, in case someone showed up at the door with a warrant to sieze the machine. It also logs *nothing*, which turned out to be a lot more complicated than simply disabling syslog. :) The system has a full gigabit speed connection to the Internet and Internet2, but our Tor traffic seems to stay pretty steady right around 30Mbps 24x7. I've been told by the networking people that this machine is the single largest bandwidth user at BU, which again might be a problem if we didn't have official faculty support. Originally the machine was located on one of our normal internal subnets, but at some point we were given a private subnet that is located external to the campus firewall, so as far as the university is concerned, our Tor server is treated as being outside the campus network. In addition to the normal default exit policy, we have always blocked any exit traffic destined for BU's own IP space; this was done primarily for legal compliance reasons, since there are a number of licensed services available to anyone with a BU IP address that we are contractually obligated to not make available to outside users. Initially the IRT simply forwarded all complaints to us, and we sent back an appropriate form letter explaining what Tor was, etc. Probably at least 95% of the complaints were DMCA takedown requests for P2P traffic. At the peak we were getting at least one a day. After about two years IRT decided that they would no longer bother to forward these requests to us, and I believe now they don't even bother responding to DMCA notices for the Tor server. We have periodically had inquiries from law enforcement, at the state and federal level, US military, other "interesting" govt agencies, and the occasional foreign law enforcement organization. These inquiries have generally been handled in conjunction with BU's General Counsel office, which required some initial education, but they have been quite helpful and supportive in all our interactions. In most cases, these inquiries went something like this: "It's a Tor node. Here's what that means..." "Oh ok, thanks for the explanation, sorry to bother you." We've had a few inquiries that required more effort to make them go away, and we're currently dealing with a more persistent person in the Mass Attorney General's office, but so far nothing has ever escalated further than that. > Anything we can do to support more nodes in other edu space? Based on our experience, the main two bits of advice I would give other .edu sites are: - Find an appropriate faculty sponsor for the project. If you can come up some some sort of interesting Tor-related research ideas, all the better. Leverage that academic freedom! - Inform the IT people and the General Counsel of what you're doing before they start to get complaints. Some education may be required. Offer to sit down with them and explain in whatever detail they'd like what Tor is and how it works, and answer any questions they might have. If they
Re: [OT] Republicons resume attacks on privacy
> The Republicants are back to pushing data retention legislation. :-( > http://news.cnet.com/8301-31921_3-20029393-281.html http://www.computerworld.com/s/article/9206379/DOJ_seeks_mandatory_data_retention_requirement_for_ISPs http://yro.slashdot.org/story/11/01/26/0418200/DOJ-Seeks-Mandatory-Data-Retention-For-ISPs http://yro.slashdot.org/story/11/01/27/0320209/Swedish-ISPs-To-Thwart-EU-Data-Retention-Law Yeah. And two years is ridiculous. Back in the days of source spoofing, internet miscreants were tracked for fun through multiple providers and countries, it took just a few hours if the right people were awake. Everyone had some form of authentication or location data. And pretty much everyone kept it for about a month. The data and subpoenas are there for any real 'exigent' purpose, primarily because providers need it for their own internal business purposes. LEO's just need to get off their duff, and if it's such small potatoes that they don't, well then, by definition, who cares. > I'd rather twist this into free promotion for TOR instead of hoping that > some random goverment will /not/ do something like this. I'd rather people keep writing congresscritters to keep it from happening, for all the good reasons discussed elsewhere on the net. Passage of such a law will promote anonymity networks in its own right. While you're giving in, might as write the draft for them that bans anonymity networks, because that will be next. Torproject did a nice job with their new look and the tor users page. And I know it's politically incorrect for them and hazardous to the project, but in addition to mentioning China all over the site as if it's the only twisted place in the world, the US, EU, etc should get some lip service too by adding another section for normal people that says 'irresponsible governments'... "They protect their communications from irresponsible corporations." *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Tor exits in .edu space
Just noticed a couple Tor exits in American .edu space. Wanted to see how that is working for you? Any issues you have running it? How do you handle 'abuse' issues? What your justifications and approaches were to start and ongoing? Anything we can do to support more nodes in other edu space? Etcetera. Nodes at large corporations would be similar, for another thread some other day. Nice having you guys around as nodes, thanks. d67b28212377617448a2ac192e11372ad951fd13 rut 9d4d995aa745a3caa6276afad505d3e4097aa075 bu *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: understanding problem, hidden services
Ok, I think it could be written as: Each endpoint must always be in control three nodes, with whoever chose the meetme using that as their third. Assuming meetme's don't apply in other areas of Tor, I suppose it could be further clarified as: Each endpoint must always be in control of three nodes. The Server uses the IP as its third. The Client uses the RP as its third. So for each step in the process it seems like this: # S inits 3 IP's S -> SR1 -> SR2 -> IP # S publishes descriptor S -> SR1 -> SR2 -> SR3 -> DB # C requests descriptor C -> CR1 -> CR2 -> CR3 -> DB # C inits RP C -> CR1 -> CR2 -> RP # C informs S of RP C -> CR1 -> CR2 -> CR3 -> :IP <- SR2 <- SR1 <- S # S uses RP S -> SR1 -> SR2 -> SR3 -> RP # full path established = 6 relays, 7 hops C -> CR1 -> CR2 -> RP: <- SR3 <- SR2 <- SR1 <- S The colon delimits the end of each sides control in the full path. The arrows are build extensions, not traffic. For the full Client-Server paths, I did not name the relays uniquely as 'OR1, OR2, OR3, ORa, ORb' as you guys have done, because there's no guarantee that they are used only once in such a path. AFAIK, it's possible to have: C -> R1 -> R2 -> RP: <- R1 <- R3 <- R2 <- S Note the reuse of relays R1 and R2 in arbitrary positions. The only constraint that holds is that the Client and Server each choose their own unique relays independantly. I've corrected that above by calling out who chose them and their uniqueness within that. I'd definitely do that too in the new spec/page clarification. Does the code check that since S could be thought to consider RP as just a destination beyond its "controlled exit" of SR3, and RP is also just another relay from which S can build circuits, that RP is in fact excluded from being any of its three relays? In other words, this might be bad: S -> SR1 -> SR2(really RP) -> SR3 -> :RP ... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: understanding problem, hidden services
https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/rend-spec.txt https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/path-spec.txt http://www.torproject.org/docs/hidden-services.html.en As you've read and itemized the spec, which I'm off to read, here's my itemized take on the web page... A Tor circuit means three hops and out to the destination, at least in the exit case. So applying that three hop definition of a circuit to HS's would lead to the following summary of that web page: # init IP's S <-> SRx <-> SRx <-> SRx <-> IP # qty: 'some' or 3 # publish desc S <-> SRx <-> SRx <-> SRx <-> DB # aka: 1 DA, maybe more # request desc C <-> CRx <-> CRx <-> CRx <-> DB # aka: 1 DA, maybe more till found # C init RP C <-> CRx <-> CRx <-> CRx <-> RP1 # inform S of RP C <-> CRx <-> CRx <-> CRx <-> IP # qty: 1, of 'some' or 3 # S init RP S <-> SRx <-> SRx <-> SRx <-> RP1 # full path C <-> CRx <-> CRx <-> CRx <-> RP1 <-> SRx <-> SRx <-> SRx <-> S Which is seven hops. Everything is consistent on the page with 7. Up until this 6 bomb summary is dropped at the end, which is probably where many people, including me, get the 6 from... "In general, the complete connection between client and hidden service consists of 6 relays: 3 of them were picked by the client with the third being the rendezvous point and the other 3 were picked by the hidden service." If so, the definition of circuit needs to be clearly redefined in this case. Also... this one needs work too. What is meant by identity? Its inet address is always protected from everyone 'learning' about it because it creates its own circuit. Who cares about the HS descriptor (with public key), anyone can get that. What other reasons, why use RP's? The HS put up a list of random IP's, not single ones, why not use one. The client did pick a single responsible relay, the RP. Or in the IP only case, the IP to use. I think the full path is joined out of band to prevent the DA's from knowing the possible meetme point(s). "One of the reasons for not using the introduction circuit for actual communication is that no single relay should appear to be responsible for a given hidden service. This is why the rendezvous point never learns about the hidden service's identity." So I'm just agreeing that the web page and even the spec could really benefit from some clarification on hops and phrasing. I would also put the images above the text descriptions, seems kindof like top posting as it is now. And BOLD the step: labels. Also dug up from that web page... "Step two: the hidden service assembles a hidden service descriptor, ... It uploads that descriptor to a distributed hash table." What I've read so far doesn't seem to indicate there is any such 'DHT' in use. It's more like the HS descriptors are simply uploaded to one or more, maybe all, of the 7 or so fixed public directory authorities chosen at random... not into a bulletproof DHT. And are then downloaded by querying the DA's until one is found that has the desired HSD. At least that's my take on it. By way of example, the Phantom project uses a real DHT for this purpose. This makes it pretty much immune to censoring the HS's, as well as overall takedown. And is stronger regarding being able to explicitly know all the descriptors that exist by coercing the DA's to log them (even though it should really be up to the HS admin to control access anyways, ie: scanning for or leaked services in the real world). Phantom expects to have a code release any day now. And last... "it is of special importance ... HS sticks to ... guards" I'd change that to "critical importance" or just "required" :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [Polipo-users] Polipo moved back to PPS
> git clone git://git.wifi.pps.jussieu.fr/polipo Do you have a gitweb? That would be nice. > Chris's old branch is called polipo-chrisd Oh, meaning 'chrisd/polipo' @ 20100113 193d95e3906967433081e0b10626a67c075ac131 > and his last tree is tagged ``polipo-chrisd-20100330''. Oh, meaning 'polipo' @ 20100330 b92db574c11961f681fa258314bd7470e4449cc0 This latter tree seeming to be seeded from the former when development there stopped. This commit compiles and runs fine on FreeBSD 8.1 i386 :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
SSL: Secure Connection Failed
Here's FF's message and the SHA-1 at the message screen time. Haven't examined the cert or the exit. HTTPS. 68:AC...6D:9B Secure Connection Failed An error occurred during a connection to mail.google.com. Peer reports incompatible or unsupported protocol version. (Error code: ssl_error_protocol_version_alert) * The page you are trying to view can not be shown because the authenticity of the received data could not be verified. * Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Now having trouble getting gmail
> I previously generated a fully anonymous gmail account early last year. > Created it via the tor network without using any personally identifiable > information, emails, or phone numbers. This is in the past, well over a month old and thus irrelevant in internet time. The recent threads about Gmail are interested in the today, not the past. Please quit mentioning the past :) > While I am not required to provide an email This 'secondary email' is optional and located on this first signup page: https://mail.google.com/mail/signup > phone number, when I complete the form (entering name and > desired login, password, etc, and click "submit" The SMS verification stage (phone number requirement[1]) location occurs only after you hit submit above. > I get a google page with "The page you requested is invalid" and > cannot complete the creation of the account. Yes, I have seen this three times. Each time I just cleared state, MAPADDRESS'd another exit, randomized info and tried again. Only to receive account creation failure of course. I've also been seeing a lot of SSL failures with sites recently. Sorry, since it's SSL, I've just been hitting retry instead of tracking it down. That's my bad for you all. > tor button Can't say that I use it. Very unlikely. > I'd hate to have to create a new account by going to some public > wifi location and doing this without tor first. That degrades my > anonymity for the email. I'd go that route. I don't see any conflict between the two, when done properly. [1] According to this months urban legend, two people have found this to not be a requirement. However, for all practical purposes, percent sucess wise, it probably should be considered to be one. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Index of hidden services?
The second some kind of automation starts kicking in, scanning for hidden services, I think this is a Bad Idea. > scanning 36^16 possible hidden services is out of discussion... It's actually 32^16. Considering 10k nodes processing 1 per second would only take 3.9 trillion years to search port 80... > The second some kind of automation starts kicking > in, scanning for hidden services, I think this is a Bad Idea. ... I still would love it if the authorities receiving the hidden service descriptors would just dump them out in OnionLand for all to see. I'd consider it a bona fide and very welcome service to the community. HINT ;-) At least until Tor went full DHT. HINT ;-) For which the nodes would just dump their own views of same. It's up to the onion operators to permit or allow onion access. Nothing different than on the regular internet. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Proposal: NEWNYM buckets
I've commonly seen exits (or paths) reused within a certain period of time after issuing a NEWNYM. For the users that have such a need, it would be nice if Tor could optionally keep a historical bucket of configurable entry length (whether based upon time and/or number of prior nodes/paths used). Such that any such nodes or paths would not be reused so long as they remained in the bucket according to its expiry rules. And as an aside, to the extent it is not already done, different ports on the same host should not necessarily be aggregated over the same circuits. I'd wager that they should not, so as to appear separate to the observer. Mostly for efficiency. Think of checking/writing multiple email accounts on the same provider... via IMAP/POP/HTTP/SMTP... without exposing too much relatedness due to using the same exit for all at once. Thanks for any consideration of this where merited. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor & Email?
Wish mail could multiply thread replies. Here are combined thoughts on the related 'Tor & Email?' and 'Tor and google groups' threads... >> Maybe you should start up a gmail activation service! Or at least for >> us here in the group! How many accounts will gmail and the other online entities allow under one number? Do they crosscheck country/region to number and are you willing to risk loss of every underlying account if so or for other 'related link' reasons. Given that, how many of you would be willing to drop cash in the mail to provide anon support for the fractional cost of the phone/SIM? The only real issue is the cost, oversubscription rate and account linking. Not the anonymity of the physical mobile SIM holder. >> able to enter the account and ... Amongst anons there would surely be some honor in this. >> Though I could open an account at gmail (with SMS) >> Belarus and an Azeri exit node and SMS verification was required >> tried to creat gmail-accounts with Netherlands and German exits In general, when you all are testing whatever service it might be, and especially since you are already picking the node, please be sure to state the node fingerprint so others can confirm. Particularly upon success. Andrew, I recall you said you were recently (the only one of two of us) able to create a Gmail account via Tor but did not know your exit. Do you remember whether or not you supplied a 'secondary' email address to them? And what domain/service it was? People should mention the fingerprint and use of any such mail domain/service when testing. As in my tests of 2010/12/29. As well as whether they used the 'broken' .exit notation or MAPADDRESS, what was MAPADDRESS'ed, etc. > I then tried again with a German exit, and had no problems. Jon, really? Do you recall the fingerprint and any recovery domain? And no captcha seems very strange. And Germany would give you @googlemail, not @gmail right? >> I am using Privoxy Privoxy alters a whole bunch more stuff than polipo. I can see where it would cause undue problems. I do ad blocking with MAPADDRESS so polipo is fine. >> As explained to me in Belgium, the law says they have to see an ID Many laws and policies say only to check, not record or some other such scheme. Many folks feel the need to go above and beyond what is written even though it serves them no particular benefit and adds to their cost, and in fact risk, of doing business. Bad will be bad, good will be good. That's why many have no problem with anonymity, because it doesn't affect that regard. Anti-anons seem to be really about profiling for profiling's sake, or slowing the normal course of historical change so that they may continue to reap the current state before naturally dying of old age. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor & Email?
Within last two hour, I tested these four exits, all failed to create new accounts. FF 3.6.1x, proxy set, dead common agent string. All form fields randomly generated for each exit. No recovery address supplied. 2bce68f1f3a84fb5986a09e6c2645f66ceb072d8 0ee6c3888c40a82a5bdc47d6e4d12edc41f4247f c1b7f0a32da660cba64ffc7c7ed71ed970aecb0e 498e83876367a3d833385562796ee8c7312f921f I'd be curious if anyone has success with these. You'll need to map these at minimum for the US. Sorry, Tor does not yet offer wildcard domain or CIDR block mapping, so you have to enter them all manually and maybe miss some that I didn't list: google.com mail.google.com clients1.google.com encrypted.google.com www.google.com > As in around 08:45 AM EST. I didn't look to see which exit, it > just worked, just a captcha required. Ok, cool. For me, there has never been a time in past few years I recall without the CAPTCHA on the signup form page. I want to see if I can instrument Tor's mapping function to emit host/IP to exit pairs as each is used or changes to syslog so they are not missed during testing various sites. > Gmail used to have the ability to stop bots from creating accounts > en masse. gmail doesn't have this ability any more. Oh, I thought that was called CAPTCHA :) Yes, I still see inbound spam from randomized accounts. Don't know if they're new. > When did you do it? I have some accounts created through such > method about 3 - 4 years ago, not later. And one of them they > required activate though sms after about 2 years of using!!! I have had ones that old and older. All single purpose accounts that I deleted when done with them. If I recall, all of them had something pop up about verification when Google became more strict. But I hit ignore and that was that. Doesn't mean it won't happen again. This thread is about people creating new accounts via Tor today, not legacy stuff. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor & Email?
> We've generally suggested gmail because their bulk account creation > process was good. It seems this is not the case any more. What is this bulk account creation you speak of? The session leak occurs with the non-https intro/splash/welcome screen that appears right after new account creation. It's a minor risk though, just change the entry link they have on the splash page to https, change your password/sec question and log out and back in. > This is false. I just created a gmail account via tor without > needing a phone number or any other information. Hmm, you mean "just", as in today? What exit were you using? Want to sell the account for bitcoins? Kidding :-) I'm interested in solving and documenting the technical part of this issue... > I heard that many times from differen people but I cannot creat > any gmail account without asking sms-verification about 2 or 3 > years... And tried do it many times ... as I too have tried maybe once a month for the last year or so and have never been able to create a new account. If it's possible, it would certainly benefit Tor users to know how to do so reliably. I also have access to various residential dynamic pools where I can obtain a different IP/subnet at will. It has been equally long since I've been able to reliably create a new account via them as well. It would be cool to map *.google.com to an exit and when someone here has success, post the exit to see if others can test it sucessfully. I say map, because Tor often rotates exits during the creation process time, which can only confuse things worse. > anti-ddos/spam/too-many-creations-from-a-single-ip-address detector > is tripped for tor exit nodes and requires other information. Are you referring to google search? Yes, that service pops up a message stating that with a captcha. However, I've never seen any such message appear when attempting to sign up for gmail. > I just tried, and was unsuccessful in the attempt. I had to answer > a CAPCHA (which is not a big deal) but was then confronted with a > request to receive either a text message or a phone call. Sorry - > that is a deal breaker. That is exactly what occurs for me. Fill out the one page form, I select USA as the country in the drop box, hit submit, the next page is the phone verification, at which point I select "don't want to give my phone" or another appropriate/true choice, put a little complaint/suggestion in the comment box, hit submit... and give up. It is exactly the same whether or not I supply a 'recovery' email address, which by the way is the only optional item on the form. > I have a fully anonymous email from gmail (about 1 yr old) > I have had several other accounts created at gmail previous to this > Have they changed something very recently? About a year ago it seems. This is about the ability to create new accounts TODAY, without using invites or phone verification. > Why are you using GMail, then? It is a legacy application, undergoing research for migration :) And simply having one is still useful to play with Google's other services in an integrated fashion. > The link above returns nothing. Works for me since five minutes, try kicking your Tor. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor & Email?
>> The only recommended way to use email with Tor is to use web mail, >> e.g. https connections to gmail. Keep in mind that google does not allow new accounts to be created via Tor. Unless you are willing to give up your phone number. Also they expose the GX session key and other cookies during the signup to login phase, even if you carefully forced ssl urls, so your minty new vanity named account is subject to immediate exit hijacking. They also bastardize IMAP and mail purging, store and read your mail for life, corroborate with the NSA and generally suck ass otherwise. If any of these bother you, and for most purposes, you're better off finding another mail provider :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Setting country code?
>> >> Yes, please see https://www.torproject.org/docs/faq#ChooseEntryExit - >> >> We recommend you do not use these — they are intended for testing and >> >> may disappear in future versions. What?! Disappearing?! People MUST have the ability to choose their exits. To get around filters, make use of sites from their own region/city, debugging, etc. So I hope I just misread this link. Because that would be a huge loss. In fact I believe Tor's exit mapping facility needs to be enhanced. At least under the hood. I should be able to MAPADDRESS: - Any, or multiple, given CIDR blocks to an exit: a.b.c.d/n -> a.b.c.d/n.fp.exit - Any, or multiple, given domain wildcards to an exit: *.google.com -> *.google.com.fp.exit *yahoo*.com -> *yahoo*.com.fp.exit The internet quit being hosted on a single server over ten years ago. You have no idea how handy this would be for testers, researchers and end users alike :) Seriously. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Adding voip to torchat
> From reading on OnionCat , the clients are essentially hidden services > once a connection is made it is bidirectional. No, OC is just a daemon shuffling data back and forth across a Tor HiddenServicePort. Tor provides a bidir return path to the source, which the listener (OC) can use, if it thinks it should... > If A initiates a connection > to B , A can be sure he/she is talking to B Yes, up to the 80-bit addressing of Tor. OC translates your request for a v6 address into an onion address and puts that stream through Tor. > but the opposite isnt true .So > if B has to sure he/she is indeed talking to A , he/she has to initiate a > connection to A [. to query and confirm it .]. Yes. Because B's onion is seeing no onion source address. And B's OC is seeing an arbitrary v6 source address. Since most protocols require a reverse channel, it's actually B that is more at risk of sending their data off to onions unknown. Luckily, that is where B (if human and not a dolt) usually notices something is broken and quits it. And it's kind of pointless to do such spoofing because if A wanted B's return stream, it should have just asked for it. So it would just be for the lol's of A blindly convincing B (or B's computer, app, etc) to disclose something to C. > Which is what torchat does to authenticate both the parties > , even if OnionCat is being used the same has to be done to ensure both the > people know who they are talking to. Am I right in my observation ?? Yes, and as before, OC had plans to do a little OCtoOC ping pong too. If running IPSEC, etc over v6, learning or making stashes of source key-v6 associations, that might do it too, more work, same thing. OC is just another app that plugs into Tor, no different than TorChat. It just happens to present the user with a cool and immensely useful v6 address instead of a cute little chat prompt. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Adding voip to torchat
> During preliminary testing we purely relied on communicating the > hidden services names (that map to OnionCat IPv6 addresses) in a > properly authenticated manner. OnionCat has no authentication between it and and the node it is running on and it's peers. It's somehwat possible though. There were some OC features being drafted to assist with this, though I do not know the current dev status on them. Till then, it's the honor system. On the big plus side, OC provides IPv6 function. Most you can do over native IPv6 can be do over OC over Tor (except maybe routing which need yet another layer). So you can do auth via ZRTP, ssh known-hosts, even IPSEC/IKE. So some good classes of bluffing are mooted by this I believe, no. If app has no built in and no IPSEC, then you are at risk for today. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Fwd: Re: DMCA Infringement Notification: Copies of 14 complaints
> your residential DSL service > is only for the use of your pcs > within your home. > You also are responsible for any harmful or illegal traffic that comes > from your DSL modem. When others among you are faced with contracts that state these two things... it may be worthwhile to defer mentioning what you are running and why (as in the former), until you have exausted all attempts to get the ISP to hand off the latter to you. Such as by writing them a note directing them to forward all such requsts to you for direct processing between you and the complainant. And that you expect the complainant to withdraw said complain from ISP in a timely fashion as the result. Then you can take your case up with the complainant and maybe they will listen and dismiss. Yeah, we all know the likelihood of that, but unless you've sent them the Tor boilerplate and specifically requested dismissal, there's no point in doubly jeopardizing youself with your ISP in the very first move. Now the mafia may not dismiss. But say your line was used to hack an edu system or post drivel on some board, etc. Those types may be much more likely to understand in your explanation as Tor as common carrier. And therefore relent. Always read your contract and plan your moves ahead. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Fwd: Re: DMCA Infringement Notification: Copies of 14 complaints
Mostly off-topic, except in regard to a possible defense for Tor relays/users in the event any go that far. I'm amazed they are able to lodge cases based on what appear to be BT scrapes of BT announcements. Certainly your announcement could be just that, metadata only. And your file could be /dev/zero. And you could be using a client that skipped integrity checks when announcing and serving. All for research and the lol's of course. Have they ever entered court with actual packets served up by the user? Preferably backed by some form of third party chain of evidence? From any network, not just BT? Because if that's not the case and all they're doing is scraping, there would seem to be quite a bit of reasonable doubt available that could help yield an easy out for any defendant. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: openssl 1.0.0c
> Is openssl 1.0.0c tor-safe? Don't know what you mean by Tor-safe. But I can say that tor 0.2.1.27, libevent 1.4.14b and openssl 0.9.8q all compile and run fine together on a legacy FreeBSD 4 box. A spot check says 1.0.0c will too on an 8 box. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Select/wholesale censorship/takedown via directories
Two related questions for general comment: 1) Couldn't the directories to which hidden service descriptors are published elect, or be ordered, to decline to publish certain descriptors? 2) What happens in the event of a sustained global DoS or a simple coordinated LEO/ISP shutdown of the directories? There have been cases where contributory, aiding, etc, regardless of common carrier principles, has been an argument that has held traction against other sites or systems. It is not unreasonable to assume such an attempt may be made upon Tor. Is the degree to which Tor is designed/distributed sufficent to render the difficulty out to at least the equivalent of shutting down all the relays? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Tor web dox bug
https://www.torproject.org/docs/tor-doc-unix the above page says tsocks. it should say: http://code.google.com/p/torsocks *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: leaker-optimized versions of Tor
> A version should come > as a convenient and containable virtual appliance, or packaged as > plug computers. What about the idea of a self aware virus running within/upon any given [overlay] network. The network would provide an execution platform. The virus would roam around, ferrying data, keeping tabs on its life/storage/replication/peer goals, things like that. Maybe somewhat like FreeNet but where the virus determines lifetime within the network limits vs. the popularity/last use (never used FN so maybe my description is wrong). Doesn't wikileaks use Tor (modified/private?) in a few places? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Ways to be notified of new relays?
I'm testing a relay here a bit more in detail and would like to know what mechanism will allow the soonest detection of it by another unaffiliated client across the globe? I can pull and crunch the /.../.tor/ files. And via the controller I can also 'getinfo desc/all-recent'. Maybe there are settings to emit new ones as soon as they are learned in real time to the controller or to logs?? And I'm not quite sure whether they come in bulk updates off the directories or piecemeal. I'm sure the dirs don't push to the clients though. Thanks. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
> I'm too obtuse to understand, just with your footnote alone, > what a "hidden service trap" is - would you provide a further > explanation, or a link to one ? A hidden service trap is a hidden service run by any one/entity you'd rather not be doing business with. A trap, a lure, a ruse, a sting. Leading to possible incrimination, characterization, etc... bridging same into the non-anonymous real world. Could be a Bad/Good dude/thing, depending on your point of view. > Lucky Green on WoT Oh yes, agreed, I never claimed signing into OpenPGP WoT was magic solution. I littered it with soft disclaimers. As before, it would be an *additional* metric which could optionally be used in selection calculations if desired. Save for a few, the node owners are mostly known only by IP. One might feel better if there was a human keychain wrapped around some of them. Many of us fully understand the weakness of such a WoT as applied to Tor, for which there's no requirement to elect to use its metrics. Much as one may or may not choose to utilize nodes that appear to reside in certain countries, appear to run on certain platforms, have cute nicknames, etc. Were I to be running a node, maybe I'd sign others based on whatever I felt they meant to me. Maybe others would similarly sign mine. Maybe the EFF would sign some, maybe Tor, maybe CCC, maybe torservers, maybe people on mailing lists, maybe FOSS devs, etc, the usual. And maybe I'd let degree of separation from me or them be a weighted guide as to the rest. It's just another tool to use, not magic. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Relay flooding, confirmation, HS's, default relay, web of trust
Some further thoughts on an already mixed thread... > Would this increase anonymity? As pointed out previously, not much. > Attacks against Tor anonymity usually relate to entry-point/exit-point > traffic correlation... Regardless of how many segments are in the > middle, if your adversary can "corner the market" on exit nodes, it > doesn't matter how many intermediate relay nodes you're using. (Correct > me where I'm wrong, experts) Ahh, ok, I see, entry-exit correlation/tagging/timing/confirmation... interesting. I guess a longer path length could only help a quite tiny amount with that by adding some jitter, packet loss, dead circuit churn, etc in between. It certainly directly helps a lot against those entities trying to do simple hop by hop flow/log requests. Non-exit relay by default wouldn't help regarding the exit part as no one's suggesting turning up new exit relays by default. But it could add more guards making observing any useful subset of them costlier. But also make the less traffic in them more likely to be yours. And what if the oponnent runs a hidden service trap?... seems that then just watching or running the client's entry guard [1] is all that is needed to confirm both connection and content? Yipes?!!! I'm no expert. This sounds like a very hard and real problem. Thanks! [1] One single lucky node, not two, the trap serves as the exit watchpoint as well. > Would this increase the health of the overall network? Yes*! Are there anonymity drawbacks to having a glut of available bandwith? Or a glut of legit nodes? Or both? I've not yet considered that in my suggestion of a model in which Tor can in fact be used for bulk/P2P transfer and remain resource healthy. > Or, as mentioned earlier, we can assign an OR a level of trust > commensurate with its age? Maybe there would also be benefit in a web of trust amongst nodes not unlike a keysigning party. As with social networking, people vouch for each other in various ways and strengths based on how they feel that person meets them. I don't see any reason why node operators [descriptors] could not keysign and have that web encoded into the descriptors, directories, DHT, etc. Degrees of separation could also be encoded, and no web is impenetrable. So it would be just one more means of scoring nodes. The sigs would be saying: Hey, I know this operator in real life or online. They have the skill to run an up to date, reasonably secure node and at least check for cold compromise once in a while. And I would be reasonably comfortable were my traffic to transit their node, excepting of course lawful order or coercion. As before, loose, just another means. > Also, symmetry of up/down bandwidth can be an issue too... which is > unfortunate. Issue? A non-exit relay runs the same bitrate in and out of its interface, bytes in, bytes out, over time, it's impossible not to. So your maximum giveback is limited to the lower of your asymmetrical rates because you'll saturate the slower side at any greater rate. The unfortunate thing about it is that all four of economies, tech, policies and outright supression conspire to make asymmetry what you see in the consumer market. As opposed to cable (and various RF tech and fiber PON's), fiber and dsl aren't really tech limited to asymmetry. So you're just seeing the other three in action there. Protest, buy more, or co-op and trench your own neighborhood :) s/hit/hip/ ;) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Anonymity easily thwarted by flooding network with relays?
> might as well shit it. And, as in my post about torrent and non-bandwidth LOL, that was one heck of a good typo :) Have a good weekend! *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Anonymity easily thwarted by flooding network with relays?
> Does anyone have any comments on this paper? Any reassurance? Frankly, > this is scary. Yes, it's absolutely scary, and should be obvious. There's only maybe 3200 fingerprints out there. Heck, even the local computer club in a major city could raise enough funds to deploy a handful of early guards, then drop enough cloud nodes [1] on the net to make the odds of compromise quite worthwhile... certainly enough for a DefCon/CCC style executed proof of concept / vulnerability paper. [1] Rent for a day or so > I nominate this paper as a founding reason why Tor should permit users > to increase the number of relay nodes used in each circuit above the > current value of 3... I'd love to have it be arbitrarily selectable from say 0-25 via the control port and config, with a default of 3. People already do that with patches, might as well shit it. And, as in my post about torrent and non-bandwidth resources, a small subset of 'power users' using more than 3 hops wouldn't seem to cause much transactional load to the TorNet. Rather, their choice would likely only hurt their own bandwidth and latency. I'd also nominate the issue, and others, as further reason Tor should ship by default as a non-exit relay... and yes, with a nice info screen and a disable button. There is absolutely no reason not to think the opponent has not already clandestinely and sufficiently flooded the net with the current nodebase. The only workable defense is to deploy the users as countermeasure and hope that however many users there are... 10k, 100k, 250k? etc, as time goes by... will make flooding cost prohibitive. Think of it this way... millions of users willingly and knowingly turn their PC's into Bittorrent piece servers every day. Want proof, check out the stats on thepiratebay.org. They happily risk extensive and conclusive monetary civil suit against them. That's nuts, but they do it anyways. There are currently very few laws [as opposed to contracts [2]] in the world that would prohibit running a non-exit [or even an exit] relay. And any other inquiries would outright fail due to common carrier. Or at most be relegated to contributory or neglect... a much nicer outcome than the suit above. Given the risk is less, it would seem to be well rationalized, justified and proper to therefore ship as a non-exit relay by default. And reap the benefits. I'm NOT advocating use of anon networks for any less than legitimate purposes. Rather, that anon networks aren't just some robust grail for only the people that 'need it'. But that that exact same robust grail should be integrated by users into the whole variety of their daily online activities as desired, and offer back what they use according to their benefit. With other P2P applications, you're either required to be a provider or the protocol works against you if you're not. Which means to play, you have to pay. At least with Tor shipping as NErelay by default, they'd get a nice "we're helping by default and here's why" screen and a button to opt out. I'd announce it as a live enhancement trial to be brought out in the next few releases and see what happens in regards to user acceptance and net capacity. Provided scalability issues are addressed in preparation first. [2] Which are already ignored and broken by provider and subscriber respectively. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
> grarpamp: i'll follow this up with links for various UDP Tor papers > and discussions. i've got a bunch of bookmarks somewhere... You don't have to or anything like that, or maybe for the wiki. I still need to check out the project site and AnonBib more and will probably scrape the web archives into a maildir someday too. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
>> Wish the mbox or maildir archives were available/mirrored for easy >> search, reading, reference and reply using native mail clients :) > > ...I wish people would stop cross-posting between -dev and -talk...;) Hey, I might just be inclined to trade detailed examination and separation of message content, as well as what comes up in 'group reply' to prior messages, for that ;-) I do miss a handful now and then. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
>> So long as users are covering their bandwidth with giveback [1], I ... >> - indeed provided back to the network as a 'moral' condition by >> those same users. ... >> case) you need to give back at least 6x your use. So you will already > there's always a catch. ;) Heh, yeah, no one ever suggested this would happen, as the leecher mindset abounds :) It just seemed useful to actually ask for, examine and collate the parameters under which it *could* happen successfully. And the areas where Tor, or any other anonymous system, is permanently incapable as a limitation of architecture. Or where the system actually could be enhanced to better support what some users are already going to use it for regardless of disencouragement. It should be noted that one reason people ask about using anon systems for such traffic is because they feel risk when doing so in the clear. Either as consumer, distributor or participant. Being anonymous may actually be the key they need that allows them to run the seed/server/distributor side without fear. In other words... I'd bet it's called 'filesharing' because most people actually *do* want to give back and share, albeit safely. Is anonymity the missing link to the global filesharing utopia invisioned be all the various sharing systems? Who knows. We'll find out. >> [2] Isn't there a proposal out there to better handle magnitudes >> more users [and avoid shutdown points] by getting rid of the >> directories and self-hosting the TorNet into a DHT or something? > > Tor would become something else, perhaps UDP Tor. > > there has been more written on that subject than i can do justice Wish the mbox or maildir archives were available/mirrored for easy search, reading, reference and reply using native mail clients :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
P2P over Tor [was: Anomos - anonBT]
> " > It's my understanding that BitTorrent is less of a bandwidth hog as it > is a connections/circuits hog. These are expensive to create and you > can't balance your BitTorrenting by hosting a high-bandwidth node > because to have 0 net effect on the network, you'd have to host a > circuit's worth of nodes for every circuit you're using for BitTorrent > connections. > " > > Bandwidth is surely finite but I'd bet safe to calculate. I would think > it easy to reach zero net, starting at minimally six times your use. > > Circuits are a separate issue. AFAIK, they are just consumers of state > on the nodes... CPU, RAM, TCP, etc. I can see where adding a node > [any node] in at 6x [or any x] would help distribute that load as well. > > Other than between the tracker, BT spawns a bunch of bandwith filled > pipes, up to some number of peers limit in the app. What is, if any, the > relationship between IPv4 TCP flows and Tor circuit usage? That could > help calculate the replacement value for non-bandwidth node resources. > >> Am I wrong, Tor Old Ones? > > I sure haven't got that far in reading to guess yet, so yeah, if someone > has a hunch, that would be interesting. Maybe 6 nodes that add up to > 6x bandwidth or something. > > Not sure about anyone else, but I do think that with the way things > are going on the internet, more people will be looking to anonymous > systems in general to supplant it for their 'filesharing' and other > interests. That accumulation might be unstoppable. So hopefully > those sorts of uses are being thought after and researched/planned/coded > for. Thought about the non-bandwidth parts of the load some more... There doesn't seem to be a need to quantify it with a numerical estimate of what amount of resource giveback would yield a zero sum impact for those parts. Say you're using 'filesharing' in the form of BitTorrent. Your single PC, when operating as a non-exit relay [1], can surely handle many times the trivial sum of all the various non-bandwidth resources described above that you would use along the way. Think of simulating a TorNet by running all the needed directories, nodes and operations bound to IP aliases on one PC. Conservatively say [3] you will have up to 100 P2P circuits at 6 hops each... Any PC should be able to handle that entire load with lots of headroom. So long as users are covering their bandwidth with giveback [1], I think it's safe to assume the rest of their overhead is also covered by the addition of that node to the network. I no longer think the standard reply/FAQ regarding such uses of Tor, excepting [2], should be an unqualified: Tor can't handle it, so don't. The answer should be that... so long as such giveback [1] is: - understood by users to be a necessary 'techical' condition to support their use of Tor for bulk transfer. - indeed provided back to the network as a 'moral' condition by those same users. ... they should then feel free to use Tor for whatever they want. BitTorrent, P2P, FTP, streaming media, chat, etc. And OnionCat is the shim that will allow the apps to communicate seamlessly. Though not as simple a response, and requiring donation by the user, it seems to be the more reasoned one. Further thoughts welcomed. [1] It's already established that in order for your use of Tor bandwidth to be zero sum (in the Hidden Service <--> Hidden Service case) you need to give back at least 6x your use. So you will already be running said relay (for the purpose of bandwidth giveback). [2] Isn't there a proposal out there to better handle magnitudes more users [and avoid shutdown points] by getting rid of the directories and self-hosting the TorNet into a DHT or something? [3] As the average bandwidth that most users [dsl, cable] will be able to give back is small, transfers will be slow anyways. Which may limit adoption [P2P peer counts]. Regardless, the limiting factor is really only bandwidth because (dice up the giveback/6 you can legitimately use... amongst P2P peer circuits however you want, ie): dsl/cable = 1 x 256Kb/6 = 10 x 25.6Kb/6 = 100 x 2.56Kb/6 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Controller and dns lookup/connection
> In the past, this used to display the FQDN as the first thing > that traversed a circuit, then the IP thereafter. Hey, wait a minute, when using torsocks and netcat, this is for a site that is unmapped: 2274 SUCCEEDED 37 amd.com:0 2278 SUCCEEDED 33 163.181.249.32:80 And this is for one that is mapped to a specific exit: 2381 SUCCEEDED 39 intel.com..exit:0 2391 SUCCEEDED 39 192.198.164.158..exit:80 I've got all the firefox proxies set to a local polipo and checked tcpdump locally for dns leaks to the dns box... everything's being sent to the tor socks port on the tor box fine. Yet using firefox as the client does NOT cause display of the dns name when visiting a new site... one that's uncached/visited/lookedup since restart of Tor, polipo, and firefox [netbsd.org]: 2956 SUCCEEDED 41 204.152.190.12:80 Yes, I tcpdumped at the border router too, no dns leaks. Anyone else seeing this? Weird. Tor v0.2.1.26 libevent 1.4.14b-stable OpenSSL 0.9.8o polipo 20100302 firefox 3.6.10 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Controller and dns lookup/connection
On occaision I watch this: authenticate "pass" usefeature extended_events usefeature verbose_names setevents stream getinfo stream-status In the past, this used to display the FQDN as the first thing that traversed a circuit, then the IP thereafter. 1072 SUCCEEDED 24 torproject.org:0 1073 SUCCEEDED 24 38.229.70.10:443 [I may have rememberd the stream, circuit and port numbering wrong, but anyways...] I've noticed lately that it only displays IP's without showing the DNS lookups beforehand. Obviously lookups are still happening. But where did they go in the output? It was massively useful for debugging, and for finding things to block or redirect [ads, bad things, etc] with: mapaddress junk=127.0.0.1 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IPv6
It doesn't seem that Tor is binding and transporting IPv6 yet. However the client could presumably set up a VPN with a tunnel broker. And do some interesting things with OnionCat as well. The last mention of IPV6 in the release notes was 0.2.1.18. On 11/4/10, Olaf Selke wrote: > Hi, > > will Tor clients take any advantage from an exit node with IPv6 > connectivity? > > cheers Olaf > *** > To unsubscribe, send an e-mail to majord...@torproject.org with > unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ > *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Directory server issue/bug?
Given a little script.
Plug it with an onion of your choice that is currently up.
Run script, sleep 15... repeat... repeat...
You may get:
HTTP/1.0 200 OK
[with descriptor attached]
HTTP/1.0 404 Not found
[with nothing attached]
[nothing at all]
[with nothing attached]
Why do some have no response?
Why does a no response come and go?
I can understand a getting a consistent 200 [until expired]
or a 404, but not a no response.
dirn='
86.59.21.38 80 tor26
216.224.124.114 9030 ides
213.115.239.118 443 maatuska
193.23.244.244 80 dannenberg
208.83.223.34 443 urras
80.190.246.100 8180 gabelmoo-legacy
128.31.0.34 9131 moria1
128.31.0.34 9131 moria1-legacy
194.109.206.212 80 dizum
80.190.246.100 8180 gabelmoo
'
echo $dirn | awk '/^[0-9]/ {print $1,$2,$3}' \
| while read ip port name ; do
echo "= $ip $port $name ="
printf 'GET /tor/rendezvous/ HTTP/1.0\r\n\r\n' \
| socat -d - tcp4:$ip:$port | strings
done
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Crypto for hidden services [was: TorFaq on https]
>>or is it still the general recommodation to >> run hidden services without https? > > I would recommend that hidden services not use HTTPS. The Tor hidden > service protocol does an adequate job of authenticating servers and > encrypting traffic to them. In the hidden service context for all below... Tor does NOT authenticate any particular underlying service [web, mail, etc], nor does it encrypt traffic to/from them. Tor merely authenticates and encrypts between two Tor daemons, one as a client and one as a HS. Give an elaborate setup behind a HS, perhaps tunneling the stream off the server, across the net, to other parties who terminate it on some daemon or cloud. Maybe some WikiLeaks form of submission/storage, or joining anon systems, or just a clueless HS admin. Or that someone is able to read the particular crypto Tor uses, but not the crypto your tunnel uses. Would you, or the provider of the intermediate or final services, not want that extra layer of protection just in case? Your bank in it's internal cloud? SSH/IRCS/SILC to behind a HS is an extra tunnel. It costs nothing. Were it still available, no one in their right mind would use ssh -c none. > In addition, it is unlikely that any CA > that Firefox is configured to trust would issue a certificate for > a .onion hostname. Perhaps, and quite unfortunately, not. However, even though the chain would break on the hostname, it would still be of supplementary value if some dual-homed site of importance to the user ran with the same cert [fingerprint] as on the internet. Especially given that the prevalence of the below aside is presumed to be extremely low. [aside: As DNSSEC is not global yet, multi-homing a non onion cert would be on the same par as a bogus/stolen cert and mitm dns, for say your bank.] >>is the server (hidden service) >> privacy threatened by using https too in any way? > > I don't see any risk to the server. Not particularly. Though it would add additional fingerprinting oppurtunities beyond Tor and the service themselves. This is the only one I can think of. >> "These objections all apply to HTTPS, TLS, SSH, and generally all >> cryptography over Tor, regardless of whether or not the destination >> is a hidden service" The whole, well we've got the anon system doing node to node encryption/auth, why bother with TLS... sounds an awful lot like why Johhny can't encrypt and why the internet still isn't encrypted. As there doesn't appear to be any real reason NOT to use crypto over top of any given anon system, might as well do it just in case. Foregoing extra 0-day's in crypto libs as applied, and the above fingerprinting... why pan it? And PKI, even amongst the anon, can be very useful thing. Communuties will be built, PKI will help. It's no different than the internet. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Firefox ctrl-shift-del vs. Torbutton
For the users who have checked all the c-s-d checkboxes and reviewed all the firefox.edit.preferences pages... For any given phase/method of browsing/usage, does torbutton clear any additional state beyond what c-s-d clears? Particularly with regard to transmittable data [whether remotely or locally generated], as opposed to non-transmittable data that is merely cached such as images, etc. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Descriptor fingerprint format
Descriptor fingerprints look like this: opt fingerprint 0001 AC1F 9AE6 9A00 3C5E 6F02 73CB D69E C6E7 6926 ... opt fingerprint FFEB 470C F379 9E9C 5956 8521 8627 9ED5 55AB 1340 It's an extra routine to remove or add the spaces for scripting, with the control port, etc. And who really uses them in a human fashion with spaces anyways, this isn't a keysigning party :) It also uses about 9 spaces x ~3300+ descriptors ~= 30,000 bytes of traffic for one client to pull the entire relay list. Multiply that by number of clients[?] x the frequency[?] ~= bandwidth wasted. Maybe another ~10,000+ bytes x clients x freq could be saved by not publishing the junk after the first left bracket '[' in the windows platform lines. Any ideas on removing these two someday? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excessive scrubs
> And some would consider phony names used in email to show > lack of courage of convictions when voicing opinions in public Throughout history, some of the world's most important movements and changes have originated with the Anonymous. Anonymity is a tool whose use case is rightly selected solely by the user, not others. As are defenses against it the purview of the latter. Neither free to trample the other across the divide. It's a beautiful thing. During such selection, certainly some would consider system nodes run by those who speak against such anonymity (in whichever the case) as fine candidates for their excludes... lest they become unreliable partners (in whichever the heat, or the whim). Then again, how does one select any particular partner from the space, be it node or human? Which assertions are true? Which shall stand? And what value to assign the many silent ones? Most curious questions indeed. Therefore, rest. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
IRQ balancing
Another links regarding earlier posts on this topic: http://www.ntop.org/blog/?p=1 http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux http://www.alexonlinux.com/why-interrupt-affinity-with-multiple-cores-is-not-such-a-good-thing *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: What about private & Public Keys
The net already changes session keys. If referring to the base key... no. Because a compromised computer must be presumed broken until fixed. Rotating keys would just churn the fingerprints, directories, etc... all while the attacker continues to happily read whatever the Tor daemon is doing. Practice good admin, secure your machines and audit your code instead. On 10/18/10, Gregory Maxwell wrote: > On Mon, Oct 18, 2010 at 2:37 PM, wrote: >> Maybe this subject has already been discussed here. >> >> Given, an attacker succeeds to break into a large number of tornodes and >> gets a copy of the secret keys from all those nodes. This would increase >> the chance to decrypt parts of the traffic that goes through the tor >> network. Am I right? > [snip] > > No, Tor uses perfect forward secrecy. The session key for every node > to node link is encrypted with one-time ephemeral keying. > *** > To unsubscribe, send an e-mail to majord...@torproject.org with > unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ > *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Me <-> Tor <-> VPN <-> Internet?
> a free VPN > There are VPN providers that will let you pay anonymously. Among others, I would be interested in reading posts containing lists of VPN providers that offer one or more of these two services. Thanks. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BetterPrivacy - necessary?
> I think Polipo was a better cache, and since an HTTP proxy can't filter > evil content out of HTTPS responses, Privoxy's filtering was not very > useful. Note though that the definition of evil can be game changed by running your instance inside a secure sandbox, behind a nat, and minding your session data appropriately. With no access to the rest of the system and no crosssite cookie/etc trails, that's a good win. You're really only left with the case of a rogue applet doing a 'whatismyip.com' to defeat your use of 1918 space and then sending the result to whoever your adversary may be. Depending on what the user is doing, that could be a big weakness that warrants the tradeoff of disabling 'evil' features. As usual, it would be awesome to have a tool that could de and re encapsulate https so that proxies and caches could do their thing with it. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The best way to run a hidden service: one or two computers?
> Use the macchanger utility. Make sure you write down your original > MAC first, in case you need to switch back to it later. Original is commonly available in Unixlike boot dmesg output. I'm as yet unaware of an available changer that will burn the hardware itself, as opposed to simply programming the running MAC register till next reboot. > sudo ifconfig eth1 hw ether 00:00:00:00:00:00 # make this > something believable Beware setting the layer2 multicast frame bit. Note also its tricky position and endianness. > See some preliminary design thoughts [1] we've been having for T(A)ILS > to try and find an approach that makes your network interface appear > different from the one it really is, and at the same time prevents it > to appear real weird (a bit like the default User-Agent used by > Torbutton). Set to current Intel vendor prefix, randomize suffix, ban original MAC, 0x0, 0xf, other obviousness, etc. Full random might look like a flaky nic to various hats, mostly old ones. > you'll likely need to have the interface down before changing mac: Some will bounce interface, all should gratuitous arp unless forbidden. Be careful with ipv6 emissions on ifup. > however, if an attacker has access to read this locally they've > already compromised Unknown here if original MAC can be read, or reset the nic for reading, via the same original boot-time routines at any given later runtime. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
Well, no rants, but I'm in qualified agreement with Scott [just this once, heh]... that yes, those of us stuck in 80x25 terminals and antique text comment databases could use a multiline format. It the project is concerned about the replace vs. add semantics, one could add two new exclude[exit]nodesmethod options. Where method is replace or add. Yet it is just an ease of use thing, and does have a certain impact on downstream controller code. So as long as the config does what the docs say it does, in whatever mode it ends up taking, that's fine, people will hack and make do either way. Config file and controller interface should act the same though. Also, regarding the interaction with HS directory lookups and excludenodes... i would suggest that specification in excludenodes should prevent all contact with such node for all reasons. Or just make another option for how to handle that case as well. This is more important than the above paragraph. As one could have a node that is a 'bad' exit through no fault/intent of its operator... such as being plugged into a non-ideal isp... yet it would still be perfectly useful when acting as a non-exit or directory provider. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor seems to have a huge security risk--please prove me wrong!
> believe that the "global external passive adversary" does exist > though (via ... secret rooms that splice cables and copy off > traffic in transit) The historical existence and use of taps, whether for international/local intrigue, criminal, research or black/white ops, with or without clear legal authority, is well documented. Even moreso is the public product line developed / purchased and capable of use by various GPA's... carnivore, narus, sql, tcpdump, fiber toys, etc. As is the base interest in research towards any potential application. It should be assumed that GPA's are actively present, at minimum in highly active research mode. At most, that remains to be seen. > 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. Further, simply because there is not sufficient evidence to the contrary, and because the history of cover ops and secrecy is equally documented... it should be assumed that any sufficiently large number of anonymity nodes are, in fact, not run by disinterested kids in their mom's basement. Just because the IP says residential dsl/cable, some corp or colo somewhere, or even signed by some seemingly well known internet figure... as opposed to mapping back to any given adversary... does not give the user reason to dismiss them. The monetary cost of owning a kilonode or two is of trivial impact to an agent capable of making productive use of such a set. Agreed, writing off a known [or unknown hypothetical] strong adversary is far better than disbelief in same or failing to see one at all. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: PayPal is not the only organization that blocks Tor.
> It is also worth noting that Craigslist prevents the use of Tor albeit in a > very strange way. I can second having similar problems with Craigslist, albeit from another fixed, yet listed, location on the globe. Any Torizens in SF, feel free to swing by CL and offer them your cluebat, I offer virtual beer :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: https proxy [was polipo]
>>> I can see it could provide some protection against... >> No. Why do you think it could? > - because by default - lots of additional reasons... The shim was just supposed to be a tool so you could hook into an http[s] stream and do whatever with it, or nothing at all. For instance, I've always wanted to cache static images and pages coming in over https via Tor/Inet. Can't do that yet. Throw this shim between your browser and your gateway, tee it off into squid and you could save some significant bandwidth. With https becoming ever more popular and likely to be everywhere soon, I'm sure someone will write the shim sooner or later. > (Tahoe LAFS / encrypted $cloud storage for your dig :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: https proxy [was polipo]
> > https://anonymous-proxy-servers.net/en/anontest > As I understand it, Polipo can't scrub the headers of an HTTPS request, Nothing in the open source field can do so yet afaik. To do it, a shim needs to be coded and placed between the application and Tor. user <-> browser <-> [optional tool] <-> shim <-> tor:9050 The shim needs to listen on a proxy port (and or two configurable ports (for http and https)) and connect out to the world (or tor) to a proxy port (socks) (and or two other ports (for http and https or whatever port the input protocol used)). It would pass http unmodified. It would break end to end https. If the destination site had an invalid cert, it would present an invalid self-generated one to the client. If the destination site had a valid cert, it would present a self-generated and self-signed one to the client (which had obviously included the shim's root as a trusted cert), simply to signify to the client as to validity. Identity would be available from verbose logging in the shim and via an http[s] port on the shim itself. It could furthermore 'tee' off two output ports from it's bottom and receive two input ports from it's top. These would be a more general hook into 'optional toolchains' located in between the client and server side, decoding and shuffling the data stream in and out to a toolset at that point. It should have no 'censoring', caching or other features.. as that is what the optional toolsets do best. Note that 'browser' could be anything that can speak http[s], not just FF/MSIE. So 'plugins' are a non option. And that the 'optional tool' might be squid or polipo or whatever. And lastly, erasing your OS and other info from your headers makes you stand out as an obvious eraser. It's better to use a dead common and up to date os and browser and then mind your sessions properly. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Project 2008 Tax Return Now Online
On 8/19/10, Seth David Schoen wrote: Exactly! Even if any particular anon system was comprimiseable, why would any comprimising organization [save the full disclosure types] wish to play their trump card in public??? If any anon system is comprimisable, far better to listen in, under the convenient seal of black ops, until such a time as enough has been learned to effect an 'indictment' upon much more common fare, grounds and methods. The users of anon systems would always be better off assuming that they are indeed 'made' when calculating their exposure to certain riskes. And further, they should integrate defenses to those riskes into their usual mode of operations... rather than trust any given system blindly. Yes, it is good to watch the news and public records in detail. As sure, all trump cards are eventually played on table... the only question is when, and for how long they've been held. And given the subject of calculating riskes... any particular strong anon system is likely good enough for all purposes not invoving a position in which the direct target of such purpose is the same as one which is in a position to prosecute: ie: government. If you have ever talked to anyone related to the governent, you would know this is the case as they are hesitant to even mention the most mundane of obvious 'secret operational methods' used to go after, say, the most common of street whores or drug dealers. Does one not think that the grand high holy of holies between thy legs would be far more protected from disclosure than that? Onward Tor et al! *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Official torproject .onions
>> Are there any official (non-mirror) .onions run by the torproject itself? > https://trac.torproject.org/projects/tor/wiki lists some hidden services, > some of which are quite official, like the hidden service that points > to archive.torproject.org. axqzzpkfwezf3kku.onion - 'Sample Hidden Service' vdyrqdwjyx7kfnhy.onion - 'Another Sample Hidden Service' duskgytldkxiuqc6.onion - 'A fine example of a hidden service' (504 socks ttl_exp) 56apzofkmsmgb3yr.onion - 'The secure way to access archive.torproject.org' (504 socks refused) > The Tor Project itself mainly writes software and does advocacy, rather > than running Tor directory authorities, hidden services, or even relays. That is very right and proper of course. > That said, there are individuals who maintain hidden services and who > are also Tor developers. The line is pretty fuzzy in some cases. Unless the Tor project backs those onions publicly, they would just be personal services as like any other TorIzen. > Why do you ask? Because it's not clear which of the above are running on official Torproject hardware and/or under official sanction; and which may be mirrors, of possibly unknown repute, or possibly put on the trac by less than core parties. Without side confirmation, who knows what links are real or provided by which party. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Official torproject .onions
> etc ? And even though they wouldn't be much of a 'service', include any official 'Hello World's under 'etc' too :-) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Official torproject .onions
Are there any official (non-mirror) .onions run by the torproject itself? ie: servers/services falling within the administrative purview of the torproject that are running the Tor daemon and offer up hidden services. website ? file / rsync / mirror / archive / distribution services ? git / trac repos ? wiki / blog ? etc ? Thanks. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Why not TOR come up with an encryption system?
> And once we're requiring both sides of the communication to install > extra software, we might as well just have both sides just support SSL > and be done with it. Tor [exit nodes] can always attempt to initiate opportunistic IPSEC. You might be surprised how many servers out there do run IKE, whether intentional or not. Tor could reference docs as to turning it on when configuring exit nodes... It's not just HTTP[s] that needs it, but pop, imap, etc. SSL on certain ports, yes, sure. But IKE/IPSEC covering everything, and the PKI aspect of SSL where warranted, now that's swell. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Exit Node Sponsorship - looking for partners
> By the way, Paypal is the most widely used paypent processor Well, in the open social networking space, sure. There's all sorts of traditional commercial processors such as: https://www.authorize.net/solutions/merchantsolutions/pricing/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Reducing relays = reducing anonymity ? Tortunnel.
> Is there any working implementation of Phantom? I2P is widely in use, > and I must say that I really begin to like it. Code also looks much > cleaner to me (not: mature). Tor could use a complete rewrite. Not as of yet. They have a specification whitepaper and a video with slides to give you a pretty good idea. And a blog post indicating some form of midyear release plans. Other players in the anon space are surely good things. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Reducing relays = reducing anonymity ? Tortunnel.
> The author is a security researcher, the tool is ages old and > abandoned, as far as I know it doesn't work right away unless you > change some of the code, and it was written to check what tor exit > nodes where running sslstrip or in other ways were messing with the > traffic. > > I'm not really sure what this fuzz is all about. I wonder how many > people actually use it these days. > > Also, *if* Tor can be used in this way, it will be. If no white-hat > will write code to do it, the black-hats will, and the only difference > is that you'll be unaware of the tool. Agreed as to general sentiment. > Have you looked at I2P? http://www.i2p2.de/techintro.html > It for example allows both users and services to specify their hop > length, and uses packet switching instead of circuit switching. Phantom does this too... user specified hop counts based on their needs for speed vs. security. A nice design feature. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Exit Node Sponsorship - looking for partners
So long as more nodes come online, and those nodes have proper family statements, particularly regarding physical/geopolitical location... I don't really see any problem with any form of organization doing this. For profit or not. Nor any problem with any level of transparency. From open books and people to the typical privately held black box. Nor any need for silly "we don't sniff" declarations. That one especially makes me laugh, because users would be foolish to believe that there are not plenty of exit node operators that: a) do sniff, declaration or not b) are under orders to sniff c) are sniffed by the upstream doing so per a or b. and because users are supposed to know that if they're not using PKI or PSK complete with fingerprint checking, that they should indeed [!] expect to have their plaintext observed at some point, regardless of whether or not they use Tor. I agree in general that due to economies of scale and SLA/policy/contact setting with the provider, it's probably better to go for one year term upfront and somewhere between lots of small nodes or a few large ones. And yes, more transparency is more likely to successfully raise funds. Go forth and prosper, the market will figure out the merits. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Running a stable exit node without interference (Was blutmagie quad core upgrade)
> I Don't have any information about the subject but would it be possible > to buy own ip-range which would stay in my possession even if I switched > ISP's. I don't think it comes very cheap... >>> I have been thinking a long time how to run a stable exit node without >>> getting constantly in trouble. Your own Whois-data on your ip-range >>> (abuse-contact etc) could help a lot. This is all possible, and in fact, largely required. However, contrary to the requirement, many providers do not allow their customers to do this. https://www.arin.net/resources/request/reassignments.html If you poke around whois using IP address from small hosting companies you'll find a few examples of properly swipped delegations. Say a /16 farming out a /22 to the hoster. You can buy your own CIDR blocks straight from the RIR's just like any ISP can. But it's not cheap, and you are pretty much required to be well steeped in the tech and also already in business as a sizable ISP/hoster. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: GeoIP database comparison
Wasn't there a user driven opensource geoip database project somewhere? Sortof like DynDNS, users go to the website, it pops up their ip address, they enter their location in the DB. Thought it had some advanced stuff too, network admins could enter CIDR blocks, contact info and such. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Polipo/Tor error messages, sdfetch, LEAK
I'm running some automated widgets that connect to various onions. The breakdown of 702 Polipo connects across about as many onions is: a 85 ok b 1 ERROR 504: Connect to failed: General SOCKS server failure. c 9 ERROR 504: Connect to failed: SOCKS connection not allowed. d 99 ERROR 504: Connect to failed: SOCKS error: TTL expired. e 5 ERROR 504: Connect to failed: SOCKS error: connection refused. f 503 ERROR 504: Connect to failed: SOCKS error: host unreachable. The breakdown of approximately the same set of Tor connects is: g 531 Closing stream for '[scrubbed].onion': hidden service is unavailable (try again later). h 1 Tried for 120 seconds to get a connection to [scrubbed]:. Giving up. i 5 Tried for 120 seconds to get a connection to [scrubbed]:. Giving up. (waiting for circuit) j 250 Tried for 120 seconds to get a connection to [scrubbed]:. Giving up. (waiting for rendezvous desc) Note the port LEAK above can identify the onion if that onion is using a unique port from most of the other onions. Anyways... h) Tor should not give up without emitting a reason. f and g) So this means there was no descriptor in the directories? ie: blahblahblahblah.onion b and c) I figure this is a local problem, maybe with the Polipo/Tor connection. d and i) Does this mean that the onion is there and up but something in the path or the terminating service is broken? e) Is the hidden service on the host up but the userland daemon (httpd, etc) down? j) This seems to be an actual Tor issue in getting a response from the directories that could be fixed? I've noticed that some of the other 504 types will change to 'unreachable' upon subsequent connection attempts. However that is not always the case. Can the timeouts for the 'TTL' and 'waiting for' issues be bumped? Also, does anyone have an update to sdfetch that works with the current stable or alpha trunks? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Torsocks gitweb, where?
Found the repo: git://git.torproject.org/git/torsocks But the gitweb for torsocks is missing from: http://gitweb.torproject.org/ It should be there, no? This is the current torsocks home right? Or did it move or go unmaintained again? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Bug in .tmp file handling
Note the double .tmp file extension. There may be places where mkstemp(3) could be considered for use... .tor, these files. Restarted tor, watched .tor dir right after. .tor hier went from: lock state cached-descriptors.new cached-descriptors cached-consensus cached-certs to: same files as in from:, plus cached-descriptors.tmp.tmp back to: same files as in from:. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Performance with potential mass use
Excluding bandwidth as that's probably the easiest to guesstimate [6x each user's use for onion2onion case]. Assuming whatever typical usage patterns exist today, and expecting a partial shift to include more bandwidth intensive apps... What sort of issues exist as each new set of say 1K/10K/100K/1000K users start using tor? - Circuits tacked up funneling bits all the time? - Circuit churn? - Loads looking up directory info, HS descriptors? - Blowing out cpu, ram, disk, OS limits to crunch it all? - And anything else really, haven't much thought about it. - How big is the impact of each affecting item? - What fixes may be on paper or in the pipeline? - Wikify this thread? Kindof a general chat, no math proofs needed :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: What can see a server of a Bittorent when I contact with it through Tor?
>> you have to have every bittorrent client in the swarm ALSO running >> a location hidden service > Correct. All users and trackers would have to have a .onion address. > > I highly doubt any bittorrent client yet supports operating in this > > manner. > I have both a torrent tracker and client setup to do this. I wrote a UPNP > client to help setup end-user's as routers for the network too. I even > bought a domain name just for this. It's been tested and works quite well. Why is a domain needed? Unless it's for documentation/community which would be better housed in onionspace anyways. Bittorrent can be completely run in onionspace, today, NO exit facilities are required. Sure, onionspace is all point2point... no layer2, broadcast, multicast or routing... but typical user apps don't need that anyways. > So why haven't I released this? Well, I was asked nicely by one of the Tor > author's NOT to do this due to fears that the Tor network would not be able > to handle the amount of traffic torrent users would bring. Out of respect, > I did what was asked of me and did not release these to the public. What is certain is that someone will do it someday, with or without Torproject's nod. All it takes is documentation regarding assembling the already existing opensource tools. Some people I've talked with are more than tempted to do it. Only reason not is simply because they're on other projects at the moment. > This is a hot topic, with good arguments on both sides. However, I feel > that until someone launches such a service, we will not know which way it > would go. Perhaps we need to branch off a new Tor network that is used more > exclusively for hidden services, in hopes of encouraging people to run a > router (non-exits only) without the risk of getting harassed because of > "abuse" complaints. Why branch when scaling may be more useful and secure? Why not ship clients that provide a minimum bandwidth non-exit relay by default? I seriously doubt that's going to get anyone jailed or kicked. And it's not like you can't stick an install popup in there that frames it right: 'the client provides bw to the net by default. it's safe because all traffic through your box is encrypted and onioned. yet if you are not permitted to run a network service or don't want to be known as providing bw, clicky here to turn it off'. At least that way when the masses figure out how to assemble the aforesaid tools, the TorNet will have bandwidth that grows as more join. Even if that growth isn't enough to cover them, it's still something. Because right now, every new user is a pure drain on TorNet, and that's a bad situation to be in. Even if it happens to be self limiting as a side effect :-) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: What can see a server of a Bittorent when I contact with it through Tor?
> > a) You do all operations in Tor... NO use of exit relays, in other words, > > entirely in onionspace. The smart reader will already know how to > > configure this :) > > Well how exactly would you accomplish that? You could put the tracker > on a location hidden service, that eliminates one exit node, however, > to connect with other hosts in the swarm, you need to be able to > connect to them... which means now, you have to have every bittorrent > client in the swarm ALSO running a location hidden service, lest you > need exit nodes to contact them. Right, no exits needed or desired. So? And? That is not a problem as I see it. People complain about mafiaa and all manner of things, so just forget about using exits at all and bury all operations underground in tor, i2p, phantom, anonet, etc. Economies of scale will happen eventually. > I highly doubt any bittorrent client yet supports operating in this > manner. It would be very cool to see... but... there would be some > hurdles. (should each node in the swarm publish a public rendezvos > descriptor? If not a custom client would be needed to set them up and > distribute them via the tracker rather than the public directories) Bidirectional onion2onion works fine with middleware tools. No need for torrent or other apps to be aware of, or manage, onion addressing, or be aware of the Tor client daemon or otherwise. Run middleware, run app, enjoy. > > b) You give back 6x the bandwidth you use in the form of a relay > > set up to provide that much bandwidth. > > Kind of arbitrary but, seems like a reasonable guideline for anyone > who wants to be sure that they are giving back. It is not arbitrary. If you send a meg from onion2onion it traverses six hops. Same if you receive one from one. That is the minimum cost of doing business on Tor, in the onion2onion case of course. > The HiddenTracker is a bittorrent tracker put behind a Tor hidden service > (but it seems to be down right now) That is good start. There is another one online soon I think. Clients can always ask a configured list of trackers plus those in the torrent, so it doesn't matter. > BitBlinder attempts to create a closed Tor-based network for bittorrent > traffic, including a system attempting to assure equal sharing. It may end up being ok. But never I understand why create a separate Tor universe. Sure, if want to only do torrent. But that is may not usual case and steals resources that could be better put to use making the one single tor universe bigger. You have to run a relay with their system so everybody may as just well run one within the single Tor universe. I question registraton and possible future commercial motivations. Given client's pki, registration should not be needed, just run the client and use pubkey as self register/track/accounting somewhere. And there will be major scale issues to solve, why not cooperate and do that under Tor namebadge as well. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: What can see a server of a Bittorent when I contact with it through Tor?
I don't think there's much of anything wrong with using Tor for bittorrent provided: a) You do all operations in Tor... NO use of exit relays, in other words, entirely in onionspace. The smart reader will already know how to configure this :) b) You give back 6x the bandwidth you use in the form of a relay set up to provide that much bandwidth. Sure, there's some additional cost in circuit overhead, but not much. (b) is the real problem, not many would be users wish to, know how to, or have the bandwidth to give back, so they don't, and Tor slows down, so Tor has to anti-advocate using Tor for this purpose. Solve (b) and (a) goes away as the services in onionspace increase. Stay tuned :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[OT] Anonymous credit cards
Thought this topic might come in handy as well. Discuss those cards not requiring positive ID or any real world data verification that the service depends upon. And whether they're refillable or not, balance limits, shipping addresses, etc. These sorts of cards also make great gifts as the purchaser is not tied to the recipient's usage. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Prepaid Cell Data Plans (was: Mobile Tor stuff)
> T-Mobile has 3 prepaid plans: "Pay as you go", "Pay by the day", and > "Flexpay". > Anyways, I thought I should report on all this research. I've been > waiting so long for the day when I could walk into a store, give > someone some money (hell, any amount!) and get ... access. You have > no idea how many times I've walked into stores prior to this year and > tried to give someone a bunch of cash, only to have them tell me my > money was no good there because I wouldn't let them xerox my ID, run > my SSN and sign a contract. I've been doing some prelim on this too. I can buy a t-mo prepaid voice cell for $20 and activate it fully anonymously on pay-go or pay-day plan. They don't even ask for a name, which I think is awesome and totally inline with what a business should be, providing a good/service without hassling the consumer for anything unnecessary to that end. However, when I inquired about flexpay, every place I asked wanted positive ID [self-serve purchase and activation was not available] and they required a credit card as the only means of refill... not store bought minute/refill cards. I wanted flex-pay because the minutes were much cheaper. Are you saying you've found flex-pay does NOT require these things any longer? That would be good news to me. My minute usage was nearing the Boost and Virgin $50/mo unlimited zone. Boost had gsm phones. Virgin had what appeared to be non-gsm phones. I've not switched to either yet. The other carriers voice plans were not competitive with the above three. I think it's important when people talk of this subject to also specify: - Requiring real credit cards vs. anonymous debit cards [refillable or not] - Positive ID / verified real world data [mailed bills, etc] vs. supplying random data that is never checked. Also, I've run into prepaid 'no-contract' 'plans' from various providers that were two sided. One plan was more expensive and could use store bought refill cards. The other less expensive one required a 'credit card'... typically on file, not just on customer demand... as the only means of refill. You can see this if you detail the kiosks/flyers at any Walmart, Target, Kmart, etc. Thank you for starting this topic! Although it's not necessarily directly related to Tor, it certainly is of interest to Tor users, for exactly the same good reasons that Tor is of interest. I hope others can pitch in with their experiences pursuing anonymity with various carriers. I do think the USA is finally beginning to catch up with the rest of the world in this area. Provided no draconian ID law is enacted, it will continue to be a win for consumers and business. Consumers like simplicity and freedom, and a business that provides agressive service to that end will prosper. Hopefully the days of contracts and ID's preventing giving your phone away to others or switching to more suitable services are ending. > Or, if you prefer to send all of your data to the NSA[1,2], AT&T now has Certainly it's safe to assume that, by cooperation or otherwise, various agencies already have said access to all Tier-1 providers. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [Kraut] inquiries from law enforcement authorities
> Thanks for your stats Olaf, intresting and sad to see that there sue peoples > for no good reason. In your case it's really a abus to become 7 inquieres in > less 2 months :/ Yeah, they're just doing due diligence though. This is actually good news. Because after at least seven inquiries, the exit operator is still: - alive - free - has all his computer gear - quite possibly friends with his regular inquisitors, and though perhaps still marked as a freedom loving loon to watch, is fun to drink beer with his nations finest of forces :) I'm curious to know what exactly do 'inquiries' entail in different countries? Phone calls, visits, temporary arrest, ISP shutdowns, raids, email, data preservation, court process/cases, etc. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: client bug in 0.2.2.7-alpha and a new bad exit: exoassist
Since I doubt the suggested tests were performed, I did the work instead. I reached the 'up' website, and timed out on the 'down' one... both as expected. And I diffed the clearnet and tornet versions of the 'up' one and they matched, sans 'alteration'. If one can prove exo is the site with the cache, and that it's also configured improperly, this case might have more merit. Can people tell me which of all the websites they surfed today had a cache somewhere between their browser and the site httpd? Did one block all those internet paths on a whim against caches? Is TorProject going to test all exits to examine for potential caches in the path and flag them all for similar reasons? And what exactly does one propose to do about all the caches and other proxies it can't detect because they happen to be more transparent? I highly think not, on the former three accounts. And 'oops, policy failure' on the latter. Some cache in the path in question is ejecting a harmless and indeed rather useful error message. One that even caught a bug in Tor. Users are free to block exo in their config, or not. In the grand scheme of things, I'd suggest it's a waste of time. > security breaches So now caches are a security breach too? That's news to me, lol :) It's up to torproject now. Happy Tor'ing as always :) And since I'm sure someone will bring up headers somewhere in all this mootness, here's a few of those too :) GET / HTTP/1.0 Host: www.freebsd.org HTTP/1.0 200 OK Content-Type: text/html Accept-Ranges: bytes ETag: "xx" Last-Modified: Tue, 02 Feb 2010 13:45:19 GMT Content-Length: 20987 Date: xxx, xx Feb 2010 xx:xx:xx GMT Server: httpd/1.4.x LaHonda X-Cache: MISS from fra1-proxy2.bbw.net.au X-Cache-Lookup: MISS from fra1-proxy2.bbw.net.au:3128 Age: X-Cache: HIT from proxy2.hbt.bbw.net.au X-Cache-Lookup: HIT from proxy2.hbt.bbw.net.au:8080 Via: 1.0 fra1-proxy2.bbw.net.au:3128 (squid/2.7.STABLE3), 1.0 proxy2.hbt.bbw.net.au:8080 (squid/2.7.STABLE3) Connection: close www.fibrlink.net 125.96.255.23 router exoassist 59.167.207.19 proxy1.bbw.net.au > proxy1.hbt.broadbandwireless.com.au 203.22.23.9 www.freebsd.org 69.147.83.33 www.sadf239csksd93.org [not found] *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: client bug in 0.2.2.7-alpha and a new bad exit: exoassist
> passed the name to the exit node for SOCKS name-to-address resolution Oh, I see, I missed that. For a sec I was thinking it was httpd griping about Host:. > b) "exoassist" is a bad exit that inserts a web page into the stream returned > to the client when a connection cannot be made. > >That site is in Australia. And considering that that url is down right > >now, and that they're fronting it with squid, who knows what all's > >pooched on their end. Before declaring exo hosed, try it when they're > >back up and by using mapaddress instead. > problem is visible when the destination is down. exoassist is indeed > a bad exit. It should be flagged as such, but still is *not* flagged. I don't think this is either a) the case or b) if so, all that troublesome to warrant a flag. That squid proxy is in AU, either resident on, or in the path between, exo and fibr. Exo certainly has the right to run a cache, hell, lots of people's own upstream ISP's do, transparently. And whoever it is is clearly not munging crap with exploits, just throwing a valid error page. Test Exo with one down and one up site, preferably both not in AU. Separately from that, if it isn't Exo running the cache, which from the hostname it appears it's not, then it's not even Exo's fault. Further, Exo has a contact listed, so why not ask them first before declaring them lame. Tor needs bandwidth, and I'd happily take it through a well configured Squid :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: client bug in 0.2.2.7-alpha and a new bad exit: exoassist
> When trying to fetch a web page from www.fibrlink.net, I was surprised to > get an error page back from someplace in Australia, That site is in Australia. And considering that that url is down right now, and that they're fronting it with squid, who knows what all's pooched on their end. Before declaring exo hosed, try it when they're back up and by using mapaddress instead. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: client bug in 0.2.2.7-alpha and a new bad exit: exoassist
> One is in the HTTP(S) header, which can indeed be stripped by privoxy. HTTPS cannot be terminated, stripped and re-encapsulated by privoxy. It passes straight through. I still offer a gold doubloon to anyone who knows of a good unix TLS proxy/munger. One can dream. > tor handles a .nickname.exit passed to it in a unique way Nicknames are not unique. People should be specifying fingerprints instead. ie: fingerprint.exit > technicalities of SOCKS proxies... certain that .exit notation caused errors > from destination servers... it's not a new problem. It's not a socks issue. Until a TLS proxy is available, the most direct 'fix' would be a browser plugin that strips it off the host header when it is seen in the URL... before the browser does ssl on it. The two results would then get stuffed through socks as usual. > Of course some servers aren't running virtual hosts and so don't care about > the "Host: example.com.nickname.exit" header That's why, failing enhancement of MAPADDRESS, keeping .exit around would be handy for clued people... ssh [example.com|10.0.0.69].fingerprint.exit... is much simpler than managing a MAP. Yet unclued people don't know exit can bite them in URLbars, so they complain, so there is desire to kill URLbars to kill complaints from the unclued. Not to mention it isn't a fully capable method to begin with. > Perhaps one of the developers could weigh in on whether Tor itself should be > modifying the Host header It should not, Tor only provides passive transport services, and rightly so. I'm not a dev. And the world is going TLS. So if Tor does anything to 'fix' this, it should enhance the MAPADDRESS functionality as proposed earlier. And possibly provide a friendlier human 'domain2exit selection' interface to it via Vidalia or whatever windows people need. > - it may be moot as .exit notation is deprecated now It is deprecated in your URLbar. But not in the MAPADDRESS function. Exit MAPADDRESSing is still needed given the world's penchant for screwing up how their own services work based on where you're coming from. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Need for sane ISP's?
And what, if any, $USD value per month/ per mbit would such a service have to various people? And why? Perhaps that is what really signifies such a need? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Need for sane ISP's?
Hi. In regard to the current general discussion regarding Tor operators who are getting disconnected for DMCA reports, etc... Is there a need for a 'by the books' ISP/hoster based in the USA? By 'by the books' (btb), I mean... one who isn't just going to kill your node, blog, files, etc... because someone complained and the ISP doesn't happen to like complaints or you... but will just claim common carrier immunity as provided for in usa law. Note that, in the usa, this generally means that if the subscriber does not step up to deal with the issue, that the isp is then forced to act to avoid becoming a conspirator or facilitator... often due to legal verbage in their contracts leading all the way back to the Tier-1's. Except I'm curious to get a handle on whether even that is the real world case... ie: the provider continuing to claim immunity even if the subscriber fails to stand or be reachable vs. the isp losing their pipe because of it. But overall, is there a need for a usa ISP who won't kneel to silly inquiries unless the law requires them to do so. And certainly won't do it because they take some lame moral sides to whatever the issue of the day is. aka: btb. Having one in the usa may not be good in relation to DMCA issues but surely also may be good for foreign entities to safely host what wouldn't be welcome in their own country. But would surely be ok as free speech in the usa. And other variations on this theme. Discussion as to such need? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: AW: tor exit-node abused, takedown by ISP,
> In addition, there is a mailinglist for exitnode-operators within Germany: > http://archives.seul.org/or/talk/Mar-2008/msg00043.html this pointer doesn't really help when the only available list archives strip anything with an '@' in the message as a misguided spamfighting attempt. the address you want is here, and their list has raw, unmangled, archives available via the help system: exitnodes-subscr...@lists.ccc.de *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor exit-node abused, takedown by ISP,
> place a judical complaint on me, plus they charge me quite a lot of > money (around 300$ so far). So I have to convince them that I dealt with And any ISP who treates its customers like this should be shot. Hundreds of $USD just to open a standard ticket and forward some email, that's ludicrous. Umm, yeah, stay away from that ISP, definitely one for the archives. I think the CCC.de may have some help and pointers for you too on the legal/reply parts. I'm sure once this little blip blows over you may have further interest in providing services to any number of anonymous networks, for all the right reasons... albeit from another, more sane, ISP, heh. Thanks for posting and helping out. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor exit-node abused, takedown by ISP,
Infringing Work: 90210 First Found: 21 Jan 2010 xx:xx:xx EST (GMT -0500) Last Found: 21 Jan 2010 xx:xx:xx EST (GMT -0500) IP Address: 188.40.xxx.xxx IP Port: 37278 Protocol: BitTorrent Torrent InfoHash: D1A9A5301B873BB56944F9EA23B23A9C330687ED Containing file(s): 90210.S02E12.Winter.Wonderland.HDTV.XviD-FQM.avi.torrent (367,143,776 bytes) Keep in mind that this also appears to be simply a torrent scrape. Though yes, a hash seemingly indicates content up to 160 bits worth of sureness... they likely never bothered to actually _download_ and compare _anything_, so they wouldn't have any proof of actual infringement in that case. Nor would such a case have any proof of 'making available' unless it actually was available. The user behind your tor node could have been running a fake torrent client, fake data, etc. ...Just in case someone needs more ways to defend against this sort of drivel beyond the common carrier exceptions. Somewhere on the torproject website are some good dmca reply templates. As to whether or not 90210 is even worth the bandwidth, that's another story, haha... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Dir server's rendezvous-service-descriptor's
I was reading these two docs. They seemed to hint that such a thing existed on the authoritative directories. As that seemed where the HS nodes were uploading their descriptors/intro points to. Thus maybe a disk or control port query would exist for such records. Or with some minor source change, could be logged upon receipt. https://www.torproject.org/hidden-services.html.en Step two: the hidden service assembles a hidden service descriptor, containing its public key and a summary of each introduction point, and signs this descriptor with its private key. It uploads that descriptor to a set of directory servers. http://gitweb.torproject.org/tor/tor.git/blob/HEAD:/doc/spec/rend-spec.txt 1.2/1.6 > v2 hidden service descriptors are stored DHT-style on any relays > with the HSDir flag. Right now I count 581 of those relays in the > consensus. Hmm, ok, I think I need to read these specs some more. Well, certainly some of the 581 are untrusted regarding your A) above. Does each one hold a full list of the HS's out there? If DHT, no, it would probably be an even subset distribution. I'd have to read more. I can't imagine that logging each HS onion name received would present any risk to the net. But could provide a handy HS index. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Project infrastructure updates in response to security breach
ok, cool. thx guys. would it make sense to sign the torbutton xpi's? and torsocks? perhaps since it all comes from the same git repo it isn't necessary. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Project infrastructure updates in response to security breach
As I wrote someone earlier... It would be easier to just sign the git revision hashes at various intervals. Such as explicitly including the revision hash that each release is made from in the release docs itself. And then signing that release. That way everyone... git repo maintainers, devels, mirrors, users... can all verify the git repo via that signature. Of course the sig key material needs to be handled in a sanitary way, but still, it's the idea that matters. And git, not svn, would need to be the canonical repo committers commit to, etc. Thanks for Tor. ---I could imagine that they might try to sneak in a commit to the git repository. We have a hook that mails all commits to the mailing list, and we watch that pretty well. But they could disable the hook during their commit. As I mentioned in the earlier mail, the git tree is made up of hashes, so they can't just modify it outright. I've looked over the 'git log' output, and didn't find anything odd. It might be neat to do an automated comparison of "mails that made it to the mailing list" vs "commits to the git repository", if we wanted another layer of checking. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Dir server's rendezvous-service-descriptor's
Is there an archive or a current snapshot of these from any or all of the six servers available? Thanks. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[Relay]BandwidthRate interpretation
RBR is doc'd to be only relay rate + directory requests. Is and if so, where is the client rate limited? Is and if so, where is the HS [onion] rate limited? Is and if so, where is there a distinction made between non-exit and exit rate? And which rate, if any, is the parent rate? Does BR = RBR + OR ? ie: BR >= RBR Does RBR = BR + OR ? ie: RBR >= BR Define: Other Rate = OR, undoc'd rate for client and/or HS [onion], etc. If there is no OR in use at any given time, will the child rate grow on the fly to fill the parent? Will the child get pushed out of the way under the parent cap when the client and/or HS is used? Or put another way, how does client and/or HS usage play with BR and/or RBR? Are client and/or HS only considered a 'node'? Thanks! >From the man page: BandwidthRate N bytes|KB|MB|GB|TB A token bucket limits the average incoming bandwidth usage on this node to the specified number of bytes per second, and the average outgoing bandwidth usage to that same value. RelayBandwidthRate N bytes|KB|MB|GB|TB If defined, a separate token bucket limits the average incoming bandwidth usage for _relayed traffic_ on this node to the speci- fied number of bytes per second, and the average outgoing band- width usage to that same value. Relayed traffic currently is calculated to include answers to directory requests *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay bandwidth needed to pay back Hidden Service usage
>> It may be more proper to think of it as bandwith. Server serves a >> stream 24x7x365 at 100,000bps. User consumes it 24x7x365. > How so? Some people think in terms of bytes transferred [the file case]. Some people think in terms of bandwidth [the stream case]. In either case, the solution to the math problem will be the same. I figured it would be better to think in terms of bandwidth since that is what is actually being configured. > How could someone download a single 100,000 B file non-stop > for a year? I can't answer your question directly because it: - Mixes bytes and time in an ambiguous way. o One file many times? - That yields the bandwidth case. o One file that takes a year to download? - not very possible - Questions the user's motivations. They are immaterial here. > Why should such a user be expected to "pay back" anything? This is purely a math question. The user's motivations are immaterial. Perhaps the user is feeling thankful or benevolent or communal :) > Yes, both the Internet and the tor net can be modeled in this > way. Your point is? Bandwidth on Tor is presumably far more scarce than the commodity internet. Thus relay pipes are more likely to be full. Thus a user has a higher chance of actually negatively impacting the network. For which, given a whim, the same user may wish to ensure his use of the network is given back for others to use. Such that the result is a zero net bandwidth change, just an overall increase in the gross. Maybe it was to show the user's possible thoughts about 'slowness' yielding their ideas as to giving back. Anyways, back to the math... >> the six hop relay system > Six? My mistake. According to the last paragraph here: https://www.torproject.org/hidden-services.html.en it is: 6 relays, 7 hops. CLI - CSR1 - CSR2 - RP * HSR3 - HSR2 - HSR1 - HS I should mention one more thing to assume. That there is actually free bandwidth on the network. Such that all the users give/get the bandwidth they want without contention. But just barely. This simply removes the influence of others from the whole thing. > Sorry if I'm just being dense tonight. :-] Same here, that's why I punted the math question to you all, cuz I'd just futz the answer the way this month's been goin so far :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Relay bandwidth needed to pay back Hidden Service usage
Say a hidden service makes available a 100,000 byte file. Now another user downloads that file. There was obviously some 'cost' in bytes to the six hop relay system for doing that. Say the user who downloaded that file feels obligated to repay his usage back to the system by running his own non-exit relay. How many bytes should he offer back to the network? It may be more proper to think of it as bandwith. Server serves a stream 24x7x365 at 100,000bps. User consumes it 24x7x365. How much inbound and outbound pipe should user provision to replace his usage? When compared to the internet, the network is a closed system with finite resources, so the cost is certainly not equal to his usage [ie: 1x]. His usage causes a depression of overall available resources during the transfer. I thought it might simply be 6x his usage due to 6 hops. But maybe it involves adding 6 increasing fractions? And what about the middle relays that both receive and send the supply stream? Tor overhead and packet retransmissions can be ignored. Tor's configuration limits and the availablity of any given pipe size can also be ignored as this is only an excercise. The return tcp ack stream would not be negligible but could be left out by reference... only if it was simply additive on top of the supply stream using the same calculations. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Avoid TLS renegotiating error on FreeBSD 8.0.Unable to link to parallel openssl libraries.
> wrote: > >I built/installed openssl-0.9.8l on /usr/local/ssl/ > the tor configure script when run recognize according the messages > this openssl > (I used the configure option --with-openssl-dir=/usr/local/ssl/lib He implies building it by hand. He needs to remove the trailing '/lib' from his last sentence above when rebuilding tor. The /ssl/ or /openssl/ install hiers are quite annoying historical relics. With luck they will be purged from the net sometime this decade. tmtowtdi. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TLS renegotiating error persists on FreeBSD 8.0 updated.
> In the meantime, I guess we're at a standoff. > "What the fuck, freebsd? Why did you break a system library?" Until FreeBSD updates their base, include a note in the source release build docs in big block letters: BUILDING TOR ON FREEBSD... That caveat and instructions would hopefully register with builders and quiet this list a bit. I certainly wouldn't modify tor to accomodate freebsd base unless it actually improves tor and is not a kneeling kludge. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TLS renegotiating error persists on FreeBSD 8.0 updated.
> (when I no more could use tor) You need to update openssl. Check the list archives for this month about how to successfully do that using either canonical sources or freebsd ports. > Right. Unfortunately, it seems that FreeBSD patched openssl in such a way > that it is entirely impossible for any application to enable renegotiation. > I believe that Tor will update eventually, but this > might take a substantial amount of time. No. Tor really has no need to update. It is obviously FreeBSD that needs to update its base openssl to 0.9.8l. Their base is still in kneejerk patch mode that everyone else was in before 0.9.8l came out. Please post your base openssl update request to freebsd-stable. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Still problems with TLS negotiation
> However, if one installs openssl from the ports tree, it will be > version 0.9.8l instead. > It is not necessary to link with static libraries. Here is an excerpt It example of isolating everything as proof current tor and ssl is ok and as alternative build concepts. Static can be useful for those who want simple... say drop just one binfile in a chroot, jail, etc. > I'd like [app x] to use zlib compression when connecting to [svc y]. > openssl in base doesn't support zlib. I installed openssl port from package > (in the port zlib in on by default) Tried compiling ssl with oppurtunistic zlib a while back, no go. Must go see how fbsd does it, this is cool news to me! Thx. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Still problems with TLS negotiation
FreeBSD RELENG_8 20091229T1432 works fine from current sources:
openssl version -v -p
OpenSSL 0.9.8k 25 Mar 2009
platform: FreeBSD-i386
mkdir tor ; cd tor
tar -xf /.../openssl-0.9.8l.tar.gz
tar -xf /.../libevent-1.4.13-stable.tar.gz
tar -xf /.../tor-0.2.1.21.tar.gz
c () { /usr/bin/env - PATH=/usr/bin:/bin:/usr/sbin:/sbin /bin/sh -c "$1" ; }
cd openssl-0.9.8l
c './config --prefix=$(realpath ..) no-sse2 shared enable-camellia'
c 'make depend ; make ; make install_docs install_sw'
cd ..
cd libevent-1.4.13-stable
c './configure --prefix=$(realpath ..) ; make ; make install'
cd ..
cd tor-0.2.1.21
c 'CPPFLAGS=-static LDFLAGS=-static ./configure --prefix=$(realpath
..) --with-openssl-dir=$(realpath ..) --with-libevent-dir=$(realpath
..)'
c 'make ; make install'
cd ..
./bin/tor
...
Jan 02 xx:xx:xx.xxx [notice] Bootstrapped 100%: Done.
Tor should be made to emit both the libevent and openssl version
strings upon startup.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: doesn't take long for the dmca's notices to start rolling in..
try searching for privacy free speech no logs webhosting or something like that. there were two companies i found in the usa while researching a couple years back that offered it. they were a bit pricy due to the manpower needed to fulfill their obligation to shuffle various legal process around. if you are doing legal stuff, even if it's unpopular, they can be a good home. > If I limit my exit ports to http(s) and ssh; would that pretty much stop the > torrenting? Probably. But people can still publish to say rapidshare with that. And cause various mayhem. You're working through it with your provider to find a solution so that's always a good thing. > Or does anyone know a good vps hosting company they can point me too? > One that isn't racked in the FDC DC? however no company will defend their users from doing illegal things. unless they also get a kick out of taking promising cases up to the supremes as some sort of masochistic revolutionary fun. the companies above accepted anonymous payments. many around the world do that. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TOR and ISP
> On the contrary, in the United States, all ISPs are *required* by > statute to record all URL requests that can be detected passing from their > customers through their equipment. False. ISP's in the US don't have to record any information of any kind about their user or their data whatsoever. None, period. Nor are they required to give it to anyone except under legal process [subpoena, court order]. US ISP's routinely lobby against recording anything because the time, capital and recurring cost to them to do so is precisely that, pure cost, no profit. Any information they record is usually related to generating metrics so that they can make more money. However, lately, all that has been flipping on it's back, now many are recording as a feel good or pressure measure, 'Hey, I'm a spiffy "patriotic" company, I helped law enforcement bust a terrorist 9yo kid today. Yay :) Please count me in as a good guy and don't put me on your watch list ok.' Any data they do happen to have on hand is of course subject to process. > norms... against the ISPs reminding users that ISPs have this ability. :-) True. There is also the CALEA system, the result of which is that pretty much every phone switch in the US is remotely tappable. Internet gear is the next obviously logical step for that joint, partly required, partly offered, effort. > I doubt that they provide this information > to private individuals, and doing so may well be prohibited by ECPA True. Including other acts... wiretap, fcra, blah and etc. Such acts in some cases require those that have data about you to disclose it back to you on request. Or to others at your explicit direction. But that's usually only in the finance and medical sectors. > but they > can be required to submit their logs of this information to statute > enforcement agencies. Only if such 'requirement' means court order. They can give it to whoever they want, provided they don't care about the possible legal repurcussions of doing so. ie: AT&T etc obviously have a 69 position with the gov't going back to the days of Western Union, so they don't care. > The key here is that the ISPs not only cannot detect encrypted URLs, The ISP only knows that the user is using Tor. And as always, it is best to assume your adversary knows far more than you think... and to plan your strategies accordingly. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
