Re: Is gatereloaded a Bad Exit?
2011/2/14 Julie C ju...@h-ck.ca: If this BadExit policy is being made up ad-hoc, that's fine by me. If the offending Tor node operators want to stand up and defend themselves, or their choices, that's fine too. So, I as a Tor Node Operator now have to defend myself, because it's a priviledge to run a Tor node, not a service to the community? Guys, whats up with you? morphium *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 2/15/2011 5:00 AM, morphium wrote: 2011/2/14 Julie Cju...@h-ck.ca: If this BadExit policy is being made up ad-hoc, that's fine by me. If the offending Tor node operators want to stand up and defend themselves, or their choices, that's fine too. So, I as a Tor Node Operator now have to defend myself, because it's a priviledge to run a Tor node, not a service to the community? Guys, whats up with you? I hate to continue a clearly dead-end argument, but have you ever volunteered, well, *anywhere*? If I were, say, volunteering to build houses for the homeless, and I started going off on my own, ignoring all guidelines, and hammering around wherever the fuck I wanted, I'd expect to either be asked what the hell I was doing (and allowed to continue given good reasoning), or be booted off the project. I have my reasons for doing this, trust me is not good enough. The same logic applies to nearly any volunteer or community service situation you could get yourself into. You wouldn't be allowed to re-arrange books at a library without explaining yourself, just as you shouldn't expect to run a broken- or malicious-looking Tor node without a heads-up to the community. Running a node is indeed a community service; however, all community service requires some degree of responsibility. If you're really in a position where such a responsibility would endanger you (or you're simply defiant to the point of rebelling against responsibility when you're told it's expected of you), then yes, I expect you to be limited to the safe zone of being a middle node until you explain yourself or grow the hell up. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Monday 14 February 2011 18:11:42 Dave U. Random wrote: SHUT UP EELBASH! I'm not eelbash, nor do I know who eelbash is (I've heard rumors that eelbash is wormcast, but I don't remember what that was about, it was years ago). *** 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 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, let the
Re: Is gatereloaded a Bad Exit?
So, with everything said, could we now please Un-BadExit the nodes that were affected? Thanks! morphium *** 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?
Thus spake morphium (morph...@morphium.info): So, with everything said, could we now please Un-BadExit the nodes that were affected? Sure, dude. Since you've read everything that was said, I take it you're volunteering to contact the other node operators and ask them to give reasons for why they chose their exit policy? Let us know their preferred email addresses when you're done. But they'll have to survive a challenge and response round proving they can modify their contact info field ;). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgprFx9XcJnz7.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Am 14.02.2011 14:41, schrieb morphium: So, with everything said, could we now please Un-BadExit the nodes that were affected? the whole discussion didn't change my mind. I still support the idea of flagging them as bad exit. regards Olaf *** 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?
the whole discussion didn't change my mind. I still support the idea of flagging them as bad exit. Same. Mike gave some good reasons for flagging them weeks ago and I've yet to see much else besides ranting that seems to ignore most of this thread. -Damian *** 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?
Sure, dude. Since you've read everything that was said, I take it you're volunteering to contact the other node operators and ask them to give reasons for why they chose their exit policy? So please BadExit all nodes without contact email, if they don't explain why they chose the default exit policy, I think they should be blacklisted! Thanks! morphium *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, 2011-02-14 at 14:41 +0100, morphium wrote: So, with everything said, could we now please Un-BadExit the nodes that were affected? Sorry, but this has been a long thread and I want to try to make sure I understand something important. Is it true or false that traffic was actually exiting through gatereloaded et all? I recall seeing that those nodes weren't marked as exits in the consensus anyway. If that is the case, then all of John Case's arguments related to super-secret movie-plot usages of Tor and servers running on port 80 only accessible through gatereloaded et all seem to be irrelevant. signature.asc Description: This is a digitally signed message part
Re: Is gatereloaded a Bad Exit?
On Mon, 14 Feb 2011, morphium wrote: Sure, dude. Since you've read everything that was said, I take it you're volunteering to contact the other node operators and ask them to give reasons for why they chose their exit policy? So please BadExit all nodes without contact email, if they don't explain why they chose the default exit policy, I think they should be blacklisted! No, it goes further than that. The real motion here is to BadExit all nodes that aren't being used and deployed exactly like I deploy mine. When the dust settles, could we get the official threat model, and the official end user profile and the official use case documented ? Again, for the lulz. *** 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 suppose the anarchist genes in me are not strong enough. I have to agree with Mike Perry's arguments, given his credibility, and his clearer perspective than most of the rest of us. If this BadExit policy is being made up ad-hoc, that's fine by me. If the offending Tor node operators want to stand up and defend themselves, or their choices, that's fine too. -- Julie C. ju...@h-ck.ca GPG key FF4E2E70 available at http://keys.gnupg.net On Mon, Feb 14, 2011 at 9:44 AM, John Case c...@sdf.lonestar.org wrote: On Mon, 14 Feb 2011, morphium wrote: Sure, dude. Since you've read everything that was said, I take it you're volunteering to contact the other node operators and ask them to give reasons for why they chose their exit policy? So please BadExit all nodes without contact email, if they don't explain why they chose the default exit policy, I think they should be blacklisted! No, it goes further than that. The real motion here is to BadExit all nodes that aren't being used and deployed exactly like I deploy mine. When the dust settles, could we get the official threat model, and the official end user profile and the official use case documented ? Again, for the lulz. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, 2011-02-14 at 17:41 +, John Case wrote: On Mon, 14 Feb 2011, Ted Smith wrote: Sorry, but this has been a long thread and I want to try to make sure I understand something important. Is it true or false that traffic was actually exiting through gatereloaded et all? I recall seeing that those nodes weren't marked as exits in the consensus anyway. If that is the case, then all of John Case's arguments related to super-secret movie-plot usages of Tor and servers running on port 80 only accessible through gatereloaded et all seem to be irrelevant. And therefore will always be irrelevant, never affecting a single ToR user into the infinite future. Is there an or-parliament list I should be on if I want to be an Official Tor Project Legislator, making these *important policy decisions* that affect Tor into the *infinite future*? I know it's easier to send emails about something incredibly unimportant to inflate one's own ego than it is to actually get shit done, but this is ridiculous. signature.asc Description: This is a digitally signed message part
Re: Is gatereloaded a Bad Exit?
On 2/14/2011 7:48 AM, grarpamp wrote: [snip] If another example is needed, not that one is; Corporate, edu and other LAN's sometimes think they can block 'ooo, encryption bad' ports so they can watch their user's plaintext URL's with their substandard vendor nanny watch tool of the day. All the while their staff laughs at them as they happily tunnel whatever they want over that (perhaps even the client or exit parts of Tor). Yes, this kind of joke exists :) [/snip] Although I've been keeping out of this argument for the most part, and even though I'm leaning towards seeing things Mike's way, I just wanted to comment that I've actually been in an environment like this several times, once at my previous university, and once working for a local government organization. As asinine as such reasoning is on the part of the network administrator (or the person who signs their checks), I can see why the *ability* to run strange exit policies could be a good thing, and should be preserved in the software. However, I see no reason why providing an anonymous contact email would be so hard. Certainly if you're going out of your way to avoid [insert conspiracy of choice] in order to run a node, you have the skills to use one of the hundreds of free email services out there? I don't think asking for a tiny bit of responsibility on the part of exit operators is too much to ask, and I'm amazed that allow them to continue to function as middle nodes until they explain why their node appears broken or malicious is continually being turned into some kind of human-rights violation. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Monday 14 February 2011 14:17:45 Aplin, Justin M wrote: However, I see no reason why providing an anonymous contact email would be so hard. Certainly if you're going out of your way to avoid [insert conspiracy of choice] in order to run a node, you have the skills to use one of the hundreds of free email services out there? I don't think asking for a tiny bit of responsibility on the part of exit operators is too much to ask, and I'm amazed that allow them to continue to function as middle nodes until they explain why their node appears broken or malicious is continually being turned into some kind of human-rights violation. Or even better, create a nym using remailers. This does take some maintenance, as if one of the remailers goes down, you have to make a new chain of remailers for the nym to work, but it's more secure than a Yahoo/Hotmail/etc. account. cmeclax *** 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?
Hello Julie, On Mon, 14 Feb 2011, Julie C wrote: I suppose the anarchist genes in me are not strong enough. I have to agree with Mike Perry's arguments, given his credibility, and his clearer perspective than most of the rest of us. If this BadExit policy is being made up ad-hoc, that's fine by me. If the offending Tor node operators want to stand up and defend themselves, or their choices, that's fine too. Great. What's the acceptable companion port to 119 ? How about 6667 ? Since these ports, like 25, have no standard companion (like 80/443 typically does) what collection of encrypted ports need to be maintained to balance out running 199/6667 ? Come on people - I thought there would be quick answers to all of this... RE: clearer perspective - it's easy to have a clear perspective when you discount all possible use cases that aren't what I do. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 2011-02-14 John Case wrote: Where's the answer to this ? I chose edge-case scenarios above, for sure, but this is the real meat of the implementation of your plans, and I'd like to know if you've given any thought to this whatsoever. What _is_ the proper corresponding open port for 25 ? What _do_ you find an acceptable match for 53 ? What system of weights will you give ports that don't have an obvious correlary ? Oh, by the way - I used TCP port 80 this morning for something other than cleartext HTTP. You've already made perfectly clear that you don't get the point. Can we now stop beating the dead horse? Thank you. Regards Ansgar Wiechers -- All vulnerabilities deserve a public fear period prior to patches becoming available. --Jason Coombs on Bugtraq *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, Feb 14, 2011 at 4:32 PM, John Case c...@sdf.lonestar.org wrote: Hello Julie, On Mon, 14 Feb 2011, Julie C wrote: I suppose the anarchist genes in me are not strong enough. I have to agree with Mike Perry's arguments, given his credibility, and his clearer perspective than most of the rest of us. If this BadExit policy is being made up ad-hoc, that's fine by me. If the offending Tor node operators want to stand up and defend themselves, or their choices, that's fine too. Great. What's the acceptable companion port to 119 ? How about 6667 ? Since these ports, like 25, have no standard companion (like 80/443 typically does) what collection of encrypted ports need to be maintained to balance out running 199/6667 ? Come on people - I thought there would be quick answers to all of this... RE: clearer perspective - it's easy to have a clear perspective when you discount all possible use cases that aren't what I do. Here's an argument tip: When you think you've spotted some enormous hole in the other side's argument, there is at least a small chance that you're actually instead spotted a hole in your understanding of their position. You should probably take a moment to reflect and make sure you're confident that you know where the error is before hitting send. I refrained from answering this the first time you asked it because I thought if I gave you more time you might realize that it wasn't really a useful question. No one has suggested every unencrypted port must be matched. There are some very clear matches which do exist (e.g. HTTP/HTTPS) and for those matches action can be taken. Nothing requires anything to be done about all the other cases where such nice and popular parallels are not obvious or where the protocols are unpopular enough to begin with. HTTP is an overwhelming popular port, and there really isn't anything wrong with special casing _just_ that, if thats all that it ever came to. Your examples aren't the best though, SSL SMTP is on 465— and it's probably common enough that a similar rule could be enforced if anyone cared. IRC ports aren't all that consistent even without the introduction of security, so there isn't much that can be said there. [snip] and people that need this are in literally life or death (or at least free or jail) situations Then they need to not run an exit. If running an exit is probably going to get you killed or put in jail you should not be running one. If you're right and the decision to allow wacko exit policies discourages people with their life on the line from running exits, then I could imagine no better policy. *** 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?
Hi Geoff, On Sat, 12 Feb 2011, Geoff Down wrote: There are a small number of easily identifiable cons to letting an exit run like this, and there are an unlimited number of unknown pros to letting an exit run like this. You should know this. Leaving aside the original question of whether to BadExit GateReloaded, I'm afraid this argument is without merit. A rational decision can only be made on the basis of that for which you have evidence. There will always be an infinite number of things for which you have no evidence, but which you can imagine. Your argument appears to be equivalent to Pascal's argument for worshipping God - which has always been open to the rejoinder which god, worshipped how?. Until you can quantify the pros, it is only rational to behave on the basis of the quantifiable cons. That's fair. Instead of stressing the boundless set of pros, I will discuss a single, specific pro, and that is the idea that open, arbitrary systems provide a foundation upon which to build surprising and unexpected combinations. I wouldn't think that a group of technical people, much less a group of technical people immersed in network architectures would need this explained to them. Then again, I didn't think we woud be referring to /etc/services as hard, physical laws, either. You live and learn, I guess. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, 31 Jan 2011, Andrew Lewman wrote: In my opinion, judging a relay based on exit policy is a slippery slope we don't want to go down. We never claim to make using Tor alone safer than using the Internet at large. Whether the creep is at Starbucks sniffing the wifi or running a relay is irrelevant to me. Encouraging people to use encrypted communications, the https everywhere firefox extension, and learn to be more secure online are some of our goals. The Tor Browser Bundle, while still a work in progress, is the best way to protect novice users and get them safer than they are without Tor. Yes, this is the obvious, sensible response. Since this come from someb...@torproject.org, can I assume the adults have spoken and I can move on ? Or are we still trying to convince people that they might not know what every possible use of ToR is, and looks like ? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, Feb 12, 2011 at 5:35 PM, John Case c...@sdf.lonestar.org wrote: That's fair. Instead of stressing the boundless set of pros, I will discuss a single, specific pro, and that is the idea that open, arbitrary systems provide a foundation upon which to build surprising and unexpected combinations. I wouldn't think that a group of technical people, much less a group of technical people immersed in network architectures would need this explained to them. Then again, I didn't think we woud be referring to /etc/services as hard, physical laws, either. You live and learn, I guess. This argument has fallen on deaf ears because in isolation it produces nonsense results. That it is continually pressed while the substantive arguments required to actually make a decision are ignored by the people promoting this view makes them look like fanatics, at least in my eyes. (And I was happily ignoring the thread until someone commented that they had be swayed by the continued arguments, which I'd not been bothering to refute) If we were to take this argument openness/flexibility argument as hard doctrine why would we not provide a facility for Tor to execute arbitrary code shipped over from arbitrary users? That would make tor a truly open, arbitrary system. Of course we don't do this because it's highly insecure and no one would run a tor daemon which did that. So in practice we must weigh the benefits of the speculative features mobile code many provide vs the costs of turning tor into a opensource botnet, and in _this_ analysis the openness argument provides little input, because it's the _specific_ consequences of the decision which determine the best outcome. The pro you're proposing is not useful as a _specific_ pro, because it fails completely as a specific _pro_ as the absolute majority of the infinite number of arguments I could make under it would actually be really bad ideas: It doesn't really do much to accurately separate the space of ideas into good and bad ones— especially in the domain of security a lot of bad software is bad because it was too flexible for the wrong users. Flexibility is also sometimes mutually exclusive and what you exclude (no buffer overflows!) can be as much of a feature as what you include (run arbitrary code!). As Geoff points out— this class of argument is fundamentally a pascal's wager. Which God? Worshiped how? Which flexibility? Implemented at what cost? I grant that flexibility is a useful general principle, but one so general that it would never be useful in making a decision by itself. Not a specific benefit. For example, I'd use the flexibility to say that this policy should not be implemented in every single client, which take forever to upgrade, but instead should be signaled via directories— so that the decision could be change quickly and easily. So back to the case in question: We must look at the cost of excluding an infinitesimal piece of flexibility (the conceivable uses of four non-exit flagged exit nodes, is I believe what this policy would impact today), vs a tiny piece of social policy (if you want to run an exit node to :80, you're going to allow it to exit to :443 as well or no one will use it, thus subsidizing port 443 capacity on the back of port 80 capacity) and decreased incentive for tor users to run personal exit filters (which would result in network partitioning and reduced anonymity for everyone if widespread). Like my botnet toy example, — the more flexible system would be preferred all things equal, but all things are almost never equal and so we fall to the simple balance of specific benefits. And it's very difficult to argue for specific benefits resulting from permitting nodes to exit to commonly non-encrypted ports while rejecting their commonly encrypted counterparts, while the specific benefits of rejecting these nodes are easily explained (if not all that significant). One of the side effects of the suggestion of this policy which I was not expecting is that it caused some participants on this list to expose their previously held mistaken belief that the Tor network's technical inability to prevent exit sniffing was actually an explicit approval of this unethical and probably unlawful activity. To the extent that policy which is overtly sniffing hostile, if actually ineffectual at preventing any sniffing, makes it more clear that this activity is considered regrettable and not permitted then that can only be a good thing 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: Is gatereloaded a Bad Exit?
Hello Gregory, On Fri, 11 Feb 2011, Gregory Maxwell wrote: As far as I can tell this is a completely spurious strawman argument. Where is this person with a legitimate reason why they can allow :80 and not :443? What is their reason? I am trying to suggest two things here: 1) We cannot know the answer to this (what is their reason, what is their scenario, what is their threat model) 2) There are uses of ToR, and roles that ToR plays, that are very, very different than the official, accepted use model. So let me back up one step here and state some things that I am sorry are not obvious: - you have no idea what kind of things run over ports like 21, 23, 80, and 110. I know what _I_ use them for, and you know what _you_ use them for, and we know what's in /etc/services, but you are forgetting that anything can run over a TCP port. - you have no idea what particular network activity, or services provided, is considered suspicious in a particular setting. _I_ can run services on arbitrary ports and so can you, and so can most anybody, but you are forgetting that there are threat models wherein this is not the case. - you have no idea what type of overall architecture someone has fit their ToR use into. _I_ use ToR in the typical, accepted fashion, and so does most everyone else, but perhaps ToR is used as simply one component, and maybe not even the most important component, of a larger network architecture. - you have no idea what the overall goal of sending and receiving traffic on the ToR network is for a person or group. _I_ use it like you do, to perform normal Internet functions anonymously - but others may have very different needs, ranging from simple traffic generation to plausible deniability. What frustrates me so much about this whole conversation is that the above items (and we could all come up with many more) are true in general, but are never more true than they are related to ToR. Further, since we're all technical people here, it should be second nature to us that the POWER of an open system are the arbitrary combinations that arise from a simple, unrestrictive ruleset. There are a small number of easily identifiable cons to letting an exit run like this, and there are an unlimited number of unknown pros to letting an exit run like this. You should know this. If anyone was showing up expressing this as a serious constraint with a legitimate cause, then it might be reasonable to reconsider. Certainly if there were many of them. I am suggesting fringe, and possibly temporary use cases that imply actors that probably aren't going to pop in to talk shop. I'll say it again: There are a small number of easily identifiable cons to letting an exit run like this, and there are an unlimited number of unknown pros to letting an exit run like this. You should know this. Tor already has a great many tweaks and heuristics. Why are you not complaining about the exit load-balancing heuristic that denies the exit flag to nodes which don't exit to at least a /8 of several important ports? It impacts a great many more nodes. Or why not complain about the countermeasures against one hop usage that make nodes seizure targets and takes an unfair share of the bandwidth? Forgive me, but this is a near-perfect example of a straw man logical fallacy. My not protesting these other items (which I may or may not support) does not suggest that my above argument is faulty. Will this contingent next be advocating not blacklisting exits known to insert malware or advertisements in the traffic because without this activity the exit operator can not afford to keep their exit going? If running an exit is somehow so imposing on someone that they feel the need to impose bizarre (even inexplicable) restrictions on its behaviour then they really should be helping the tor network in some other way — by running a bridge or a regular middle node. Or finding something else to do with their scarce resources. Tor needs people's help, sure, but it doesn't demand their blood. Why not let the rich white people in the north that you seem to have so much disdain for take a larger part of the exit burden? Again, you are limiting your view to free people who are donating resources for the world. Yes, that is how I am involved in ToR, and how you are involved in ToR, but you completely discount the people running ToR nodes on the other side of the sword, so to speak. They're not in it for you and me, and they're not in it for the EFF - they have an immediate communications need that has both purpose and constraints that you and I cannot imagine. I personally run a node with an oddball exit policy (well, it's down at the moment due to a hardware failure). I wouldn't have any issue explaining the exit policy to someone who asked. (basically I have a node that exists to a collection of hand selected 'read only' websites, plus tcp dns to some dns
Re: Is gatereloaded a Bad Exit?
On Fri, 11 Feb 2011 17:44 +, John Case c...@sdf.lonestar.org wrote: There are a small number of easily identifiable cons to letting an exit run like this, and there are an unlimited number of unknown pros to letting an exit run like this. You should know this. Leaving aside the original question of whether to BadExit GateReloaded, I'm afraid this argument is without merit. A rational decision can only be made on the basis of that for which you have evidence. There will always be an infinite number of things for which you have no evidence, but which you can imagine. Your argument appears to be equivalent to Pascal's argument for worshipping God - which has always been open to the rejoinder which god, worshipped how?. Until you can quantify the pros, it is only rational to behave on the basis of the quantifiable cons. GD -- http://www.fastmail.fm - Does exactly what it says on the tin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, 31 Jan 2011 11:30:20 -0500 Andrew Lewman and...@torproject.org wrote: In my opinion, judging a relay based on exit policy is a slippery slope we don't want to go down. We never claim to make using Tor alone safer than using the Internet at large. Whether the creep is at Starbucks sniffing the wifi or running a relay is irrelevant to me. Encouraging people to use encrypted communications, the https everywhere firefox extension, and learn to be more secure online are some of our goals. The Tor Browser Bundle, while still a work in progress, is the best way to protect novice users and get them safer than they are without Tor. I personally run encrypted services on unencrypted ports, like 25, 80, 143, 110, etc. It's just a port number and only convention says port 80 has to be for http only. If people start doing deep packet inspection to enforce 80 is really http or running filters in some misguided attempt to block bad things through Tor, then those are reasons to 'badexit' relays. There are some obvious ways we can detect traffic manipulation through Tor relays. Today, we do detect them and badexit those relays. If we're going to start censoring Tor exits based on impressions, we might as well start blocking Tor relays that are rumoured to be run by national intelligence agencies, criminal organizations, martians, and other people we might not like. In fact, we might as well go back to the original model of every Tor relay operator has met and gained Roger's trust. I want a diverse set of Tor relays. If people don't want to trust relays based on whatever heuristics they want to use, great, use ExcludeNodes in your torrc. Don't punish everyone based on rumors and impressions. Hear, hear! Thank you, Andrew, for putting it so clearly in accord with previously posted policy statements by the tor development team, both on the tor lists and on the tor project's web site. I don't know what triggered Mike's dictatorial moment, but I hope he comes to his senses quickly (if he hasn't already; I confess I'm hundreds of messages behind in my email at present). Your remark about the Roger trusts 'em model does still seem to apply to the assignment of Authority flags. Given the current directory protocol(s) and distribution structure, I'm fine with that arrangement for the time being for Authority flagging, but not for BadExit flagging for the reasons you posted, as well as a few posted by others, including myself. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** 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?
Thus spake grarpamp (grarp...@gmail.com): Exit policy is currently at the operator's pleasure, need and design. If exit policy mandates will help solve some Tor scalability or attack vector issues, in a substantive way, from an engineering standpoint, fine. But please, don't claim it makes users any more 'safe' from sniffing. I've already addressed the rest of your points. For the record, you're just strawmanning here. I never made the claim this was safer. I cited several engineering reasosn why this type of exit policy is a pain for us. I've also made the claim that there is no rational reason to operate an exit in this fashion, other than to log/monitor/censor traffic or because of undesirable network conditions, and no one has disputed that claim. Morphium gave us a reason, even if it was rather petty and irrational, so he won't be getting the badexit flag. But for my vote in the process, any other relay that does not give a reason for this policy, or that can not give us one because of no contact info, will be getting the flag. The same goes for exits that we detect RSTing 443, or censoring 443, or throttling 443, or doing anything else to TLS connections. But I only have one vote out of three. Roger and Peter are free to change their minds. Perhaps we should bring more people on board in this process, too. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpG9O9HmMzFj.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
On Thu, 10 Feb 2011, Mike Perry wrote: Exit policy is currently at the operator's pleasure, need and design. If exit policy mandates will help solve some Tor scalability or attack vector issues, in a substantive way, from an engineering standpoint, fine. But please, don't claim it makes users any more 'safe' from sniffing. I've already addressed the rest of your points. For the record, you're just strawmanning here. I never made the claim this was safer. I cited several engineering reasosn why this type of exit policy is a pain for us. I think these reasons should be worked around or ignored. I think you, and others on that side of this argument have a very, very myopic view of the constraints and non-technical decisions that go into running a particular node - exit or not. Rich white people in the north can just trade some dollars for co-location, exercise their free speech, and argue back at the police, as their equals, when they come calling. That's not the case for everyone - and even in those rich, white countries, there are political and economic ramifications for running a Tor node, exit or otherwise, that seem to have not occurred to you. I've also made the claim that there is no rational reason to operate an exit in this fashion, other than to log/monitor/censor traffic or because of undesirable network conditions, and no one has disputed that claim. No, there is no _technical_ reason to operate an exit in this fashion. There is no reason, from a myopic, borderline autistic view of the externalities involved, to run an exit in this fashion. However, I can think of many, many reasons to: - run a node with no contact information - run a node with an odd set of exits - run a node with plain (unencrypted) exits - run a node with odd (non standard port) exits You have absolutely NO FUCKING IDEA what a node has been deployed for, who is using it, and how many layers of subterfuge are being employed between the external function and the true function underneath. Further, the power of a platform such as ToR is in the arbitrary extension of the base set of capabilities, and many, many different models of subterfuge, trust, anonymity, etc., can then be built - at arbitrary levels of complexity - and you are chopping those off at the knees. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Fri, Feb 11, 2011 at 6:58 AM, John Case c...@sdf.lonestar.org wrote: No, there is no _technical_ reason to operate an exit in this fashion. There is no reason, from a myopic, borderline autistic view of the externalities involved, to run an exit in this fashion. However, I can think of many, many reasons to: - run a node with no contact information - run a node with an odd set of exits - run a node with plain (unencrypted) exits - run a node with odd (non standard port) exits Can you please list some of the reasons for doing all of this at the same time? Since you reply here I assume you have read the posts in this very long thread, and Mike have already countered the given reasons, from a non-technical perspective. It would be nice if you could give an example that have not already been brought up, since you seem to know some. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Fri, Feb 11, 2011 at 12:58 AM, John Case c...@sdf.lonestar.org wrote: I think these reasons should be worked around or ignored. I think you, and others on that side of this argument have a very, very myopic view of the constraints and non-technical decisions that go into running a particular node - exit or not. Rich white people in the north can just trade some dollars for co-location, exercise their free speech, and argue back at the police, as their equals, when they come calling. That's not the case for everyone - and even in those rich, white countries, there are political and economic ramifications for running a Tor node, exit or otherwise, that seem to have not occurred to you. As far as I can tell this is a completely spurious strawman argument. Where is this person with a legitimate reason why they can allow :80 and not :443? What is their reason? If anyone was showing up expressing this as a serious constraint with a legitimate cause, then it might be reasonable to reconsider. Certainly if there were many of them. If you want myopia, you need to look no further than this obsession with some speculative hypothetical universe where someone is going to be gravely injured by the tor network not choosing to use their :80 but not :443 exit. There are a great many ways to contribute to the tor network, so it isn't even as though their contributions are being turned away completely. Tor already has a great many tweaks and heuristics. Why are you not complaining about the exit load-balancing heuristic that denies the exit flag to nodes which don't exit to at least a /8 of several important ports? It impacts a great many more nodes. Or why not complain about the countermeasures against one hop usage that make nodes seizure targets and takes an unfair share of the bandwidth? Why are you not outraged about the hundreds and hundreds of bridge operators who are getting no use _at all_ because their identities are being held in reserve in order to build up decent pools of bridges for use with differentiated distribution? Will this contingent next be advocating not blacklisting exits known to insert malware or advertisements in the traffic because without this activity the exit operator can not afford to keep their exit going? If running an exit is somehow so imposing on someone that they feel the need to impose bizarre (even inexplicable) restrictions on its behaviour then they really should be helping the tor network in some other way — by running a bridge or a regular middle node. Or finding something else to do with their scarce resources. Tor needs people's help, sure, but it doesn't demand their blood. Why not let the rich white people in the north that you seem to have so much disdain for take a larger part of the exit burden? No, there is no _technical_ reason to operate an exit in this fashion. There is no reason, from a myopic, borderline autistic view of the externalities involved, to run an exit in this fashion. However, I can think of many, many reasons to: - run a node with no contact information - run a node with an odd set of exits - run a node with plain (unencrypted) exits - run a node with odd (non standard port) exits I personally run a node with an oddball exit policy (well, it's down at the moment due to a hardware failure). I wouldn't have any issue explaining the exit policy to someone who asked. (basically I have a node that exists to a collection of hand selected 'read only' websites, plus tcp dns to some dns servers, and a number of other assorted things that I know should will be free of complaint generating outcomes) But I don't care that it barely gets used as an exit (due to various technical details), nor would I care if tor changed in a way that would prevent it from it ever being used as an exit. Do you really think that someone who doesn't provide contact information is more likely to care about this sort of thing than me? You have absolutely NO FUCKING IDEA what a node has been deployed for, who is using it, and how many layers of subterfuge are being employed between the external function and the true function underneath. You could employ that same argument against _every_ _single_ technical or policy decision in the design and operation of the tor software and network. It's an information free argument. Ultimately the tor network is _not_ anyone's personal spy-business playground. It provides a real anonymity service to a great many people, and real censorship avoidance to a great many people. If it's also useful for things outside of this, then great, but you don't get to argue in favour of these non-primary uses when you can't even disclose what they are. There are too many real constraints on Tor already for people to worry about imaginary much less unimaginable ones! at arbitrary levels of complexity - and you are chopping those off at the knees. I am greatly disappointed by Tor's failure to steganographically
Re: Is gatereloaded a Bad Exit?
On Mon, 31 Jan 2011 11:09:51 +0100 Olaf Selke olaf.se...@blutmagie.de wrote: On 31.01.2011 10:52, morphium wrote: As I stated above, it's not a good idea to BadExit them, because it puts more load on the servers, that DO support https i.e. - and makes them slower. I disagree Morphium's position mainly for the same reasons Mike and Jake already pointed out. If the operators really care about their nodes they'll certainly contact Tor admins. Damaging Tor's reputation in the public due to exit sniffing imo is much more worse than loosing some bandwidth. I think Mike's and Jake's implied claims of clairvoyance regarding an exit node operator's intentions in writing the exit policy for his/her node call for some supporting evidence. Instead, one of them has already admitted that they have no evidence because they have no way to detect any. And I don't see ANY point in BadExit'ing 5 random Nodes, suggesting that no one could capture your unencrypted traffic now. those five high bandwidth nodes with suspicious exit policies haven't been chosen randomly. Olaf, you run four high-capacity exit nodes, each of which allows unencrypted exits. You have a longstanding capacity record, so it wouldn't be random at all to choose to flag your nodes as bad exits; rather, it would simply be recognizing that you have the ability to sniff a significant portion of all unencrypted exit traffic. To avoid having your four nodes flagged as bad exits, perhaps you should block port 80 and all the thousands of other ports that are usually unencrypted. Now, you might point out that Mike's criterion for avoiding BadExit flagging is that you can continue to do your sniffing of unencrypted exit traffic, provided you also allow encrypted exits on a handful of ports. This is all silliness. 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. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, 31 Jan 2011 11:17:27 +0100 morphium morph...@morphium.info wrote: 2011/1/31 Olaf Selke olaf.se...@blutmagie.de: I disagree Morphium's position mainly for the same reasons Mike and Jake already pointed out. If the operators really care about their nodes they'll certainly contact Tor admins. Damaging Tor's reputation in the public due to exit sniffing imo is much more worse than loosing some bandwidth. Sniffing is worse than loosing bandwidth, right. But sniffing still occurs, we just don't know where. And we can't tell wether they did. I think concluding only 80: he is sniffing is wrong (and even would be 80 and 443: he is a good guy). And if those nodes really are ran by the bad guys, I don't think it's a problem for them now to setup a new node on a new subnet that allows their old ports + 443 and continue sniffing. Exactly, on all points. I can not see the Tor project won _anything_ with this decision. Well, they've made clear that they know what's good for exit operators better than those exit operators do. Perhaps they should arrange ISP choices, contracts, and bill payment methods for those exit operators next? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, 29 Jan 2011 23:23:55 -0800 Mike Perry mikepe...@fscked.org wrote: Thus spake Eddie Cornejo (corn...@gmail.com): I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. =20 Ok, I accept that this might send a message to 50ish nodes (if you ban all 50+) but if someone was so inclined they could still do this by allowing encrypted traffic and throttling it/blocking it outside of TOR (transparent proxy perhaps?) I predict this is worse as the user client will believe node A will honestly relay encrypted traffic and will select it on this basis, only to find their connection is slow or doesn't fully connect. Admitedly, this won't be a huge problem unless a good number of nodes started doing this. We can detect nodes that fail encrypted connections. We currently scan for failure of port 443. We also detect throttling by virtue of our bw authorities measuring using 443. 443 is the second-most trafficed port by byte on the Tor network, occupying only ~1% of the traffic. If stingy exit nodes really want to And port 80 is the highest-traffic port. Exits to port 80 allow unencrypted access to webmail sites with user ids and passwords transmitted in the clear. Using your argument, all nodes allowing exits to port 80 that do not eliminate all webmail sites by way of their exit policies should be flagged as BadExit. That would certainly be a strange way to put tor into the dustbin of computer history, but it would indeed accomplish that. waste hours to pinch pennies from their malicious exit policy, they gatereloaded is among the top 60 nodes in the network by traffic capacity and is unlikely therefore to be pinching pennies on it. It is a valuable entry and middle node. If the operator wishes to offer in addition some exit services for a handful of ports that are unlikely to trigger problems from the operator's ISP, that is merely added gravy for tor users. can try crafting a throttling policy that we can't detect. Seems like there are better ways to spend their time. Like reading other people's email. So no, I'm not terribly concerned about second-order effects of this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. =20 My argument is that you're not identifying wolves. If you were serious about identifying wolves then could I suggest you create some dummy accounts, send your password through all exit nodes individually and see which of your accounts are accessed. This would positively identify wolves. All you're achieving by soley looking at exit policies is identifying things that may or may not be wolves and ignoring the larger body of exit nodes that may or may not include wolves. I submit your testing is flawed. We're not trying to identify wolves. We are sending a message to the community. =20 If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. =20 I'm not sure I'm comfortable with dictating how an exit nodes exitpolicy should be defined. Each policy should be up to the exit node owner to decide. Just my 2c I second that discomfort. I further note that the tor project team has repeatedly claimed that there is an ongoing shortage of exit nodes, although it has not often noted for which ports there is a shortage. One of the selling points for potential exit operators is that the exit operator can set an exit policy of his/her choice. The ability to do that means the operator can evaluate his/her own situation vis-a-vis his/her ISP, data rate capacity, etc. and decide upon a policy that will not cause him/her a level of grief unacceptable to him/her. Not really. In reality, it's up to those who write the code to decide what is available and how it works ;). Welcome to The Golden Path. At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Here you threaten that the tor project would someday severely reduce the control that an exit operator would have over his/her node. How would such a reduction help to entice more people to run exit nodes? How would such a reduction not cause at least some existing exit operators to stop offering exit services because they could no longer set an exit policy that they found acceptable in their circumstances? Scott Bennett, Comm. ASMELG, CFIAG
Re: Is gatereloaded a Bad Exit?
mi nt wrote: On Mon, Jan 31, 2011 at 08:39:29PM -0500, Gregory Maxwell wrote: The chances of having your traffic logged by malicious operators, known or unknown, allowing traffic on 443 or not, can be minimized by not using Tor. Just saying! :-) -- m...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ The chances of having your traffic logged by anyone, known or unknown, allowing traffic on 443 or not, can be minimized by not using Internet! :) *** 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?
Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I don't see what the issue is here. Not all e-mail services support HTTPS. Or are you saying: if there is a HTTPS option as for Gmail the 50 nodes choose the HTTP option instead? *** 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?
We already filter exit nodes based on suspicion by defaulting ExcludeSingleHopRelays to true (the reason for that being that single hop exits are more likely to be passively monitoring data). Can you please say a little more about this for all of us who are not au fait with all command options? We also invalidated the trotsky relays without proof of malicious intent (a suspected sybil attack when over seven hundred identical relays appeared out of the blue). Could you please say a little more about this case and sybil attack[s]? On Sun, Jan 30, 2011 at 10:58 AM, Orionjur Tor-admin tor-ad...@orionjurinform.com wrote: Damian Johnson wrote: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian [1] https://trac.torproject.org/projects/tor/wiki/badRelays On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiherj...@buksy.de wrote: At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Sounds good. But what to do for now? Just creating a list of nodes which only allow unencrypted traffic and put them into the ExcludeExitNodes list? Shouldnt these nodes be excluded by default? I'm unsure. I want to stress again that I'm not saying any operator is doing anything evil, but I think we should find some way to avoid nodes which have such weird exitpolicies. best regards, Jan *** 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/ Is it possible to publish a list of bad-exits for copypasting it to /etc/torrc in addition to the above-mentioned list? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
Can you please say a little more about this for all of us who are not au fait with all command options? Relays have an option to allow single hop connections through them, which is off by default. If relays *do* set this and allow single hop circuits through themselves then Tor clients by default avoid them for *any* usage in their circuits. Here's the description from the man page [1]: ExcludeSingleHopRelays 0|1 This option controls whether circuits built by Tor will include relays with the AllowSingleHopExits flag set to true. If ExcludeSingleHopRelays is set to 0, these relays will be included. Note that these relays might be at higher risk of being seized or observed, so they are not normally included. Also note that relatively few clients turn off this option, so using these relays might make your client stand out. (Default: 1) In short, there's no proof that these relays are bad but we avoid them because they're riskier (hopefully the parallels with the current discussion are obvious). Could you please say a little more about this case and sybil attack[s]? A sybil attack is where a huge number of relays operated by a single entity appear with the goal of doing bad things (for instance operating the first and last circuit hops to correlate traffic). Again, during that incident we didn't have proof that the seven hundred Trotsky relays appearing out of the blue were bad - we invalidated them because they were highly suspicious, lacked contact information, and had no family entry set. In both of those cases we took harder measures based on suspicion of malicious intent than we are with these plaintext-only relays. Despite its name, the BadExit flag really isn't a big whoop - the relays are still perfectly usable for guard and middle hop positions. They just aren't seeing exit traffic any longer. -Damian [1] https://www.torproject.org/docs/tor-manual.html *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Tue, Feb 1, 2011 at 6:31 PM, Damian Johnson atag...@gmail.com wrote: In both of those cases we took harder measures based on suspicion of malicious intent than we are with these plaintext-only relays. Despite its name, the BadExit flag really isn't a big whoop - the relays are still perfectly usable for guard and middle hop positions. They just aren't seeing exit traffic any longer. -Damian Slightly OT: Is there a place that explains what the various flags mean? I've wondered what they mean while looking at torstatus and metrics.torproject.org... and the manuals don't go into that. best, Joe -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/ *** 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?
https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l1285 On Tue, Feb 1, 2011 at 4:10 PM, Joseph Lorenzo Hall joeh...@gmail.com wrote: On Tue, Feb 1, 2011 at 6:31 PM, Damian Johnson atag...@gmail.com wrote: In both of those cases we took harder measures based on suspicion of malicious intent than we are with these plaintext-only relays. Despite its name, the BadExit flag really isn't a big whoop - the relays are still perfectly usable for guard and middle hop positions. They just aren't seeing exit traffic any longer. -Damian Slightly OT: Is there a place that explains what the various flags mean? I've wondered what they mean while looking at torstatus and metrics.torproject.org... and the manuals don't go into that. best, Joe -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in 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: Is gatereloaded a Bad Exit?
Do you have a rational reason why we should allow people to carry the unencrypted version of a service but not the encrypted one, other than Well, they could be bad actors even with a good policy! As I stated above, it's not a good idea to BadExit them, because it puts more load on the servers, that DO support https i.e. - and makes them slower. Those weren't 10K/s Nodes you blacklisted there, they've been really fast Exit Nodes. And I don't see ANY point in BadExit'ing 5 random Nodes, suggesting that no one could capture your unencrypted traffic now. This is just further slowing down the whole Tor-Network. morphium *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 31.01.2011 10:52, morphium wrote: As I stated above, it's not a good idea to BadExit them, because it puts more load on the servers, that DO support https i.e. - and makes them slower. I disagree Morphium's position mainly for the same reasons Mike and Jake already pointed out. If the operators really care about their nodes they'll certainly contact Tor admins. Damaging Tor's reputation in the public due to exit sniffing imo is much more worse than loosing some bandwidth. And I don't see ANY point in BadExit'ing 5 random Nodes, suggesting that no one could capture your unencrypted traffic now. those five high bandwidth nodes with suspicious exit policies haven't been chosen randomly. Olaf *** 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?
2011/1/31 Olaf Selke olaf.se...@blutmagie.de: I disagree Morphium's position mainly for the same reasons Mike and Jake already pointed out. If the operators really care about their nodes they'll certainly contact Tor admins. Damaging Tor's reputation in the public due to exit sniffing imo is much more worse than loosing some bandwidth. Sniffing is worse than loosing bandwidth, right. But sniffing still occurs, we just don't know where. And we can't tell wether they did. I think concluding only 80: he is sniffing is wrong (and even would be 80 and 443: he is a good guy). And if those nodes really are ran by the bad guys, I don't think it's a problem for them now to setup a new node on a new subnet that allows their old ports + 443 and continue sniffing. I can not see the Tor project won _anything_ with this decision. morphium *** 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 can not see the Tor project won _anything_ with this decision. I agree 100%. By all means try to identify those that are trying to misuse the privilege of running an exit node by other means - but solely looking at exit policies is not sufficient. All you're stating to the community is do it my way or the highway and honestly, aren't we better than that? Blacklist them, sure, after you have *good* reason. WRT grouping 80 and 443 later on, I'm totally against that as it doesn't give operators the freedom to select what goes through their nodes. If I was still running a node I'd disconnect it after you implemented this 'feature' - purely in protest. -- Eddie Cornejo -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d? s: a C+++ UL+++ P++ L++ E- W+ N- o K- w++ O M-- V PS+ PE Y PGP++ t 5 X+ R tv-- b+ DI D++ G e++ h r+++ y --END GEEK CODE BLOCK-- *** 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?
2011/1/31 Mike Perry mikepe...@fscked.org: So when I said in my earlier post that we don't need exit capacity that bad, I meant it. Thanks, but no thanks. You are contributing negative productivity, and none of the non-bitorrenting exits really will notice your absence in terms of load. Please direct yourself towards the nearest forbidden lake. So, to summarize that, you are saying to every operator that is not your opinion: We (as the Tor project) don't need you. Thats... pretty arrogant. Or am I mis-understanding you? Best regards, morphium *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 1/31/2011 6:05 AM, morphium wrote: 2011/1/31 Mike Perrymikepe...@fscked.org: So when I said in my earlier post that we don't need exit capacity that bad, I meant it. Thanks, but no thanks. You are contributing negative productivity, and none of the non-bitorrenting exits really will notice your absence in terms of load. Please direct yourself towards the nearest forbidden lake. So, to summarize that, you are saying to every operator that is not your opinion: We (as the Tor project) don't need you. Thats... pretty arrogant. I'm not sure how that's arrogant at all. These nodes aren't exit-flagged, have suspicious (though maybe not damning) exit policies, and have no or fake contact information. They're either malicious or horribly configured, and in either case there's no way to get in touch with the operators. Strong odds are they're doing the network (and its goals) more harm than good, so they're removed from it (note that there was no IP ban, so the operators are free to return to the network if they so choose). Honestly, it seems to me that this is the Tor Project equivalent of a slap on the wrist; a much stronger, more irrational decision could certainly have been elicited. I'm operating under the assumption that we run our nodes to further the goals of the Tor Project and help the community. I'm not sure why removing exits with idiotic or malicious configurations (until the operator either fixes them or explains themselves) is a bad thing. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
morphium wrote: 2011/1/31 Olaf Selke olaf.se...@blutmagie.de: I disagree Morphium's position mainly for the same reasons Mike and Jake already pointed out. If the operators really care about their nodes they'll certainly contact Tor admins. Damaging Tor's reputation in the public due to exit sniffing imo is much more worse than loosing some bandwidth. Sniffing is worse than loosing bandwidth, right. But sniffing still occurs, we just don't know where. And we can't tell wether they did. I think concluding only 80: he is sniffing is wrong (and even would be 80 and 443: he is a good guy). And if those nodes really are ran by the bad guys, I don't think it's a problem for them now to setup a new node on a new subnet that allows their old ports + 443 and continue sniffing. I can not see the Tor project won _anything_ with this decision. morphium *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ And, then, it seems to me that it is no a big problem to exclude packages with encrypted information from sniffing logs for people who setting up nodes for that evil purposes. But, in the other side, it seems to me that guys which set up so such fast nodes are not full lamers. And they probably can read this mailing list and are able to answer us, am I wrong? As concern to me, if I read some bad about my nodes here I will write something to answer, no? *** 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?
Mike Perry wrote: Thus spake morphium (morph...@morphium.info): Do you have a rational reason why we should allow people to carry the unencrypted version of a service but not the encrypted one, other than Well, they could be bad actors even with a good policy! As I stated above, it's not a good idea to BadExit them, because it puts more load on the servers, that DO support https i.e. - and makes them slower. Those weren't 10K/s Nodes you blacklisted there, they've been really fast Exit Nodes. And I don't see ANY point in BadExit'ing 5 random Nodes, suggesting that no one could capture your unencrypted traffic now. This is just further slowing down the whole Tor-Network. This is not true. The exit nodes in question account for ~6% of the network Exit-flagged bandwidth. That is, *IF* they actually had the Exit flag (they did not), they would have provided 6% of that bandwidth. They do not have the Exit flag, however, so they provide 0%. How is it possible that they configured their nodes as exits and defined their exit policies but those nodes didn't work as exits in practice? Are those nodes misconfiured? So, how those can sniffing exit-traffic? But I can confirm that somedays ago I have used oompaloompa and oompaloompa2 for connecting to the LiveJournal. I know it becouse their ip (and an ip of Olaf's node too) was banned by the LJ team as bots and I sent to the LJ team report for unblocking that ips as belonging not to bots but to exit-nodes of the Tor. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 31/01/2011 12:37, Orionjur Tor-admin wrote: But, in the other side, it seems to me that guys which set up so such fast nodes are not full lamers. And they probably can read this mailing list and are able to answer us, am I wrong? They may or may not read this list. Has anyone taken pro-active steps to try and contact the people running these exits? They may not publish their contact details in the directory, but we have their IP addresses... Which means we can probably figure out how to contact at least some of them... Assuming the worse, and disregarding volunteer exit bandwidth without some proper investigation, doesn't sound like a good approach to me... -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F signature.asc Description: OpenPGP digital signature
Re: Is gatereloaded a Bad Exit?
Assuming the worse, and disregarding volunteer exit bandwidth without some proper investigation, doesn't sound like a good approach to me... Nobody does that, but I think its fair to say that if you want that somebody can contact you about your node, you publish your contact details in the directory. And if you enter wrong contact infos, you made clear that you dont want to be contacted. I think marking them as bad and waiting for the admin to show up is the easiest way to go. Lets call it a cry-test. Just wait until someone shows up and cries. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 31/01/2011 13:11, Jan Weiher wrote: Assuming the worse, and disregarding volunteer exit bandwidth without some proper investigation, doesn't sound like a good approach to me... Nobody does that, but I think its fair to say that if you want that somebody can contact you about your node, you publish your contact details in the directory. And if you enter wrong contact infos, you made clear that you dont want to be contacted. I don't think you can make that assumption. Maybe they just didn't want their email address to be public for spam bots to harvest. Maybe they're just used to not publishing their email address unless they really have to. Safest course of action: Figure out how to contact them, and ask them. I think marking them as bad and waiting for the admin to show up is the easiest way to go. Lets call it a cry-test. Just wait until someone shows up and cries. It's the easiest, but the least efficient route. Somebody mentioned 6% of Exit bandwidth. How much effort would be spent trying to increase the capacity of the network by 6% via coding and/or publicity? Probably a lot more effort than would be required to try and contact these Exit owners and maybe retain the bandwidth. You make it sound as though running an Exit node is a privilege and that people who run them somehow owe the Tor project? They're volunteering bandwidth, for the benefit of the network. If you don't treat volunteers well, they will go elsewhere, and the people who lose out are the people who use the Tor network, not the people who previously ran Exit nodes. Exit bandwidth is a scarce and valuable resource, and should be treated as such. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F signature.asc Description: OpenPGP digital signature
Re: Is gatereloaded a Bad Exit?
You make it sound as though running an Exit node is a privilege and that people who run them somehow owe the Tor project? They're volunteering bandwidth, for the benefit of the network. This was not my intention. But I think it should be possible to ask a volunteer about what he is doing? And creating a freemail acc somewhere isnt that hard I think? I'm not saying that they should put their real name / email there. But at least some way to contact them would probably make this whole discussion completely useless. They are still working for the benefit of the network, but not as exit at the moment. best regards, Jan *** 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 don't think that tor should be dictating what ports must or must not be open on an exit node. This is after all a voluntary operation. If people want to send unencrypted data, they will do so with or without these 5 nodes. Shutting them or others down as exits will not make up for users that don't bother to secure their data. I will do my little bit to show my disagreement with the actions that have been taken by taking 'goodeid' offline until such time as cooler heads resolve this situation without jumping to unfounded conclusions. Chuck On 2011-01-30, at 11:54 PM, Mike Perry wrote: Thus spake morphium (morph...@morphium.info): 2011/1/30 Damian Johnson atag...@gmail.com: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian That was really dumb, as it puts a lot more load on the Nodes that support encryption, and, as was mentioned before, _every_ operator could sniff. There is no rational reason to carry the unencrypted version of a service but not the encrypted version, except to log data. So unless these 5 nodes were all just playing their favorite lotto numbers in their exit policy, they were being jerks. I am aware that every operator can sniff regardless of policy. Every operator can do a lot of things. The fact that even good exit policies can do bad things is not a necessary condition for allowing bad exit policies. Frankly, this in-your-face selfishness of *only* accepting the unencrypted data because fuck it, that's the only data I want to log just rubs me the wrong way. Not one of those 5 had legit contact info. Two of them actually bothered to fill out the field, but filled it in with a fake email address. All of them just wreak of disrespect for us, for the network, and for our users. Essentially, it's that disrespect that earned them the BadExit flag. If this means that sending the message to them means we take out a few irrational actors in the process, that's fine. I don't much want people playing lotto in their exit policies either. They can stick to middle node and put their lotto numbers in their contact info. I promise that it will work just as well. I will change my Exit Policy now to something like 80, 6667, 21 and if you BadExit it, you'll loose another fast node. *sigh*. And so the cat herding begins. Are you really protesting this policy decision with civil disobedience? Really? Fighting for Great Justice everywhere, eh? Do you have a rational reason why we should allow people to carry the unencrypted version of a service but not the encrypted one, other than Well, they could be bad actors even with a good policy! Or is it just because you feel that someone told to do something and you don't much like being told what to do, regardless of the reasoning? I forbid you from jumping in the nearest lake! I also forbid you from taking your freshly-gimped exit node in for a swim with you! -- Mike Perry Mad Computer Scientist fscked.org evil labs *** 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?
In my opinion, judging a relay based on exit policy is a slippery slope we don't want to go down. We never claim to make using Tor alone safer than using the Internet at large. Whether the creep is at Starbucks sniffing the wifi or running a relay is irrelevant to me. Encouraging people to use encrypted communications, the https everywhere firefox extension, and learn to be more secure online are some of our goals. The Tor Browser Bundle, while still a work in progress, is the best way to protect novice users and get them safer than they are without Tor. I personally run encrypted services on unencrypted ports, like 25, 80, 143, 110, etc. It's just a port number and only convention says port 80 has to be for http only. If people start doing deep packet inspection to enforce 80 is really http or running filters in some misguided attempt to block bad things through Tor, then those are reasons to 'badexit' relays. There are some obvious ways we can detect traffic manipulation through Tor relays. Today, we do detect them and badexit those relays. If we're going to start censoring Tor exits based on impressions, we might as well start blocking Tor relays that are rumoured to be run by national intelligence agencies, criminal organizations, martians, and other people we might not like. In fact, we might as well go back to the original model of every Tor relay operator has met and gained Roger's trust. I want a diverse set of Tor relays. If people don't want to trust relays based on whatever heuristics they want to use, great, use ExcludeNodes in your torrc. Don't punish everyone based on rumors and impressions. -- Andrew pgp 0x74ED336B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, Jan 31, 2011 at 11:30 AM, Andrew Lewman and...@torproject.org wrote: [snip] If we're going to start censoring Tor exits based on impressions, we might as well start blocking Tor relays that are rumoured to be run by national intelligence agencies, criminal organizations, martians, and other people we might not like. In fact, we might as well go back to the original model of every Tor relay operator has met and gained Roger's trust. I'd disappointed that you're not responding to the argument I initially posed. We should do this not because the node looks suspicious but because we want to shape the behaviour of exit operators. There are legitimate reasons why tor supports an operator controlled exit policy, but no real suggestion has been made for a _legitimate_ reason to allow 80 and block 443. So we make carrying 443 part of the price of being a port 80 exit. So this exclusion shouldn't be seen as something that will eliminate bad guys, — it clearly won't — but will instead force them to behave more like we want them to, by adding 443 capacity and making tor faster for https users— as part of the price of operating an exit. The best argument against this would be that it makes it harder for people to spot these probably-bad nodes based on the exit policy and exclude them for themselves. I think this downside is inconsequential because almost no one is actually going to do this, and anyone that sophisticated can be trusted to protect themselves in other ways. Tor has a great many behaviour shaping incentives in the protocol and implementation. This would not stand out as too unusual. *** 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?
- Original Message From: Gregory Maxwell gmaxw...@gmail.com To: or-talk@freehaven.net Sent: Mon, January 31, 2011 6:47:37 PM Subject: Re: Is gatereloaded a Bad Exit? There are legitimate reasons why tor supports an operator controlled exit policy, but no real suggestion has been made for a _legitimate_ reason to allow 80 and block 443. Is it possible that some people operate in a port-restricted environment or that port 443 is throttled by some ISPs? My real question concerns the scenario in which a user happens upon an exit that blocks HTTPS and uses that exit to access a website that uses a combination of HTTP and HTTPS. The HTTPS portion would be forced through a different exit, and the server may be programmed to notice the difference and break by design. For example, say you want to login somewhere, and the server notes that you appear to be logging in from France. The HTTPS portion appears to come from the United States. That disparity triggers an I'm sorry... message. *** 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?
Thus spake Curious Kid (letsshareinformat...@yahoo.com): - Original Message From: Gregory Maxwell gmaxw...@gmail.com To: or-talk@freehaven.net Sent: Mon, January 31, 2011 6:47:37 PM Subject: Re: Is gatereloaded a Bad Exit? There are legitimate reasons why tor supports an operator controlled exit policy, but no real suggestion has been made for a _legitimate_ reason to allow 80 and block 443. Is it possible that some people operate in a port-restricted environment or that port 443 is throttled by some ISPs? These people should not be Tor nodes. A good portion of the public network is on port 443. If you can't reach that port, lots of circuits clients try to build through you will fail. Failed circuits have a negative impact on latency, esp if they were not pre-launched predicted circuits. Byzantine circuit failures also make it difficult to differentiate between overloaded, CPU-bound nodes, malicious nodes, and just plain janky nodes - all of which we would like to be able to take into account for future load balancing decisions. Ex: https://trac.torproject.org/projects/tor/ticket/1984 My real question concerns the scenario in which a user happens upon an exit that blocks HTTPS and uses that exit to access a website that uses a combination of HTTP and HTTPS. The HTTPS portion would be forced through a different exit, and the server may be programmed to notice the difference and break by design. For example, say you want to login somewhere, and the server notes that you appear to be logging in from France. The HTTPS portion appears to come from the United States. That disparity triggers an I'm sorry... message. This is an excellent point, and yet another reason why we should not allow asinine exit policies unless there is good reason for them. So far there is still no rational reason posted why you should allow 80 and not 443 and still be considered a desirable Tor node to use. Just a lot of handwaving about the freedom to be a jerk, and fears over shunning volunteers who run fast exits to grab passwords. Moreover, I strongly believe that we should be working on converging our choices of exit policy down to fewer options for many practical engineering and usability reasons. Exit policies already take up an absurd amount of capacity in terms of descriptor and even networkstatus storage. If we can standardize on a group or groups of ports (such as the Vidalia GUI attempts to do), we can describe sane exit policies using much fewer bytes. And we can load balance more intelligently among exits with standard policies, as I mentioned before. So to me, there are plenty of reasons to do this, and not a whole lot of reasons not to do it, other than handwavy notions that it shouldn't matter, when in fact as you have pointed out, it does matter. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpAQeXL2YOCP.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake t...@lists.grepular.com (t...@lists.grepular.com): On 31/01/2011 13:11, Jan Weiher wrote: Assuming the worse, and disregarding volunteer exit bandwidth without some proper investigation, doesn't sound like a good approach to me... Nobody does that, but I think its fair to say that if you want that somebody can contact you about your node, you publish your contact details in the directory. And if you enter wrong contact infos, you made clear that you dont want to be contacted. I don't think you can make that assumption. Maybe they just didn't want their email address to be public for spam bots to harvest. Maybe they're just used to not publishing their email address unless they really have to. Safest course of action: Figure out how to contact them, and ask them. 3/5 of the nodes provide contact info. 2/5 are run by Joe Blow, and the other is run by nobody at example.com Just for grins, I did in fact send an email to Mr. Blow's gmail address. It of course bounced. Which means it is available on gmail if he wanted it, but he didn't even bother to create it. He's obviously real intent on being a member of the community. But don't worry, at some point Mr. Blow et al will realize that their packet captures stopped grabbing passwords and are only seeing encrypted middle and guard node traffic. They'll probably show up then, proclaiming their innocence from the rooftops, demanding they be allowed to help the network. But do feel free to spend your time going above and beyond, trying to track our 4 heroes down before then. I'm sure they're well worth your time and effort to outreach. Pick a nice Saturday afternoon and spend it calling ISPs and NOCs trying frantically to get in touch with our unjustly punished martyrs here... Heck, take a day off work! I think marking them as bad and waiting for the admin to show up is the easiest way to go. Lets call it a cry-test. Just wait until someone shows up and cries. It's the easiest, but the least efficient route. Somebody mentioned 6% of Exit bandwidth. How much effort would be spent trying to increase the capacity of the network by 6% via coding and/or publicity? Probably a lot more effort than would be required to try and contact these Exit owners and maybe retain the bandwidth. You make it sound as though running an Exit node is a privilege and that people who run them somehow owe the Tor project? They're volunteering bandwidth, for the benefit of the network. If you don't treat volunteers well, they will go elsewhere, and the people who lose out are the people who use the Tor network, not the people who previously ran Exit nodes. Exit bandwidth is a scarce and valuable resource, and should be treated as such. It's not true exit bandwidth here. It's janky bandwidth with lots of bad properties, such as the tendency to break mixed-mode websites as Curious Kid pointed out, and the load balancing issues I mentioned. We should do the same for all http-but-not-https exits for this reason. Again, non-bittorrenting exits have a real hard time attracting enough 80+443 traffic. All of our metrics indicate they are not overloaded the vast majority of the time, and tend to end up pushing half of the bytes/sec as their bitorrent-supporting peers. There is plenty of spare port 80 capacity. The network is bottlenecked in other ways (probably actually in the queues of overloaded middle and guard nodes, which these jerks would be more directly assisting). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpV80CfRkECf.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
On 01/02/2011 00:00, Mike Perry wrote: I don't think you can make that assumption. Maybe they just didn't want their email address to be public for spam bots to harvest. Maybe they're just used to not publishing their email address unless they really have to. Safest course of action: Figure out how to contact them, and ask them. 3/5 of the nodes provide contact info. 2/5 are run by Joe Blow, and the other is run by nobody at example.com Just for grins, I did in fact send an email to Mr. Blow's gmail address. It of course bounced. Which means it is available on gmail if he wanted it, but he didn't even bother to create it. He's obviously real intent on being a member of the community. If valid contact info is important/necessary, the Tor project should enforce it, and perform periodic email address validation in order to allow routers to be Exits. If it's not important/necessary than I see no valid reason to complain about it not existing. But don't worry, at some point Mr. Blow et al will realize that their packet captures stopped grabbing passwords and are only seeing encrypted middle and guard node traffic. They'll probably show up then, proclaiming their innocence from the rooftops, demanding they be allowed to help the network. The above may or may not be true. Would be nice to see some evidence. Or at least some evidence of somebody trying to find the truth. But do feel free to spend your time going above and beyond, trying to track our 4 heroes down before then. I'm sure they're well worth your time and effort to outreach. Pick a nice Saturday afternoon and spend it calling ISPs and NOCs trying frantically to get in touch with our unjustly punished martyrs here... Heck, take a day off work! Do you find that being condescending is a good way to get people to agree with you? I tend to find it fosters disrespect. I think marking them as bad and waiting for the admin to show up is the easiest way to go. Lets call it a cry-test. Just wait until someone shows up and cries. It's the easiest, but the least efficient route. Somebody mentioned 6% of Exit bandwidth. How much effort would be spent trying to increase the capacity of the network by 6% via coding and/or publicity? Probably a lot more effort than would be required to try and contact these Exit owners and maybe retain the bandwidth. You make it sound as though running an Exit node is a privilege and that people who run them somehow owe the Tor project? They're volunteering bandwidth, for the benefit of the network. If you don't treat volunteers well, they will go elsewhere, and the people who lose out are the people who use the Tor network, not the people who previously ran Exit nodes. Exit bandwidth is a scarce and valuable resource, and should be treated as such. It's not true exit bandwidth here. It's janky bandwidth with lots of bad properties, such as the tendency to break mixed-mode websites as Curious Kid pointed out, and the load balancing issues I mentioned. We should do the same for all http-but-not-https exits for this reason. If exiting port 80 but not port 443 causes problems for Tor, then Tor should be updated so you can't offer one without the other. This is a problem with Tor, not with Tor exit operators. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F signature.asc Description: OpenPGP digital signature
Re: Is gatereloaded a Bad Exit?
Thus spake t...@lists.grepular.com (t...@lists.grepular.com): But don't worry, at some point Mr. Blow et al will realize that their packet captures stopped grabbing passwords and are only seeing encrypted middle and guard node traffic. They'll probably show up then, proclaiming their innocence from the rooftops, demanding they be allowed to help the network. The above may or may not be true. Would be nice to see some evidence. Or at least some evidence of somebody trying to find the truth. The truth here is that these nodes are not behaving in a way that encourages trust in their usage. All we ask is that they adjust their exit policies to allow encryption, but there is no way to ask them this, so they are badexited until such time as there is a way to communicate with them. They will remain valid middle and guard nodes until they rekey with policy supporting encryption (and the Exit flag). But do feel free to spend your time going above and beyond, trying to track our 4 heroes down before then. I'm sure they're well worth your time and effort to outreach. Pick a nice Saturday afternoon and spend it calling ISPs and NOCs trying frantically to get in touch with our unjustly punished martyrs here... Heck, take a day off work! Do you find that being condescending is a good way to get people to agree with you? I tend to find it fosters disrespect. You're right. I apologize for my tone to you. I am merely frustrated with the amount of mental energy devoted to what so plainly appears to me as a simple policy: If you carry the unencrypted version of the service, you should carry the encrypted version. I am just getting frustrated with the length of this thread and still the lack of any valid, rational reason why this policy itself is an unjust one. It seems pretty plain to me that we're actually worried about offending the sensibilities of people who for some unknown (but rationally obvious) reason refuse to carry encrypted exit traffic. So the idea that we should devote yet more effort to catering to people whose motivations are extremely suspect (and who seemingly have no real interest in being members of our community) is causing me to balk. Exit bandwidth is a scarce and valuable resource, and should be treated as such. It's not true exit bandwidth here. It's janky bandwidth with lots of bad properties, such as the tendency to break mixed-mode websites as Curious Kid pointed out, and the load balancing issues I mentioned. We should do the same for all http-but-not-https exits for this reason. If exiting port 80 but not port 443 causes problems for Tor, then Tor should be updated so you can't offer one without the other. This is a problem with Tor, not with Tor exit operators. Sure. Perhaps we will include such a patch as part of https://trac.torproject.org/projects/tor/ticket/2395. Or, perhaps it will just be a second-order effect that means you're just not used as often because you're not a true Exit (which is already the case for these nodes to some extent). But again, I think this is more of a long-term idea. In the meantime, we can enforce this policy with code on the exit scanning end, by emailing everyone with valid contact info who exits to 80 but not 443, to start (as that is the most obviously broken case). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp3Q4FGYxP93.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
These people should not be Tor nodes. Mike, I respectfully disagree. Anyone willing to allow traffic should be node. The tor project homepage makes no 'rules' when it comes to running a node. If you're willing to allow any traffic you're a suitable candidate, apparently in the opinion of the creators of that site and in mine. The fact is that some people are going to do things they shouldn't over *any* node, not just these that APPEAR suspicious. We have no idea why they're restricting access to those ports, even if it's just for logging what others are doing - they're still providing access. I'll use those nodes to read news articles and such, who cares if they log that? Users should understand what makes them secure when it comes to things they're doing across the internet - tor project or anyone participating should have absolutely zero responsibility, or concern, over traffic leaving the network. You can't protect people from their own stupidity. If someone insists on using insecure methods they're simply going to do it. Let's say I was a malicious node operator and I wanted to log a bunch of traffic -- I'm going to set up a node to allow all traffic and log what I can to avoid suspicion and the very thing that is happening on this list!. This is simple logic and I'm sure it's not lost on our *supposed* malicious node owners that we're currently discussing. The point I'm trying to make here is that even if these guys are just saying 'fuck it, I'll just allow 80 and telnet so I can grab accounts' that's no reason to ban them. Users should be responsible for their own security *outside* of the network (and internally when it relates to activities on hidden services for that matter) - we shouldn't assume people are too stupid to know not to login to their bank(for example) over tor using plaintext. I say keep them around and use the hell out of them. If they're logging my hentai pictures well then more power to them - I hope they enjoy! I realize my opinion doesn't mean a lot as I'm fairly new to this list but there it is. (I'm not one of these exit operators btw as I would certainly allow all traffic) -- m...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org *** 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?
Furthermore I would like to add that if I ran an exit I *might* just not put contact info on it. I don't see the issue unless it's rejecting traffic and I'm screwing up the network. Even if it was I'd figure it out eventually. I wouldn't want you weirdos emailing me anyway ;) -- m...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Mon, Jan 31, 2011 at 8:08 PM, mi nt m...@sdf.lonestar.org wrote: These people should not be Tor nodes. Mike, I respectfully disagree. Anyone willing to allow traffic should be node. The tor project homepage makes no 'rules' when it comes to running a node. If you're willing to allow any traffic you're a suitable candidate, apparently in the opinion of the creators of that site and in mine. The fact is that some people are going to do things they [snip] The website also advises that sniffing exit traffic is potentially a crime. (http://www.torproject.org/eff/tor-legal-faq.html.en#ExitSnooping) So I very much think you are mistaking the perspective of the website operators. Please don't confuse the realistic position of We can't prevent this from happening from the we approve of this activity. Can you exactly point out places where the website seems to suggest that anything goes is actually permitted? Any such text should be corrected, because it's not correct. It isn't permitted to do these things, to the extent that the tor developers and community can stop these activities they will (but the extent is very limited). On Mon, Jan 31, 2011 at 8:10 PM, mi nt m...@sdf.lonestar.org wrote: Furthermore I would like to add that if I ran an exit I *might* just not put contact info on it. I don't see the issue unless it's rejecting traffic and I'm screwing up the network. Even if it was I'd figure it out eventually. I wouldn't want you weirdos emailing me anyway ;) The chances of receiving email from the weirdos here can be minimized by unsubscribing from this mailing list. Just saying! :-) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sun, 30 Jan 2011, Christopher A. Lindsey wrote: Could it be that these nodes have set these policies to reduce the possibility of being approached because of illegal activity passing through them? It could be they believe that they're helping with the project and limiting their exposure as bad guys wouldn't use clear text. Sorry, Chris - the mob has spoken. Further common sense - like suggesting that we have no idea what kind of traffic flows over an open port 21/23/etc., or proposing that these may be internal tools for specific populations that we know nothing about, will not be useful. But here's a snarky thought for you - what if my exit policy is: 21 23 80 110 143 8999 (Brodos Crypto Trade Protocol) Now what ? *** 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?
Mike Perry wrote: Thus spake Eddie Cornejo (corn...@gmail.com): Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm missing something. Yeah, I believe you're missing the fact that these ports also contain plaintext passwords than can be used to gain access to information on these and other accounts that may or may not have ever traveled over tor. That is the difference. And what is a difference in using the Tor and not using the Tor when you don't use SSL? Only that in the last time your password etc. can see your ISP or governmental systems like european Echelon, Russian SORM and etc. *** 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?
At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Sounds good. But what to do for now? Just creating a list of nodes which only allow unencrypted traffic and put them into the ExcludeExitNodes list? Shouldnt these nodes be excluded by default? I'm unsure. I want to stress again that I'm not saying any operator is doing anything evil, but I think we should find some way to avoid nodes which have such weird exitpolicies. best regards, Jan *** 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?
The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian [1] https://trac.torproject.org/projects/tor/wiki/badRelays On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiher j...@buksy.de wrote: At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Sounds good. But what to do for now? Just creating a list of nodes which only allow unencrypted traffic and put them into the ExcludeExitNodes list? Shouldnt these nodes be excluded by default? I'm unsure. I want to stress again that I'm not saying any operator is doing anything evil, but I think we should find some way to avoid nodes which have such weird exitpolicies. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in 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: Is gatereloaded a Bad Exit?
On Sun, 30 Jan 2011 10:33:31 +0100 Jan Weiher j...@buksy.de wrote: At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Sounds good. But what to do for now? Just creating a list of nodes which only allow unencrypted traffic and put them into the ExcludeExitNodes list? Shouldnt these nodes be excluded by default? They will be now. The exit scanner detects such nodes, and Mike Perry has just made it easier to mark nodes with suspicious policies with the BadExit flag in the future: https://gitweb.torproject.org/torflow.git/commitdiff/2320961a05e3277534887c7f76036c826a879230 Robert Ransom signature.asc Description: PGP signature
Re: Is gatereloaded a Bad Exit?
2011/1/30 Damian Johnson atag...@gmail.com: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian That was really dumb, as it puts a lot more load on the Nodes that support encryption, and, as was mentioned before, _every_ operator could sniff. I will change my Exit Policy now to something like 80, 6667, 21 and if you BadExit it, you'll loose another fast node. Bye! morphium *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 01/30/2011 01:56 AM, morphium wrote: 2011/1/30 Damian Johnson atag...@gmail.com: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian That was really dumb, as it puts a lot more load on the Nodes that support encryption, and, as was mentioned before, _every_ operator could sniff. Hardly. An important difference is that some people specifically create exit policies to attract traffic worth passively sniffing. In any case, it hardly puts more load on nodes that support encryption unless they also are supporting the unencrypted protocols in the first place. I will change my Exit Policy now to something like 80, 6667, 21 and if you BadExit it, you'll loose another fast node. It sounds like there's now a known reason for your exit policy, I doubt anyone would bad exit you. All the best, Jake *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, 2011-01-29 at 22:45 -0800, Mike Perry wrote: Thus spake Eddie Cornejo (corn...@gmail.com): Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm missing something. Yeah, I believe you're missing the fact that these ports also contain plaintext passwords than can be used to gain access to information on these and other accounts that may or may not have ever traveled over tor. That is the difference. Finally there is no way that an exit node can directly affect the mode choices by a client. Ie, apart from a particular node existing, there is no way that a node could force a user to use it. See above. Therefore I submit that having these nodes, whether they are overtly recording traffic or not, does not result in any harm to the TOR network. In fact, their presence lessens the burden on the TOR network as they are providing much needed bandwidth. We don't need bandwidth that bad. So, what's the threat? Why are you considering banning these nodes when, by all accounts, I cannot see them having a negative impact on the network as a whole (in fact, it's probably a positive influence) I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. Could it be that these nodes have set these policies to reduce the possibility of being approached because of illegal activity passing through them? It could be they believe that they're helping with the project and limiting their exposure as bad guys wouldn't use clear text. Take care, Chris signature.asc Description: This is a digitally signed message part
Re: Is gatereloaded a Bad Exit?
On Sat, Jan 29, 2011 at 07:46:20PM +0100, Jan Weiher wrote: Hi, while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? I'm aware of the fact that it is not recommended to use tor without additional encryption, but some users do. And I dont see any reason for only allowing unencrypted traffic than snooping? Can anyone clearify this? If the admin of this node is on the list, would he please explain this situation? best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ I don't see why any of this really matters. Anyone running tor should have the good sense to realize that if you login to webmail.example.com over plaintext then the node operator could grab your details. It states this repeatedly on torproject IIRC. Furthermore anything really important like financial logins are typically done over SSL anyway. If some guy gets his facebook account hijacked because he didn't read the FAQ I don't see the issue. Just my measly two cents. *** 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?
Damian Johnson wrote: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian [1] https://trac.torproject.org/projects/tor/wiki/badRelays On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiher j...@buksy.de wrote: At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Sounds good. But what to do for now? Just creating a list of nodes which only allow unencrypted traffic and put them into the ExcludeExitNodes list? Shouldnt these nodes be excluded by default? I'm unsure. I want to stress again that I'm not saying any operator is doing anything evil, but I think we should find some way to avoid nodes which have such weird exitpolicies. best regards, Jan *** 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/ Is it possible to publish a list of bad-exits for copypasting it to /etc/torrc in addition to the above-mentioned list? *** 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?
There's no point in putting relays flagged as BadExit into your torrc since your client will already avoid them. However, if you want a listing of the bad exits then it's available at: https://trac.torproject.org/projects/tor/wiki/badRelays As for the previous discussion of if plaintext-only exits warrant the flag, here's my bit to add to the discussion: We already filter exit nodes based on suspicion by defaulting ExcludeSingleHopRelays to true (the reason for that being that single hop exits are more likely to be passively monitoring data). We also invalidated the trotsky relays without proof of malicious intent (a suspected sybil attack when over seven hundred identical relays appeared out of the blue). I'm a little in favor of flagging plaintext-only exits, though I agree that it sucks when flagging doesn't have a smoking gun. Cheers! -Damian On Sun, Jan 30, 2011 at 10:58 AM, Orionjur Tor-admin tor-ad...@orionjurinform.com wrote: Damian Johnson wrote: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian [1] https://trac.torproject.org/projects/tor/wiki/badRelays On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiher j...@buksy.de wrote: At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Sounds good. But what to do for now? Just creating a list of nodes which only allow unencrypted traffic and put them into the ExcludeExitNodes list? Shouldnt these nodes be excluded by default? I'm unsure. I want to stress again that I'm not saying any operator is doing anything evil, but I think we should find some way to avoid nodes which have such weird exitpolicies. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ Is it possible to publish a list of bad-exits for copypasting it to /etc/torrc in addition to the above-mentioned list? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in 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: Is gatereloaded a Bad Exit?
I'm aware of the fact that it is not recommended to use tor without additional encryption, but some users do. And I dont see any reason for only allowing unencrypted traffic than snooping? [...] I don't see why any of this really matters. Anyone running tor should have the good sense to realize that if you login to webmail.example.com over plaintext then the node operator could grab your details. It states this repeatedly on torproject IIRC. Furthermore anything really important like financial logins are typically done over SSL anyway. Yes, we all know that, hopefully the average user knows that. But in my opinion this has nothing to do with having an exitpolicy that attracts unencrypted traffic. Just the fact that everyone (hopefully) knows that the traffic can be recorded, it does not make it better if I do? I would have asked the specific operator about his exitpolicy, but as I noted, there is no contact info given, which makes it even more suspicious. Not the fact that there is no contact info - there are many nodes without contact infos - but I thought the combination is odd. If some guy gets his facebook account hijacked because he didn't read the FAQ I don't see the issue. I totally disagree. Of course, you could argue that it's his fault and so forth. I would agree to that, but on the other hand, should accept to make this even easier? Additionally, if some guy gets his account somewhere hacked after having used tor, it looks bad. And at that point, the user does not really care about I told you so!!!. He is going to tell his friends I used tor and my account got hacked.. These nodes are marked as BadExits for now, which does not hurt, because if the operators of these nodes care about Tor, they are going to ask why is my node marked as bad exit and you could have a discussion about it. The operators can tell us why they choose these exitpolicy or we can help to improve them. If those nodes - which have sometimes been up for several months - silently disappear, I know what I'll think. best regards, Jan *** 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?
Thus spake morphium (morph...@morphium.info): 2011/1/30 Damian Johnson atag...@gmail.com: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian That was really dumb, as it puts a lot more load on the Nodes that support encryption, and, as was mentioned before, _every_ operator could sniff. There is no rational reason to carry the unencrypted version of a service but not the encrypted version, except to log data. So unless these 5 nodes were all just playing their favorite lotto numbers in their exit policy, they were being jerks. I am aware that every operator can sniff regardless of policy. Every operator can do a lot of things. The fact that even good exit policies can do bad things is not a necessary condition for allowing bad exit policies. Frankly, this in-your-face selfishness of *only* accepting the unencrypted data because fuck it, that's the only data I want to log just rubs me the wrong way. Not one of those 5 had legit contact info. Two of them actually bothered to fill out the field, but filled it in with a fake email address. All of them just wreak of disrespect for us, for the network, and for our users. Essentially, it's that disrespect that earned them the BadExit flag. If this means that sending the message to them means we take out a few irrational actors in the process, that's fine. I don't much want people playing lotto in their exit policies either. They can stick to middle node and put their lotto numbers in their contact info. I promise that it will work just as well. I will change my Exit Policy now to something like 80, 6667, 21 and if you BadExit it, you'll loose another fast node. *sigh*. And so the cat herding begins. Are you really protesting this policy decision with civil disobedience? Really? Fighting for Great Justice everywhere, eh? Do you have a rational reason why we should allow people to carry the unencrypted version of a service but not the encrypted one, other than Well, they could be bad actors even with a good policy! Or is it just because you feel that someone told to do something and you don't much like being told what to do, regardless of the reasoning? I forbid you from jumping in the nearest lake! I also forbid you from taking your freshly-gimped exit node in for a swim with you! -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpmdWraSdf96.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
On Sat, Jan 29, 2011 at 12:46 PM, Jan Weiher j...@buksy.de wrote: Hi, while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? I'm aware of the fact that it is not recommended to use tor without additional encryption, but some users do. And I dont see any reason for only allowing unencrypted traffic than snooping? Can anyone clearify this? If the admin of this node is on the list, would he please explain this situation? best regards, Jan It may possible be a middle node instead of an exit node. As for lack of contact info, can't answer that. I know there have been several other nodes in past without a contact info. Jon *** 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?
Am 29.01.2011 20:13, schrieb Jon: On Sat, Jan 29, 2011 at 12:46 PM, Jan Weiher j...@buksy.de wrote: Hi, while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? I'm aware of the fact that it is not recommended to use tor without additional encryption, but some users do. And I dont see any reason for only allowing unencrypted traffic than snooping? Can anyone clearify this? If the admin of this node is on the list, would he please explain this situation? best regards, Jan It may possible be a middle node instead of an exit node. As far as I understand the ExitPolicy, the first matching rule applies. Which means, that this is an Exit Node, at least for ports 21,80,110 and 143 to IP adresses that do not match the reject rules above the corresponding accept rules. Anyone is free to correct me if I'm wrong, but a middle node has only _one_ ExitPolicy which is reject *:*. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 2011-01-29 19:46, Jan Weiher wrote: while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? See: 'https://gitweb.torproject.org/arma/tor.git/blob_plain/03b9c2cb903cc59f83139039d963f1fdea99b83a:/doc/spec/dir-spec.txt' Exit -- A router is called an 'Exit' iff it allows exits to at least two of the ports 80, 443, and 6667 and allows exits to at least one /8 address space. Also: http://www.mail-archive.com/or-talk@freehaven.net/msg10275.html *** 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?
Am 29.01.2011 21:27, schrieb Gitano: On 2011-01-29 19:46, Jan Weiher wrote: while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? See: 'https://gitweb.torproject.org/arma/tor.git/blob_plain/03b9c2cb903cc59f83139039d963f1fdea99b83a:/doc/spec/dir-spec.txt' Exit -- A router is called an 'Exit' iff it allows exits to at least two of the ports 80, 443, and 6667 and allows exits to at least one /8 address space. Also: http://www.mail-archive.com/or-talk@freehaven.net/msg10275.html this explains why the status page does not list the node as an exit node. thanks. But as far as I understand, the node does not get the Exit-Flag, but it is still used for outgoing traffic on the accepted ports? So the main-question is still unanswered. best regars, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, 29 Jan 2011 19:46:20 +0100 Jan Weiher j...@buksy.de wrote: This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: It hasn't shown up in any of the exit scans as suspicious. Lack of contact info isn't a concern. The exit policy is odd, yes. However, arguably those are also very popular ports as well. -- Andrew pgp 0x74ED336B *** 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?
Am 29.01.2011 21:44, schrieb Andrew Lewman: On Sat, 29 Jan 2011 19:46:20 +0100 Jan Weiher j...@buksy.de wrote: This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: It hasn't shown up in any of the exit scans as suspicious. What kind of scans do you perform? I thought these scans do only check for content manipulation? I dont see how to recognize if the traffic is recorded? Lack of contact info isn't a concern. I think if you run one of the fastest nodes, it is at least very odd not to have a contact info. If you are concerned about your privacy, just go on and create a freemail account somewhere. The exit policy is odd, yes. However, arguably those are also very popular ports as well. Yeah, I'm not saying this is evil, but want to bring it into discussion, because I was unable to get any reasonable explanation for this exitpolicy. Of course these ports are popular, but 443 is popular as well? So for me it looked like pick all the popular _unencrypted_ ports. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, Jan 29, 2011 at 09:55:05PM +0100, j...@buksy.de wrote 1.3K bytes in 38 lines about: : What kind of scans do you perform? I thought these scans do only check : for content manipulation? I dont see how to recognize if the traffic is : recorded? https://gitweb.torproject.org/torflow.git/tree/HEAD:/NetworkScanners/ExitAuthority is the code. You are correct in that we cannot detect recording of traffic. : Yeah, I'm not saying this is evil, but want to bring it into : discussion, because I was unable to get any reasonable explanation for : this exitpolicy. : : Of course these ports are popular, but 443 is popular as well? So for me : it looked like pick all the popular _unencrypted_ ports. I agree, it does look that way. People can set ExcludeExitNodes for gatereloaded in their torrc. -- Andrew pgp key: 0x74ED336B *** 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/
Re: Is gatereloaded a Bad Exit?
One could argue that recording traffic goes against the spirit of the tor project and anonymity in general. But even if people do monitor the traffic as long as they don't control both nodes there is little chance that the end user can really be tracked. There is also an onus on the end user to still practice safe internet habits and be careful about still using SSL, when they are entering passwords, or doing similar sensitive things. Tor was not designed to make internet browsing safe in a general sense, rather it is meant to provide away around firewalls and censorship so that people can access the open internet without a fear of getting tracked as easy. -Andrew On Jan 29, 2011, at 8:56 PM, grarpamp wrote: 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/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote: 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. It's not realistic to think that people will maintain their own excludelists— a few extremists will, but the bulk of the users won't. Instead, I think that nodes which exit _only_ to the unencrypted version of a service (e.g. 80 but not 443) should be excluded from operating as exits entirely (except as enclaves). In this way these nodes would be force to pay their way. We can't stop them from sniffing, but at least we can make them carry traffic they can't sniff as part of the cost of doing their evil business. They could do things like severely throttle encrypted traffic, but that is activity that testing could detect. To some extent the exit flag criteria approximates this, but it's mostly a load balancing criteria and it's actually really easy to trick, even though this node has not successfully done so. (E.g. Accept 224/4:*) As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. *** 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?
Thus spake Gregory Maxwell (gmaxw...@gmail.com): On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote: I dont see how to recognize if the traffic is recorded? Various research groups occasionally experiment with using side channels for detecting recording exits. Their results are not usually reproducible, though (no source code, poor design, poor quality control, too easy to mitigate, etc). :/ They do occasionally find interesting stuff. But then they either publish, or get rejected, and then shut down their code and forget about it. Instead, I think that nodes which exit _only_ to the unencrypted version of a service (e.g. 80 but not 443) should be excluded from operating as exits entirely (except as enclaves). In this way these nodes would be force to pay their way. We can't stop them from sniffing, but at least we can make them carry traffic they can't sniff as part of the cost of doing their evil business. They could do things like severely throttle encrypted traffic, but that is activity that testing could detect. As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. I agree. We already have scripts to detect this, we just have not yet decided to actually use them yet. I believe we should. Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I believe we hould ban these 5 immediately, and consider banning the other 50 after issuing the appropriate announcements. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpE4kMVVEmo8.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake Mike Perry (mikepe...@fscked.org): Thus spake Gregory Maxwell (gmaxw...@gmail.com): As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. I agree. We already have scripts to detect this, we just have not yet decided to actually use them yet. I believe we should. Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I believe we hould ban these 5 immediately, and consider banning the other 50 after issuing the appropriate announcements. Sorry, the 5 are: NOTICE[Sat Jan 29 20:56:43 2011]:Nodes allowing plaintext but not secure: ElzaTorServer=009E71AED2C5580E942AC1743D1C440C5B2C459E QuantumSevero=4BF2F90E6E1905E2FB4F371E471422150D722A93 gatereloaded=550CC9724FA77C7F9260B93989D22A70654D3B92 oompaloompa=775DF6B8CF3FB0150A594F6E2B5CB1E0AC45D09B oompaloompa2=BABBF0694251E5AFF7BF3A0A02EFDC12CB99B05F -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpCgx8xgRqZn.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm missing something. Everyone that uses TOR should acknowlege that all data that doesn't use encryption before entering the TOR network. It's even in the FAQ (https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#CanexitnodeseavesdroponcommunicationsIsntthatbad) That means if I go to http://www.somewebsite.com I already acknowedge that someone out there could potentially be monitoring my traffic - regardless of whether I use TOR or not. In other words TOR does not claim to protect against this kind of attack. Furthermore we all acknowledge that any exit node could potentially be monitoring our unencrypted traffic (As Andrew stated earlier You are correct in that we cannot detect recording of traffic.) Finally there is no way that an exit node can directly affect the mode choices by a client. Ie, apart from a particular node existing, there is no way that a node could force a user to use it. Therefore I submit that having these nodes, whether they are overtly recording traffic or not, does not result in any harm to the TOR network. In fact, their presence lessens the burden on the TOR network as they are providing much needed bandwidth. In addition, if a user was to attempt to use encryption then another entirely separate exit node will be used instead (one that has a policy that allows traffic on the specific port) So the user isn't inconvenienced or forced to use an insecure protocol. So, what's the threat? Why are you considering banning these nodes when, by all accounts, I cannot see them having a negative impact on the network as a whole (in fact, it's probably a positive influence) FWIW, none of these nodes are mine. I used to run an exit node but I don't any longer (with my new Internet connection speeds it's not worth it) Eddie On Sun, Jan 30, 2011 at 15:57, Mike Perry mikepe...@fscked.org wrote: Thus spake Mike Perry (mikepe...@fscked.org): Thus spake Gregory Maxwell (gmaxw...@gmail.com): As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. I agree. We already have scripts to detect this, we just have not yet decided to actually use them yet. I believe we should. Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I believe we hould ban these 5 immediately, and consider banning the other 50 after issuing the appropriate announcements. Sorry, the 5 are: NOTICE[Sat Jan 29 20:56:43 2011]:Nodes allowing plaintext but not secure: ElzaTorServer=009E71AED2C5580E942AC1743D1C440C5B2C459E QuantumSevero=4BF2F90E6E1905E2FB4F371E471422150D722A93 gatereloaded=550CC9724FA77C7F9260B93989D22A70654D3B92 oompaloompa=775DF6B8CF3FB0150A594F6E2B5CB1E0AC45D09B oompaloompa2=BABBF0694251E5AFF7BF3A0A02EFDC12CB99B05F -- Mike Perry Mad Computer Scientist fscked.org evil labs -- Eddie Cornejo -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d? s: a C+++ UL+++ P++ L++ E- W+ N- o K- w++ O M-- V PS+ PE Y PGP++ t 5 X+ R tv-- b+ DI D++ G e++ h r+++ y --END GEEK CODE BLOCK-- *** 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?
Thus spake Eddie Cornejo (corn...@gmail.com): Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm missing something. Yeah, I believe you're missing the fact that these ports also contain plaintext passwords than can be used to gain access to information on these and other accounts that may or may not have ever traveled over tor. That is the difference. Finally there is no way that an exit node can directly affect the mode choices by a client. Ie, apart from a particular node existing, there is no way that a node could force a user to use it. See above. Therefore I submit that having these nodes, whether they are overtly recording traffic or not, does not result in any harm to the TOR network. In fact, their presence lessens the burden on the TOR network as they are providing much needed bandwidth. We don't need bandwidth that bad. So, what's the threat? Why are you considering banning these nodes when, by all accounts, I cannot see them having a negative impact on the network as a whole (in fact, it's probably a positive influence) I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpAhAbyOuyIb.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Howdy, Thanks for replying. Yeah, I believe you're missing the fact that these ports also contain plaintext passwords than can be used to gain access to information on these and other accounts that may or may not have ever traveled over tor. That is the difference. Actually, no I acknowledge that. I'm stating that this is a known position. Regardless of whether you ban these nodes or not, ALL nodes have the potential for reading unencrypted traffic. The FAQ I linked clearly mentions this. Finally there is no way that an exit node can directly affect the mode choices by a client. Ie, apart from a particular node existing, there is no way that a node could force a user to use it. See above. Above? I'm sorry but I don't think you've addressed this point. Exit node A can't force user Z to use it. We don't need bandwidth that bad. A matter of opinion, but I'll accept it. I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. Ok, I accept that this might send a message to 50ish nodes (if you ban all 50+) but if someone was so inclined they could still do this by allowing encrypted traffic and throttling it/blocking it outside of TOR (transparent proxy perhaps?) I predict this is worse as the user client will believe node A will honestly relay encrypted traffic and will select it on this basis, only to find their connection is slow or doesn't fully connect. Admitedly, this won't be a huge problem unless a good number of nodes started doing this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. My argument is that you're not identifying wolves. If you were serious about identifying wolves then could I suggest you create some dummy accounts, send your password through all exit nodes individually and see which of your accounts are accessed. This would positively identify wolves. All you're achieving by soley looking at exit policies is identifying things that may or may not be wolves and ignoring the larger body of exit nodes that may or may not include wolves. I submit your testing is flawed. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. I'm not sure I'm comfortable with dictating how an exit nodes exitpolicy should be defined. Each policy should be up to the exit node owner to decide. Just my 2c -- Eddie Cornejo -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d? s: a C+++ UL+++ P++ L++ E- W+ N- o K- w++ O M-- V PS+ PE Y PGP++ t 5 X+ R tv-- b+ DI D++ G e++ h r+++ y --END GEEK CODE BLOCK-- *** 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?
Thus spake Eddie Cornejo (corn...@gmail.com): I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. Ok, I accept that this might send a message to 50ish nodes (if you ban all 50+) but if someone was so inclined they could still do this by allowing encrypted traffic and throttling it/blocking it outside of TOR (transparent proxy perhaps?) I predict this is worse as the user client will believe node A will honestly relay encrypted traffic and will select it on this basis, only to find their connection is slow or doesn't fully connect. Admitedly, this won't be a huge problem unless a good number of nodes started doing this. We can detect nodes that fail encrypted connections. We currently scan for failure of port 443. We also detect throttling by virtue of our bw authorities measuring using 443. 443 is the second-most trafficed port by byte on the Tor network, occupying only ~1% of the traffic. If stingy exit nodes really want to waste hours to pinch pennies from their malicious exit policy, they can try crafting a throttling policy that we can't detect. Seems like there are better ways to spend their time. Like reading other people's email. So no, I'm not terribly concerned about second-order effects of this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. My argument is that you're not identifying wolves. If you were serious about identifying wolves then could I suggest you create some dummy accounts, send your password through all exit nodes individually and see which of your accounts are accessed. This would positively identify wolves. All you're achieving by soley looking at exit policies is identifying things that may or may not be wolves and ignoring the larger body of exit nodes that may or may not include wolves. I submit your testing is flawed. We're not trying to identify wolves. We are sending a message to the community. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. I'm not sure I'm comfortable with dictating how an exit nodes exitpolicy should be defined. Each policy should be up to the exit node owner to decide. Just my 2c Not really. In reality, it's up to those who write the code to decide what is available and how it works ;). Welcome to The Golden Path. At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpFPYPp83NMq.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Jan Weiher wrote: Of course these ports are popular, but 443 is popular as well? So for me it looked like pick all the popular _unencrypted_ ports. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ Maybe the owner of that node is just only a lamer? *** 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?
grarpamp wrote: 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/ Is it a serious problem if some of owners of tor-nodes record the exit traffic? It seems to me that the Govermental bodies can do it instead of them and they probably do it in such countries as the US or Germany and etc. If the first is serious problem, why the last is not one? *** 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?
Gregory Maxwell wrote: On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote: Instead, I think that nodes which exit _only_ to the unencrypted version of a service (e.g. 80 but not 443) should be excluded from operating as exits entirely (except as enclaves). In this way these nodes would be force to pay their way. We can't stop them from sniffing, but at least we can make them carry traffic they can't sniff as part of the cost of doing their evil business. They could do things like severely throttle encrypted traffic, but that is activity that testing could detect. Where I can read what it means a bad exit? Earlier I thought that it is and exit which works wrong in something. And I thought that them excludes from routing. But I pereodically can see that my client establish connections through bad exits. Have I to need do something from preventing it for protection of my anonimity? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
