subject:""

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/

Please Badexit:

Hi,

please BadExit the following nodes (for the same reason you badexit'ed
gatereloaded et al. - no valid contact info, they didn't explain their
exit policy to us, I suspect they are sniffing unencrypted Exit
traffic):

TORy0 - 753e0b5922e34bf98f0d21cc08ea7d1adeee2f6b
TORy2 - f08f537d245a65d9c242359983718a19650a25f7
st0nerhenge - c2f9d30118bebf3efee6d96252374082ca73c054
vivalarevolution - 29448afd5251b60a44fc79f4414423e7d026500d

Thanks in advance!

morphium
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Please Badexit:

2011-02-15 Thread Mike Perry

Thus spake morphium (morph...@morphium.info):

 Hi,
 
 please BadExit the following nodes (for the same reason you badexit'ed
 gatereloaded et al. - no valid contact info, they didn't explain their
 exit policy to us, I suspect they are sniffing unencrypted Exit
 traffic):
 
 TORy0 - 753e0b5922e34bf98f0d21cc08ea7d1adeee2f6b
 TORy2 - f08f537d245a65d9c242359983718a19650a25f7

These are running a slightly modified default exit policy. They allow
443. They are fine by me.

 st0nerhenge - c2f9d30118bebf3efee6d96252374082ca73c054

Funny you should mention this node. A researcher flagged it once in a
test to detect sniffing, but was not able to reproduce it later. Maybe
they just turned off their sniffer and got lucky :). There were also
serious issues with the methodology though, and it may have been a bug
in the scanning technique.

However, at this point we are only going after nodes that carried
unencrypted versions of both mail *and* web. The reason we did this
was because another researcher actually detected another node that he
*was* able to reproduce. It had this exact type of exit policy. It
calls itself 'agitator'.

When we found that sniffer, we looked for other exit policies similar
to that one, and found the five here that caused so much controversy.

We probably should have came out with all this earlier, but the
researcher requested we keep their methodology secret until
publication. It also needs some work in the reproducibility dept...

At any rate, this node appears to (now?) carry 443. Did it's policy
just change?

 vivalarevolution - 29448afd5251b60a44fc79f4414423e7d026500d

Same as Tory0.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs


pgp5dLfYdFjyX.pgp
Description: PGP signature

Balancing?

2011-02-15 Thread Jon

With the latest TOR version and the increased in nodes, with the new
balancing in the new version, does it mean that it would be possible
that the volume load would have been decrease from what it was on some
of the nodes?

Maybe a better explanation I am trying to ask is before the updated
version, the amt of band usage was a lot higher than it is now. I
suspect with the more nodes we have n ow that might explain some of us
not being used like we were, but does the new balancing be making that
adjustment also by distributing the users thru out the nodes better?.

Hopefully that explains it better what I am trying to ask.

Jon
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Please Badexit:

2011/2/15 Mike Perry mikepe...@fscked.org:
 Thus spake morphium (morph...@morphium.info):

 Hi,

 please BadExit the following nodes (for the same reason you badexit'ed
 gatereloaded et al. - no valid contact info, they didn't explain their
 exit policy to us, I suspect they are sniffing unencrypted Exit
 traffic):

 TORy0 - 753e0b5922e34bf98f0d21cc08ea7d1adeee2f6b
 TORy2 - f08f537d245a65d9c242359983718a19650a25f7

 These are running a slightly modified default exit policy. They allow
 443. They are fine by me.

Oh why? They modified the exit policy and didn't explain here why. And
they allow 80 (unencrypted HTTP as you know) as unecrypted mail ports.
I think they should be definitely blacklisted!

morphium
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Please Badexit:

2011-02-15 Thread Mike Perry

Thus spake morphium (morph...@morphium.info):

 2011/2/15 Mike Perry mikepe...@fscked.org:
  please BadExit the following nodes (for the same reason you badexit'ed
  gatereloaded et al. - no valid contact info, they didn't explain their
  exit policy to us, I suspect they are sniffing unencrypted Exit
  traffic):
 
  TORy0 - 753e0b5922e34bf98f0d21cc08ea7d1adeee2f6b
  TORy2 - f08f537d245a65d9c242359983718a19650a25f7
 
  These are running a slightly modified default exit policy. They allow
  443. They are fine by me.
 
 Oh why? They modified the exit policy and didn't explain here why. And
 they allow 80 (unencrypted HTTP as you know) as unecrypted mail ports.
 I think they should be definitely blacklisted!

I think you've become a troll. Sorry 'bout it, man.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs


pgpRVngQRF0W0.pgp
Description: PGP signature

Re: Please Badexit:

2011/2/15 Mike Perry mikepe...@fscked.org:
 I think you've become a troll. Sorry 'bout it, man.

I think you just noticed in the mirror, how irrational your decision
to BadExit gatereloaded et al. was.

Thank 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?

2011-02-15 Thread Aplin, Justin M


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?

2011-02-15 Thread cmeclax-sazri

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: Scroogle and Tor

2011-02-15 Thread Robert Hogan

On Tuesday 15 February 2011 05:20:21 Mike Perry wrote:
 
 I was under the impression that we hacked it to also be memory-only,
 though. But you're right, if I toggle Torbutton to clear my cache,
 Polipo's is still there...

The polipo shipped in the tor bundles has the cache turned off, but any 
non-Windows users will tend to use the polipo shipped by their distro - 
with caching turned on.

***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Contacted by oompaloompa operator: BadExit removed

2011-02-15 Thread Mike Perry

I was contacted by the operator of oompaloompa. He has changed the
exit policy of his two nodes to the Reduced policy:
http://torstatus.blutmagie.de/router_detail.php?FP=775df6b8cf3fb0150a594f6e2b5cb1e0ac45d09b
http://torstatus.blutmagie.de/router_detail.php?FP=babbf0694251e5aff7bf3a0a02efdc12cb99b05f

He said that he started those two nodes as a test to experiment with
Tor, and picked the exit policy quickly off the top of his head,
keeping it brief because it was tedious to write.

He also gave the following reasons why one might want an exit policy
like this (though he said none of these were his reasons):

1. Crypto may not be legal

The problem with this is that Tor is already pumping a ton of crypto
that was designed to look as much like web TLS as possible. Chaning
your exit policy doesn't really help this.

2. IDSs could prevent attacks

This would be a great idea in theory, if it ever worked. In practice,
IDSs end up being censorship devices for security mailinglists,
exploit advisory info, and other information on computer security.
We've actually already BadExited quite a few of these types of nodes,
because our exit scanner detects the censorship.

3. Plausible deniability due to eliminating additional TLS fingerprints

This is an interesting one, and I think I misread what he meant when
he first said it, but if it means not having the additional TLS
fingerprints of tor client traffic so that your TLS traffic doesn't
stand out in the Tor noise, I don't think this works out for you. You
end up being obvious because your node would not exit to any TLS
ports.


At any rate, because the Exit Policy has changed, I've personally
updated my authority to remove the BadExit. I believe we're still
waiting on one of Roger or Peter.



-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs


pgp1tsUugpdRp.pgp
Description: PGP signature

Mailing list transition [archives]

2011-02-14 Thread grarpamp

Can someone make sure all the new lists get submitted/added
to markmail?

As official archives in Maildir or Mbox are not yet provided (under
the curious guise of spam prevention), some alternative indexes
to the ones provided by the list engine would be valuable to
the community.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Scroogle and Tor

Thus spake Matthew (pump...@cotse.net):

 On 13/02/11 19:09, scroo...@lavabit.com wrote:
 I've been fighting two different Tor users for a week. Each is
 apparently having a good time trying to see how quickly they
 can get results from Scroogle searches via Tor exit nodes.
 The fastest I've seen is about two per second. Since Tor users
 are only two percent of all Scroogle searches, I'm not adverse
 to blocking all Tor exits for a while when all else fails.
 These two Tor users were rotating their search terms, and one
 also switched his user-agent once. You can see why I might be
 tempted to throw my block all Tor switch on occasion --
 sometimes there's no other way to convince the bad guy that
 he's not going to succeed.
 
 For the less than knowledgeable people amongst us (e.g me) who want to 
 learn a bit more: what was the rationale for those two Tor users doing what 
 they did?  What do they get from it?

I second this.

Daniel,

If you can find a way to fingerprint these bots, my suggestion would
be to observe the types of queries they are running (perhaps for some
of their earlier runs from when you could ban them by user agent?).

One of the things Google does is actually decide your 'Captchaness'
based on the content of your queries. Well, at least I suspect that's
what they are doing, because I have been able to more reliably
reproduce torbutton Captcha-related bugs when I try hard to write
queries like robots that are looking for php sites to exploit.

I would love to hear more about the types of scrapers that abuse Tor.
Or rather, I would like to see if someone can at least identify
rational behavior behind scrapers that abuse Tor. Some of it could
also be misdirected malware that is operating from within Torified
browsers. Some of it could also be deliberately torified malware.

Google won't tell us any of this, obviously ;).


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs


pgpVxq8YphoPj.pgp
Description: PGP signature

Re: Scroogle and Tor

2011-02-14 Thread Jim


scroo...@lavabit.com wrote:

I've been fighting two different Tor users for a week. Each is
apparently having a good time trying to see how quickly they
can get results from Scroogle searches via Tor exit nodes. 
[snip]


As the person who (recently) raised the question about the availability 
of Scroogle via Tor, I want to thank you both for running Scroogle and 
for coming on this list to explain what happened.  I also apologize to 
the list for not mentioning that Scroogle is once again available via 
Tor.  (I discovered that and meant to publish that fact aprox. 24 hours 
ago.)


You are obviously much more knowledgable about network issues than I am 
so I will leave it to others to advise you about possible mitigations 
for your problems.  It is a real shame about the script kiddies, but 
such is the world we live in.


Jim


***
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-02-14 Thread grarpamp

 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?

2011-02-14 Thread morphium

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?

2011-02-14 Thread Olaf Selke

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?

2011-02-14 Thread Damian Johnson

 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?

2011-02-14 Thread morphium

 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?

2011-02-14 Thread Ted Smith

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?

2011-02-14 Thread John Case



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/

dir-spec.txt and directory-signature entries

2011-02-14 Thread J

The final entries in a consensus document are a number of directory-
signature entries.

dir-spec.txt says:

cite

  directory-signature SP identity SP signing-key-digest NL Signature

This is a signature of the status document, with the initial item
network-status-version, and the signature item
directory-signature, using the signing key.  (In this case, we
take
the hash through the _space_ after directory-signature, not the
newline: this ensures that all authorities sign the same thing.)
identity is the hex-encoded digest of the authority identity
key of
the signing authority, and signing-key-digest is the hex-encoded
digest of the current authority signing key of the signing
authority.

/cite

Does that mean The hash from the network-status-version entry to the
*first* directory-signature entry including a SP?

Or something else? The wording in dir-spec.txt is ambigous to me.

Any help appreciated.

Cheers
/Jocke
***
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-02-14 Thread Julie C

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: dir-spec.txt and directory-signature entries

2011-02-14 Thread Joakim G.

On 2011-02-14 19:46, Nick Mathewson wrote:

snip/


 Does that mean The hash from the network-status-version entry to the
 *first* directory-signature entry including a SP?
 
 It means everything beginning with the string network-status-version
 and ending with the first string directory-signature .  This refers
 to the _string_ directory signature  (with included space), not to
 the entire directory signature.  (It _can't_ refer to the entire
 directory signature, since when the authority computes the signature,
 it doesn't know what the signature is going to be.)

Yes, that was my understanding as well. Thanks for the clarification.

I looked elsewhere in my code and realised that the shared signature
code added an extra \n after directory-signature  when verifying
consensus documents. I got extremely confused because I could verify
both router descriptor and key certificate documents.

In other words: My bad, i.e. I needed someone to talk to. :-)

Sorry for the noise

Cheers
/Jocke
***
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-02-14 Thread Ted Smith

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?

2011-02-14 Thread Aplin, Justin M


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?

2011-02-14 Thread cmeclax-sazri

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?

2011-02-14 Thread John Case



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?

2011-02-14 Thread Ansgar Wiechers

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?

2011-02-14 Thread Gregory Maxwell

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/

ToR: A network by/for ToR admins

2011-02-14 Thread John Case



On Mon, 14 Feb 2011, Gregory Maxwell wrote:


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.



Thank you, thank you.  It took some time and some goading, but we've 
finally arrived:


ToR will be used the way we think it should be.

That's all I needed to hear.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Scroogle and Tor

2011-02-14 Thread scroogle

Some have wondered why anyone would want to abuse Scroogle
using Tor. Apart from some malicious types that may be
doing it for their own amusement, it looks to me like they
are trying to datamine Google -- arguably the largest,
most diverse database on the planet.

If you can manage to run a script 24/7 that datamines
Google, you can monetize your results. Search engine
optimizers would like to be able to do this. So would
various directory builders.

Doing it by scraping google.com directly is not easy.
Scroogle provides 100 links of organic results per
request, with less than one-half the byte-bloat that
Google delivers for the same links and snippets. It is
also much easier to parse Scroogle's simple output page
than it is to parse Google's output page.

I spend a couple hours per day blocking abusers. A huge
amount of this is done through a couple dozen monitoring
programs I've written, but for the most part these
programs provide candidates for blocking only, and
my wetware is needed to make the final determination.

My efforts to counter abuse occasionally cause some
programmers to consider using Tor to get Scroogle's
results. About a year ago I began requiring any and all
Tor searches at Scroogle to use SSL. Using SSL is always
a good idea, but the main reason I did this is that the
SSL requirement discouraged script writers who didn't
know how to add this to their scripts. This policy
helped immensely in cutting back on the abuse I was
seeing from Tor.

Now I'm seeing script writers who have solved the SSL
problem. This leaves me with the user-agent, the search
terms, and as a last resort, blocking Tor exit nodes.
If they vary their search terms and user-agents, it can
take hours to analyze patterns and accurately block them
by returning a blank page. That's the way I prefer to do
it, because I don't like to block Tor exit nodes. Those
who are most sympathetic with what Tor is doing are also
sympathetic with what Scroogle is doing. There's a lot of
collateral damage associated with blocking Tor exit nodes,
and I don't want to alienate the Tor community except as
a last resort.

One reason why Scroogle has lasted for more than six
years is that we are nonprofit, and Google knows by now
that I don't tolerate abuse. My job is to stop the abuser
before Scroogle passes their search terms to Google.
Abusers who use Tor make this more difficult for me.
Blocking an IP address is easy, but blocking Tor abusers
without alienating other Tor users is more complex.

-- Daniel Brandt



***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Scroogle and Tor

2011-02-14 Thread thecarp

On 02/14/2011 06:29 PM, scroo...@lavabit.com wrote:
 Some have wondered why anyone would want to abuse Scroogle
 using Tor. Apart from some malicious types that may be
 doing it for their own amusement, it looks to me like they
 are trying to datamine Google -- arguably the largest,
 most diverse database on the planet.

Makes a lot of sense. Actually, can hardly blame them for wanting to
mine the data. Of course, you make it pretty easily available, as you
detail. I can see why this starts to present a problem.
 I spend a couple hours per day blocking abusers. A huge
 amount of this is done through a couple dozen monitoring
 programs I've written, but for the most part these
 programs provide candidates for blocking only, and
 my wetware is needed to make the final determination.

Ouch, that really sucks... time like that adds up fast.

 Now I'm seeing script writers who have solved the SSL
 problem. This leaves me with the user-agent, the search
 terms, and as a last resort, blocking Tor exit nodes.
 If they vary their search terms and user-agents, it can
 take hours to analyze patterns and accurately block them
 by returning a blank page. That's the way I prefer to do
 it, because I don't like to block Tor exit nodes. Those
 who are most sympathetic with what Tor is doing are also
 sympathetic with what Scroogle is doing. There's a lot of
 collateral damage associated with blocking Tor exit nodes,
 and I don't want to alienate the Tor community except as
 a last resort.


Well...google uses the captcha system. Hard to say how well that works.
I doubt anything too simple is going to work here, for many reasons,
including the ones that you specify. How about this... we know you can
(mostly reliably) detect tor exits.

I think you have your goals wrong. You don't need to stop the scripts
from getting to google, even google can't stop that on their own site.
What you need is to make abusive use unprofitable on a scale that matters.

Tor users care about their privacy right... but you need a way to
differentiate them. So how about a temporary registration system? I get
sent to a page with a captcha (or two kinds even). If I pass, then I get
a token (set in a cookie, or put in the query string) that lets me do
searches. Maybe I can set when it should expire (up to a max) maybe
put in a 30 second timeout before it becomes active. (slow them down
some more)... maybe limit the rate per ip over time for registrations?

Secondly, have you considered poisoning their stream? If you detect an
obvious abusive script, return randomized cached results. Ruining their
work, rather than just slowing them down, might convince them to move on
and try somewhere else. It is a thought anyway.

 One reason why Scroogle has lasted for more than six
 years is that we are nonprofit, and Google knows by now
 that I don't tolerate abuse. My job is to stop the abuser
 before Scroogle passes their search terms to Google.
 Abusers who use Tor make this more difficult for me.
 Blocking an IP address is easy, but blocking Tor abusers
 without alienating other Tor users is more complex.

It will be sad to see tor users lose your service (I actually had only
heard the name before this thread, very curious to check it out now).

-Steve

***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Scroogle and Tor

Thus spake scroo...@lavabit.com (scroo...@lavabit.com):

 My efforts to counter abuse occasionally cause some
 programmers to consider using Tor to get Scroogle's
 results. About a year ago I began requiring any and all
 Tor searches at Scroogle to use SSL. Using SSL is always
 a good idea, but the main reason I did this is that the
 SSL requirement discouraged script writers who didn't
 know how to add this to their scripts. This policy
 helped immensely in cutting back on the abuse I was
 seeing from Tor.
 
 Now I'm seeing script writers who have solved the SSL
 problem. This leaves me with the user-agent, the search
 terms, and as a last resort, blocking Tor exit nodes.
 If they vary their search terms and user-agents, it can
 take hours to analyze patterns and accurately block them
 by returning a blank page. That's the way I prefer to do
 it, because I don't like to block Tor exit nodes. Those
 who are most sympathetic with what Tor is doing are also
 sympathetic with what Scroogle is doing. There's a lot of
 collateral damage associated with blocking Tor exit nodes,
 and I don't want to alienate the Tor community except as
 a last resort.

Great, now that we know the motivations of the scrapers and a history
of the arms race so far, it becomes a bit easier to try to do some
things to mitigate their efforts. I particularly like the idea of
feeding them random, incorrect search results when you can fingerprint
them.


If you want my suggestions for next steps in the arms race for this,
(having written some benevolent scrapers and web scanners myself), it
would actually be to do things that require your adversary to
implement and load more and more bits of a proper web browser into
their crawlers for them to succeed in properly issuing queries to you.

Some examples:

1. A couple layers of crazy CSS.

If you use CSS style sheets that fetch other randomly generated and
programmatically controlled style elements that are also keyed to the
form submit for the search query (via an extra hidden parameter or
something that is their hash), then you can verify on your server side
that a given query also loaded sufficient CSS to be genuine. 

The problem with this is it will mess with people who use your search
plugin or search keywords, but you could also do it in a brief landing
page that is displayed *after* the query, but before a 302 or
meta-refresh to actual results, for problem IPs.

2. Storing identifiers in the cache

http://crypto.stanford.edu/sameorigin/safecachetest.html has some PoC
of this. Torbutton protects against long-term cache identifiers, but
for performance reasons the memory cache is enabled by default, so you
could use this to differentiate crawlers who do not properly obey all
brower caching sematics. Caching is actually pretty darn hard to get
right, so there's probably quite a bit more room here than just plain
identifiers.

3. Javascript proof of work

If the client supports javascript, you can have them factor some
medium-sized integers and post the factorization with the query
string, to prove some level of periodic work. The factors could be
stored in cookies and given a lifetime. The obvious downside of this
is that I bet a fair share of your users are running NoScript, or
prefer to disable js and cookies.


Anyways, thanks for your efforts with Scroogle. Hopefully the above
ideas are actually easy enough to implement on your infrastructure to
make it worth your while to use for all problem IPs, not just Tor.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs


pgpDQruQ8zLhC.pgp
Description: PGP signature

Re: Scroogle and Tor

2011-02-14 Thread Robert Ransom

On Mon, 14 Feb 2011 20:19:50 -0800
Mike Perry mikepe...@fscked.org wrote:

 2. Storing identifiers in the cache
 
 http://crypto.stanford.edu/sameorigin/safecachetest.html has some PoC
 of this. Torbutton protects against long-term cache identifiers, but
 for performance reasons the memory cache is enabled by default, so you
 could use this to differentiate crawlers who do not properly obey all
 brower caching sematics. Caching is actually pretty darn hard to get
 right, so there's probably quite a bit more room here than just plain
 identifiers.

Polipo monkey-wrenches Torbutton's protection against long-term cache
identifiers.


Robert Ransom


signature.asc
Description: PGP signature

Re: Scroogle and Tor

Thus spake Robert Ransom (rransom.8...@gmail.com):

 On Mon, 14 Feb 2011 20:19:50 -0800
 Mike Perry mikepe...@fscked.org wrote:
 
  2. Storing identifiers in the cache
  
  http://crypto.stanford.edu/sameorigin/safecachetest.html has some PoC
  of this. Torbutton protects against long-term cache identifiers, but
  for performance reasons the memory cache is enabled by default, so you
  could use this to differentiate crawlers who do not properly obey all
  brower caching sematics. Caching is actually pretty darn hard to get
  right, so there's probably quite a bit more room here than just plain
  identifiers.
 
 Polipo monkey-wrenches Torbutton's protection against long-term cache
 identifiers.

I hate polipo. I've been trying ignore it until it fucking dies. But
it's like a zombie that just won't stop gnawing on our brains. Worse,
a crack smoking zombie that got us all addicted to it through second
hand crack smoke. Or something. But hey, it's better than privoxy.
Maybe?

I was under the impression that we hacked it to also be memory-only,
though. But you're right, if I toggle Torbutton to clear my cache,
Polipo's is still there...


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs


pgpgDTEhULdw5.pgp
Description: PGP signature

Re: Yet another UDP / DNS quiestion...

 Yes if you redirect DNS requests to Tor's DNSPort you should be safe
 against DNS leaks.

Do I have to use AutomapHostsOnResolve 1 as well? Seems to be pointless
without defining AutomapHostsSuffixes.

 I guess you are talking about a local setup without a middlebox
 involved. If my assumption is correct you want to refer to the
following
 section in the document:

https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy#LocalRedirectionThroughTor
 

Thanks for clarifying that! Now I need to read some more about iptables.
One more question: will those rules route all UDP traffic to port 53 or
just DNS requests? What will happen with UDP not relating to DNS?

-- 
Tomasz Moskal ramshackle.industr...@gmail.com
Encrypted mail preferred. Key ID: 2C323C82





signature.asc
Description: This is a digitally signed message part

Re: Yet another UDP / DNS quiestion...

On 02/13/2011 03:20 PM, Tomasz Moskal wrote:
 Do I have to use AutomapHostsOnResolve 1 as well? Seems to be pointless
 without defining AutomapHostsSuffixes.

No it is not pointless because also if you do not use
AutomapHostsSuffixes in your config .exit and .onion are
AutomapHostsSuffixes per default.

 One more question: will those rules route all UDP traffic to port 53 or
 just DNS requests? What will happen with UDP not relating to DNS?

The UDP rules in the LocalRedirectionThroughTor section:
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy#LocalRedirectionThroughTor

redirect only UDP packets with destination port 53 (usually DNS
requests) to the DNSPort. All other outgoing UDP traffic is
blocked/rejected with the last rule:
iptables -A OUTPUT -j REJECT

The penultimate rule:
iptables -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT
would allow a program running with the $TOR_UID to send UDP traffic.

I will suggest to add -p tcp to that rule.


***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Excluding exit nodes

From the Tor Project FAQ
https://www.torproject.org/docs/faq#ChooseEntryExit:

We recommend you do not use these — they are intended for testing and
may disappear in future versions. You get the best security that Tor can
provide when you leave the route selection to Tor; overriding the
entry / exit nodes can mess up your anonymity in ways we don't
understand.

Now, it's a little bit confusing for a novice, let me explain why.
People both on this mailing list and else where on the Internet are
often referring to excluding bad/evil exit nodes (I'm aware that it's
a bit ambiguous concept) and yet there is this entry in Tor Project FAQ.
So how someone like me, a newcomer to Tor, Linux and networking, should
know which exit nodes are suspicious? I came across this website
http://torstatus.blutmagie.de/index.php which flags couple of nodes as
Bad Exit - should I exclude them? How reliable information on this
website are? Is there any authoritative list of suspicious exit nodes?

-- 
Tomasz Moskal ramshackle.industr...@gmail.com
Encrypted mail preferred. Key ID: 2C323C82




signature.asc
Description: This is a digitally signed message part

Re: Excluding exit nodes

On 02/13/2011 03:43 PM, Tomasz Moskal wrote:
 Now, it's a little bit confusing for a novice, let me explain why.
 People both on this mailing list and else where on the Internet are
 often referring to excluding bad/evil exit nodes (I'm aware that it's
 a bit ambiguous concept) and yet there is this entry in Tor Project FAQ.

The config directive ChooseEntryExit should not be confused with
ExcludeExitNodes.

 So how someone like me, a newcomer to Tor, Linux and networking, should
 know which exit nodes are suspicious? I came across this website
 http://torstatus.blutmagie.de/index.php which flags couple of nodes as
 Bad Exit - should I exclude them? 

No you do not need to exclude them because your client will not use
nodes with the BadExit flag as an exit node anyway. The torstatus
website does not flag them, it just shows you that they have this flag
because the DirectoryAuthorities flagged these nodes as badexits.




***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Excluding exit nodes

On Sun, 2011-02-13 at 15:51 +0100, tagnaq wrote:
 No you do not need to exclude them because your client will not use
 nodes with the BadExit flag as an exit node anyway. The torstatus
 website does not flag them, it just shows you that they have this flag
 because the DirectoryAuthorities flagged these nodes as badexits.

Now I'm even more confused! What is DirectoryAuthorities? Quick
googling yielded no results I can understand and Tor -alpha Manual is
not helpful on that matter either. Could you point me somewhere I can
find more informations about matters relating to exit nodes? I'm going
through archives of this mailing list and documents on Tor website but
there is *a lot* of informations in those places and it will take me
considerable amount of time to read all of it.

How someone can recognise if an exit node *might* be doing something
suspicious - like sniffing traffic for passwords? As far as I can tell
(with my limited knowledge that is!) it's by checking which ports the
node in question is making available. And if there are not the standards
one then it *could* do something nasty - which of course don't mean it
does. Could you clarify this whole rouge/bad/evil nodes matter?

-- 
Tomasz Moskal ramshackle.industr...@gmail.com
Encrypted mail preferred. Key ID: 2C323C82




signature.asc
Description: This is a digitally signed message part

Re: Excluding exit nodes

On 02/13/2011 04:19 PM, Tomasz Moskal wrote:
 Now I'm even more confused! What is DirectoryAuthorities?
 Could you point me somewhere I can
 find more informations about matters relating to exit nodes?

https://www.torproject.org/docs/faq.html.en#KeyManagement
(Coordination section)

General Design Document:
https://www.torproject.org/docs/documentation.html.en#DesignDoc
https://svn.torproject.org/svn/projects/design-paper/tor-design.html
(chapter 6.3)
Note: This document is from 2004. Statements like new nodes must be
approved by the directory server administrator before they are included
are no longer valid.

https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l142

 How someone can recognise if an exit node *might* be doing something
 suspicious - like sniffing traffic for passwords? As far as I can tell
 (with my limited knowledge that is!) it's by checking which ports the
 node in question is making available. And if there are not the standards
 one then it *could* do something nasty - which of course don't mean it
 does. Could you clarify this whole rouge/bad/evil nodes matter?

Well this is currently a 'hot topic' and I refer you to the lengthy
thread 'Is gatereloaded a Bad Exit?'.
Short answer: you can not reliably detect passive sniffing.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Excluding exit nodes

On Sun, 2011-02-13 at 17:07 +0100, tagnaq wrote:
 https://www.torproject.org/docs/faq.html.en#KeyManagement
 (Coordination section)
 
 General Design Document:
 https://www.torproject.org/docs/documentation.html.en#DesignDoc
 https://svn.torproject.org/svn/projects/design-paper/tor-design.html
 (chapter 6.3)
 Note: This document is from 2004. Statements like new nodes must be
 approved by the directory server administrator before they are
included
 are no longer valid.
 

https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l142

Wow! This will keep me busy for quite a while! Thanks!

 Well this is currently a 'hot topic' and I refer you to the lengthy
 thread 'Is gatereloaded a Bad Exit?'.
 Short answer: you can not reliably detect passive sniffing.

Yes, I'm following 'Is gatereloaded a Bad Exit?' but at times it's
*very* confusing. Well, I won't worry about exit nodes until I won't
have better understanding of Tor and networking in general.

-- 
Tomasz Moskal ramshackle.industr...@gmail.com
Encrypted mail preferred. Key ID: 2C323C82





signature.asc
Description: This is a digitally signed message part

Re: Excluding exit nodes

2011-02-13 Thread Aplin, Justin M


On 2/13/2011 10:19 AM, Tomasz Moskal wrote:
[snip]

How someone can recognise if an exit node *might* be doing something
suspicious - like sniffing traffic for passwords? As far as I can tell
(with my limited knowledge that is!) it's by checking which ports the
node in question is making available. And if there are not the standards
one then it *could* do something nasty - which of course don't mean it
does. Could you clarify this whole rouge/bad/evil nodes matter


I think it's worth mentioning that as an end-user you might be focusing 
on the wrong issues here. While there *may* be some nodes (exactly which 
is perpetually unknown) that record unencrypted traffic, it's more 
important to make sure that your private data (such as login 
credentials, text containing your whereabouts, etc) is encrypted 
end-to-end than to worry about excluding every possibly bad exit node. 
For example, it's much easier to use the https version of a website 
instead of http to protect a username/password combination than it would 
be to hunt down anyone who might be trying to record your http 
connection (as recording the encrypted https traffic would yield them 
nothing). The same logic applies to other tools as well, examples being 
using the encrypted ssh and sftp over telnet and ftp, respectively.


See 
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#CanexitnodeseavesdroponcommunicationsIsntthatbad 
if you haven't already.


To answer your other question, as I understand it, the traditional 
definition of bad exit nodes has been ones that manipulate (actually 
change, rather than simply record) data as they pass through the node. 
These nodes are automatically awarded the BadExit flag and are not 
used as exits, so the end-user need not worry about them. Exactly 
whether using an asinine exit polixy should cause a node to be 
considered malicious has been a point of argument over the last week or 
so here, and relates only to the sniffing of unencrypted traffic. So 
again, make sure to use encrypted protocols wherever possible, and don't 
send any personally-identifiable information when forced to use 
unencrypted protocols, and you should be fine.


Others will be better able to answer the other questions you had. Good 
luck, and stay safe!


~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: Excluding exit nodes

2011-02-13 Thread Gregory Maxwell

On Sun, Feb 13, 2011 at 11:39 AM, Tomasz Moskal
ramshackle.industr...@gmail.com wrote:
[snip]
 Would you recommend using not Tor connection when one is forced to use
 unencrypted protocols? I think I'm safer using Tor even with unencrypted
 traffic that using regular connection but again I can be gravely wrong
 here. What do you think?

This depends on the network near you and what risks you're worried
about being safe from.

If you're concerned about anonymity then sure, tor should pretty much
always be safer. (Though will you have anonymity when you're logging
in? It depends…)

As for security against eavesdropping— I think you can say that tor is
more secure in that regard than a network where you _know_ it's
happening, and less secure against that than most networks where you
are unsure.

In some cases, however, even if eavesdropping is happening it's better
if the eavesdropper is someone socially/geographically far away.  I
might be more happy about someone in japan, who mostly just wants my
passwords, reading my private messages than the sysadmin at the local
ISP who knows some of my friends personally.  Eavesdropping is also
usually far less damaging if the traffic has been successfully
anonymized.

Really, it comes down to this:  If you do not use end to end
encryption your traffic can be monitored or manipulated by a great
many people— by hackers with access to the network between you and the
other end, by the staff of network providers, potentially by
commercial agencies that ISPs have sold feeds of customer data to, by
governments along the path, etc. This is true regardless of Tor.  If
you use Tor than the people who can do these things are changed (e.g.
some other ISP instead of yours) and possibly increased (the exit
operator might be doing something nasty).

What Tor provides is the aspects of privacy that encryption can't get
you, but it doesn't replace end to end encryption.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Yet another UDP / DNS quiestion...

On 02/13/2011 05:21 PM, Tomasz Moskal wrote:
 OK, so to wrap it all up last (hopefully!) couple of questions...
 
 iptables script/rules set:
 
 #!/bin/sh
 
 # the UID Tor runs as
 TOR_UID=109
 
 iptables -F
 iptables -t nat -F
 
 # Redirects DNS traffic to the local port 53
 iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53
 
 # Allow a program running with the $TOR_UID to send UDP traffic
 iptables -A OUTPUT -p udp -m owner --uid-owner $TOR_UID -j ACCEPT
Why did you add -p udp here? Tor uses TCP.

 # Block/reject all outgoing UDP traffic
 iptables -A OUTPUT -j REJECT
This rule does not block UDP only, it rejects all traffic including UDP
(if a packets makes its way to the last line).

If this is your full iptables setup it doesn't make much sense to me.
You might have misunderstood my earlier reply.

But lets go one step back:
I'm wondering why one would want to setup DNSPort configuration without
TransPort.
I see two obvious use cases but neither matches yours:

scenario 1)
firefox+polipo+torbutton enabled
in such a setup there is no need for DNSPort + iptables if you are only
worried about firefox traffic

scenario 2)
you want to route all TCP traffic through Tor:
setup includes TransPort + DNSPort Setup (to prevent DNS leaking) +
iptables rules + Torbutton (transparent torification setting)

Could you describe your use case + thread model?

 On my machine Tor seems to have different UID after each restart (at
 least this is what ps -A | grep -w tor tells me). How I can force it
 to use always the same UID? According to this thread
 http://ubuntuforums.org/showthread.php?t=800066a I can't change it
 when Tor is already running so my guess is I should force it to use
 chosen UID before it will even start.

I wonder why your uid should be different everytime you reboot, but you
can also use the name of the user instead of the numerical value.

 I couldn't find (man iptables) nothing about -m owner - should I
 replace owner with my login or it is to match Tor through --uid-owner
 $TOR_UID?

The word 'owner' after -m is _not_ a variable that needs to be
replaced. It is the match extension module name.


***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Yet another UDP / DNS quiestion...

Could you describe your use case + thread model?

I'm terrible sorry for chaos I'm causing but right now I'm a very small
and confused person :-) Let me start from the beginning...

I'm using Privoxy + Tor combination. For Privoxy to properly handle
TCP/HTTP requests and send them over Tor network I have listen-address
127.0.0.1:8118 in my /etc/privoxy/config. Then, to make sure that
Privoxy will be used globally, I added those four lines
to /etc/environment:
http_proxy=http://127.0.0.1:8118/;
https_proxy=https://127.0.0.1:8118/;
HTTP_PROXY=$http_proxy
HTTPS_PROXY=$https_proxy
Now all TCP/HTTP traffic should go through Privoxy - Tor combination,
at least in theory. As I understand Wireshark is the tool I should use
to verify if that is what is happening in reality. I compiled Wireshark
but don't understand yet how to use it so I will come back to verify
routing of TCP/HTTP when I understand what I'm doing.
Next, I tried to use torsocks to make sure UDP/DNS requests are resolved
through Tor. To accomplish that I added to /etc/privoxy/config
forward-socks4a / 127.0.0.1:9050 .
forward-socks5 /127.0.0.1:9050 .
My /etc/torsocks.conf looks like this:
local = 127.0.0.0/255.128.0.0
local = 127.128.0.0/255.192.0.0
local = 169.254.0.0/255.255.0.0
local = 172.16.0.0/255.240.0.0
local = 192.168.0.0/255.255.0.0
server = 127.0.0.1
server_port = 9050
But I have two problems with using torsocks:
1. Not all applications seems to be working with it, for example when I
try usewithtor empathy I'm getting Segmentation fault. Which is
probably due to the problems with rejecting UDP:

torsocks allows you to use most socks-friendly applications in a safe
way with Tor. It ensures that DNS requests are handled safely and
explicitly rejects UDP traffic from the application you're using. (from
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO)

2. I would need to usewithtor every single application on my system to
make sure DNS requests are resolved through Tor.

Then I came around Transparently Routing Traffic Through Tor
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy.
And this is where more confusion and problems started! What I want to achieve
with this wiki is to make sure all UDP/DNS request will be send through Tor.
Now I intend to follow Local Redirection Through Tor from mentioned wiki to the
letter and that will hopefully resolve the case of leaking DNS.

# Block/reject all outgoing UDP traffic
iptables -A OUTPUT -j REJECT
This rule does not block UDP only, it rejects all traffic including
UDP
(if a packets makes its way to the last line).

So if I will go ahead with set-up from Local Redirection Through Tor it
will allow out just the traffic going through Tor stopping any and every
kind of no-Tor traffic from leaving my machine. But if I want to allow
traffic from certain applications I could do it by setting up exception
in iptables, right? And furthermore, with this solution there will be no
need for me to use torsocks any more, yes?

iptables -A OUTPUT -p udp -m owner --uid-owner $TOR_UID -j ACCEPT
Why did you add -p udp here? Tor uses TCP.

My mistake! Fixed now.

I'm wondering why one would want to setup DNSPort configuration without
TransPort.

That will be lack of knowledge on my part, I missunderstood informations
from wiki. I got confused by this comment
http://www.hermann-uwe.de/blog/howto-anonymous-communication-with-tor-some-hints-and-some-pitfalls#comment-80205
which doesn't mention TransPort and thus I thought it is not necessary.

I wonder why your uid should be different everytime you reboot, but you
can also use the name of the user instead of the numerical value.

Well I can't tell you why but that how it is. To double check I rebooted
twice just now and ps -A | grep -w tor each time gave me different UID
for tor.

--
Tomasz Moskal ramshackle.industr...@gmail.com
Encrypted mail preferred. Key ID: 2C323C82

signature.asc
Description: This is a digitally signed message part

Re: Yet another UDP / DNS quiestion...

2011-02-13 Thread Robert Ransom

On Sun, 13 Feb 2011 18:50:19 +
Tomasz Moskal ramshackle.industr...@gmail.com wrote:

  I wonder why your uid should be different everytime you reboot, but you
  can also use the name of the user instead of the numerical value.
  
 Well I can't tell you why but that how it is. To double check I rebooted
 twice just now and ps -A | grep -w tor each time gave me different UID
 for tor.

That's a process ID, not a user ID.


Robert Ransom


signature.asc
Description: PGP signature

Scroogle and Tor

2011-02-13 Thread scroogle

I've been fighting two different Tor users for a week. Each is
apparently having a good time trying to see how quickly they
can get results from Scroogle searches via Tor exit nodes.
The fastest I've seen is about two per second. Since Tor users
are only two percent of all Scroogle searches, I'm not adverse
to blocking all Tor exits for a while when all else fails.
These two Tor users were rotating their search terms, and one
also switched his user-agent once. You can see why I might be
tempted to throw my block all Tor switch on occasion --
sometimes there's no other way to convince the bad guy that
he's not going to succeed.

When a nonprofit such as the Tor Project or Scroogle offers a
public service, the script kiddies should have more respect.
I don't expect everyone to donate to Tor and Scroogle, but I
do expect that no one will steal time and effort from us.

By the way, my block all Tor options for my Scroogle servers
use an expanded definition of which IPs are Tor exit nodes.
I pull the blutmagie.de exit node list, or the torproject.org
exit node list (both port 80 and port 443) once per half hour,
alternating between the two sites.

One custom switch I use is a cumulative list from yesterday and
today, all in one list with duplicates purged. The other switch
I created is a moving cumulative list from today plus the
previous six days.

Why do I do this? Well, Tor's DNSEL using dig is too much
overhead, compared to searching a sorted list on my servers.
But the available exit node lists from the Tor directory are
strange, to say the least. The list size from blutmagie.de can
be as much as several hundred IPs different than the list from
torproject.org, even within the same one-hour period. Moreover,
they are extremely dynamic. While the current list is usually
around 1100 IPs, the cumulative list from yesterday plus today
is usually about 2600 unique IPs. The list from today plus the
six previous days is anywhere from 4500 to 7500 unique IPs.
I've been watching these numbers for over a year now -- take
my word for it that what I'm describing is a consistent
pattern, not some momentary fluke.

I'm getting to the point where I'm tempted to offer my two
exit node lists (yesterday plus today, and previous six days
plus today) to the public. If I had more confidence in the
lists currently available to the public, I wouldn't be
tempted to do this.

-- Daniel Brandt



***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Yet another UDP / DNS quiestion...

On Sun, 2011-02-13 at 11:04 -0800, Robert Ransom wrote:

 That's a process ID, not a user ID.
Arrrgh! My brain is slowly melting. I think what I will do now is to
give up on Tor and attempts to understand it. I will explore more how to
properly and effectively use Linux. Then I shall delve some more into
basic concepts behind Internet Protocols and THEN, just then, I will
come back to Tor. Well, see you folks in a year or two!

-- 
Tomasz Moskal ramshackle.industr...@gmail.com
Encrypted mail preferred. Key ID: 2C323C82


signature.asc
Description: This is a digitally signed message part

Re: Scroogle and Tor

2011-02-13 Thread Gregory Maxwell

On Sun, Feb 13, 2011 at 2:09 PM,  scroo...@lavabit.com wrote:
[snip]
 I'm getting to the point where I'm tempted to offer my two
 exit node lists (yesterday plus today, and previous six days
 plus today) to the public. If I had more confidence in the
 lists currently available to the public, I wouldn't be
 tempted to do this.

You should. The current public exit service is demonstrably incorrect.

Although it's also important to know why it's incorrect.

For example, one reason that the DNSEL is incorrect is a side effect
of that fact that they are tested to see what address they _really_
exit from. Sometimes an exit is placed behind some proxy and the
address that it claims to be is not the address anyone else sees.
But— if an exit has a policy so narrow that it can not be tested by
this process then it will not show up in the DNSEL results.

So, e.g. if I ran a scroogle only exit, it wouldn't be in the DNSEL
results.  I'm pretty sure this is the wrong failure mode for the
testing process.

Though this issue means that your non-testing based results will also
be incorrect, just in another way.

There may also be other issues with the DNSEL result which I am
unaware of. The daily/weekly cycle part just sounds like the pattern
of nodes hitting their transfer limits and shutting off.  Perhaps the
DNSEL is promptly delisting these nodes when there should be a hold-up
because the DNSEL results are cached.

As far as performance goes, you can download a list of nodes which can
reach a particular address at
https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.2.3.4
but, these results have the same problem with omitted nodes that I
mentioned.

As far as the annoying requests from tor goes, it would be better to
subject them to a captcha than to block them completely. Then again,
the big reason people use scroogle via tor is, as I understand it, to
avoid the annoying captchas that google often subjects tor exits to...
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Sent e-mails going into spam folders.

2011-02-13 Thread Karsten N.

Am 13.02.2011 00:54, schrieb Matthew:
 Incidentally, in http://torstatus.blutmagie.de/ gpfTOR4 is listed as
 being in the Czech Republic while gpfTOR5 and gpfTOR6 are in
 Netherlands.  Is this correct?

Yes, coorect.

In the last years we see much less trouble by using non-German ISPs for
our Tor nodes. gpfTOR4 is hosted by coolhousing.net, gpfTOR5 and gpfTOR6
are hosted by leaseweb.nl.

Greetings
Karsten N.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Scroogle and Tor

2011-02-13 Thread Matthew




On 13/02/11 19:09, scroo...@lavabit.com wrote:

I've been fighting two different Tor users for a week. Each is
apparently having a good time trying to see how quickly they
can get results from Scroogle searches via Tor exit nodes.
The fastest I've seen is about two per second. Since Tor users
are only two percent of all Scroogle searches, I'm not adverse
to blocking all Tor exits for a while when all else fails.
These two Tor users were rotating their search terms, and one
also switched his user-agent once. You can see why I might be
tempted to throw my block all Tor switch on occasion --
sometimes there's no other way to convince the bad guy that
he's not going to succeed.



For the less than knowledgeable people amongst us (e.g me) who want to 
learn a bit more: what was the rationale for those two Tor users doing what 
they did?  What do they get from it?


Incidentally, I use the SSL version of Scroogle (sometimes with Tor, 
sometimes without) because a) no CAPTCHAs b) I appreciate your 
privacy-minded ethos (ideology).  It would be a shame if you had to block 
Tor users because of an abusive minority.



When a nonprofit such as the Tor Project or Scroogle offers a
public service, the script kiddies should have more respect.
I don't expect everyone to donate to Tor and Scroogle, but I
do expect that no one will steal time and effort from us.

By the way, my block all Tor options for my Scroogle servers
use an expanded definition of which IPs are Tor exit nodes.
I pull the blutmagie.de exit node list, or the torproject.org
exit node list (both port 80 and port 443) once per half hour,
alternating between the two sites.

One custom switch I use is a cumulative list from yesterday and
today, all in one list with duplicates purged. The other switch
I created is a moving cumulative list from today plus the
previous six days.

Why do I do this? Well, Tor's DNSEL using dig is too much
overhead, compared to searching a sorted list on my servers.
But the available exit node lists from the Tor directory are
strange, to say the least. The list size from blutmagie.de can
be as much as several hundred IPs different than the list from
torproject.org, even within the same one-hour period. Moreover,
they are extremely dynamic. While the current list is usually
around 1100 IPs, the cumulative list from yesterday plus today
is usually about 2600 unique IPs. The list from today plus the
six previous days is anywhere from 4500 to 7500 unique IPs.
I've been watching these numbers for over a year now -- take
my word for it that what I'm describing is a consistent
pattern, not some momentary fluke.

I'm getting to the point where I'm tempted to offer my two
exit node lists (yesterday plus today, and previous six days
plus today) to the public. If I had more confidence in the
lists currently available to the public, I wouldn't be
tempted to do this.

-- Daniel Brandt



***
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: Sent e-mails going into spam folders.

2011-02-13 Thread Matthew




On 13/02/11 21:03, Karsten N. wrote:

Am 13.02.2011 00:54, schrieb Matthew:

Incidentally, in http://torstatus.blutmagie.de/ gpfTOR4 is listed as
being in the Czech Republic while gpfTOR5 and gpfTOR6 are in
Netherlands.  Is this correct?

Yes, coorect.

In the last years we see much less trouble by using non-German ISPs for
our Tor nodes. gpfTOR4 is hosted by coolhousing.net, gpfTOR5 and gpfTOR6
are hosted by leaseweb.nl.

Could you please say a little more about what the trouble in Germany was 
and why Dutch and Czech exit nodes involve less trouble?  Thanks.



Greetings
Karsten N.
***
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: Scroogle and Tor

2011-02-13 Thread scroogle

 Gregory Maxwell wrote:

 As far as performance goes, you can download a list of nodes which can
 reach a particular address at
 https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.2.3.4
 but, these results have the same problem with omitted nodes that I
 mentioned.

That's the torproject.org bulk list I've been using, alternating with
the blutmagie.de list. When I download the torproject.org list I ask
for exit nodes that can reach one of my servers. I alternate between
asking for port 443 and port 80 on that server.

 Someone else emailed me directly:

 Seems like you could get a lot smarter about this and block successive
 queries from the same IP that happen less than a few seconds from each
 other.

Difficult, because blutmagie.de and another high-traffic site account for
about 20 percent of my total Tor requests. I have to exempt them from some
of my screening if there's a chance of false positives. I'm already doing
something like what you suggest, after exempting these two sites. It's
normally turned off, but I try this first when I have a problem. I try
other things too before blocking all exit nodes.

Another problem is that search-engine use presents a special challenge.
Often legitimate searchers fire off a few searches in quick succession.
The input box is right there, and they may modify it just slightly and
fire off another search.

An extreme example of this is something I see several times a week
outside of Tor (which is too slow to do this). Someone has a Scroogle
search plugin out there that mimics an instant-search feature for every
keystroke as you key in your search term. This is something Google
introduced last year. But trying to do this on Scroogle is insane.
Even if it works to the user's satisfaction, I consider this extremely
abusive, and I block these IPs for a week as soon as I see it happening.
The reason it's insane is that Scroogle has six servers, while Google
has several hundred thousand servers. I wish these script kiddies would
do the math first!

-- Daniel Brandt



***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Scroogle and Tor

2011-02-13 Thread Andrew Lewman

On Sun, 13 Feb 2011 14:09:56 -0500 (EST)
scroo...@lavabit.com wrote:

 I've been fighting two different Tor users for a week. Each is
 apparently having a good time trying to see how quickly they
 can get results from Scroogle searches via Tor exit nodes.

I've talked to a few services that do one of the following:

- Run a Tor exit enclave, which would only allow exit through Tor to
  your webservers.  There are a few services that run a tor client and
  simply block every IP in the consensus, except their exit enclave.

- Run a hidden service.  Due to the current state of hidden services,
  it'll slow down everything.

- Run a tor exit enclave against one, non-load balanced server for tor
  users. If someone abuses it, the reality of slower response times is a
  self-enforcing feedback loop. Of course, this sucks for the
  non-abusers.

- Rate limiting queries in the application.  The Google solution of
  CAPTCHA. The Yahoo/Bing solution of throwing up a temporary error
  page when queries cross some threshold per IP address.

-- 
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: or-talk list migration Feb 19, 2011

2011-02-13 Thread Andrew Lewman

A reminder that this migration occurs this week.

On Mon, 24 Jan 2011 15:05:03 -0500
Andrew Lewman and...@torproject.org wrote:

 Hello or-talk subscribers,
 
 On February 19, 2011, we are migrating or-talk from or-t...@seul.org
 to tor-t...@lists.torproject.org.  We will migrate your e-mail
 address's subscription to the new list. You will receive a
 confirmation from the new mailing list software on the 19th.
 
 Current or-talk archives will be migrated.  Roger plans to leave the
 current archives in place at seul.org as well.
 
 We're using this migration to spread administration out to Tor's
 sysadmin team rather than making Roger do everything himself.  The
 secondary benefits of having the lists on the torproject.org domain
 include SSL-enabled login, archives, and easier account management.
 
 You can subscribe to the new list at
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
 
 I will send out a reminder on the day of the migration.
 
 Please e-mail tor-assista...@torproject.org with any questions.
 
 Thank you.  
 



-- 
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: Scroogle and Tor

2011-02-13 Thread Gregory Maxwell

On Sun, Feb 13, 2011 at 9:34 PM, Andrew Lewman and...@torproject.org wrote:
 I've talked to a few services that do one of the following:

 - Run a Tor exit enclave, which would only allow exit through Tor to
  your webservers.  There are a few services that run a tor client and
  simply block every IP in the consensus, except their exit enclave.
[snip]

This one can be kind of lame, because some requests to an enclaved
host (in particular, the first one always) will hit some random exit.
Depending how you do the blocking this can give unexpected results.

It would be nice if there were some roadmap to fixing this, since it
really diminishes the usefulness of enclaves as a mechanism for
reducing problems due to misbehaving exits. Likewise, the extra hop
probably washes out a lot of the benefit of an enclave as a
performance enhancement (though not as much as a hidden service).

It can also be tricky to run an enclave when you DNS load-balancing
(especially with multiple datacenters): You must have an 'apparent'
Tor node on every IP that your DNS returns.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Can't Contact Scroogle

2011-02-12 Thread Jim

I currently cannot reach https://ssl.scroogle.org:443/ via Tor.  I can 
reach it going directly to the Internet.  In the past Scroogle has 
seemed tor-friendly.  Is anybody else having this problem?


Jim
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Can't Contact Scroogle

2011-02-12 Thread Gitano

On 2011-02-12 11:01, Jim wrote:

 I currently cannot reach https://ssl.scroogle.org:443/ via Tor.

Me too.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: I wish to see one video on you tube

2011-02-12 Thread Martino Papesso

Il 08/02/2011 23:08, Praedor Atrebates ha scritto:
 The video is from Silent Hill 2 OST.  You MAY be able to play it if 1) you 
 enable flash in your firefox browser and 2) you select an exit from a country 
 not restricted (like Romania).  I say MAY because if they use flash to check 
 your location, sidestepping tor, then you will get the same restricted 
 message.

 praedor

My flash in my firefox is enable and works but how to run the second
point(you select an exit from a country not restricted...)?
Please.
Martino-Italy



***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Problem with downloading attachments in torbrowser for osx

2011-02-12 Thread Mike Perry

Thus spake M (moeedsa...@gmail.com):

  It would be helpful if you can add information such as your
  - Operating system version
  - Tor version
  - Polipo or Privoxy version
  - Torbutton version
  - Firefox version
  - Torbrowser or Vidalia bundle version.
 
 ok

It sounds like you're describing a problem that only you have. Usually
when this happens, it is because of a Firefox addon conflict. You can
try a couple of things:

1. Use Tor Browser Bundle:
https://www.torproject.org/projects/torbrowser.html.en

It is a preconfigured Tor Browser that should work right out of the
box without conflicts. If it *still* has the problem, then next place
to look is your Antivirus software. If not, you can either keep using
it, or try to diagnose your addon conflict by trying the following:

2. Start firefox with a fresh profile

If you run firefox as firefox -P, you can create a blank profile,
install torbutton in it, and verify it is OK. Then, gradually add in
all the Firefox addons you have until you notice the problem again.

3. Post your list of addons to this mailinglist or to that bug for
someone else to try to reproduce the issue.


  and does it work if you use Save As instead?
 
 cant save as with attachments...
 
  And what about this (and also the link provided by Roger:
 https://trac.torproject.org/projects/tor/report/14???

This link works for me using Tor + Torbutton.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs


pgpd73NTt5Rwe.pgp
Description: PGP signature

Re: I wish to see one video on you tube

2011-02-12 Thread Karsten N.

Am 12.02.2011 13:27, schrieb Martino Papesso:
 I say MAY because if they use flash to check your location, sidestepping 
 tor, then you will get the same restricted message.

If you location was checked with Flash you can use a proxifier like
ProxyCap or Widecap to redirect all traffic from the Flash player to
Tor. A tutorial for using ProxyCap or Widecap for Flash anonymisation
was written by JonDonym. Replace Port 4001 with the Tor listen port 9050
and it will work:

  https://anonymous-proxy-servers.net/en/help/proxifier2.html

 how to run the second point(you select an exit from a country not
 restricted...)?

You can define a map address in your torrc file:

   MapAddress youtube.com youtube.com.{RO}

Greetings
Karsten N.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: I wish to see one video on you tube

2011-02-12 Thread Martino Papesso

Il 12/02/2011 15:32, Karsten N. ha scritto:
 Am 12.02.2011 13:27, schrieb Martino Papesso:
 I say MAY because if they use flash to check your location, sidestepping 
 tor, then you will get the same restricted message.
 If you location was checked with Flash you can use a proxifier like
 ProxyCap or Widecap to redirect all traffic from the Flash player to
 Tor. A tutorial for using ProxyCap or Widecap for Flash anonymisation
 was written by JonDonym. Replace Port 4001 with the Tor listen port 9050
 and it will work:

   https://anonymous-proxy-servers.net/en/help/proxifier2.html

 how to run the second point(you select an exit from a country not
 restricted...)?
 You can define a map address in your torrc file:

MapAddress youtube.com youtube.com.{RO}

 Greetings
 Karsten N.
 ***
 To unsubscribe, send an e-mail to majord...@torproject.org with
 unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


Please , show me someone who speaks English Italian and know tor.
Not google translate or similar please.
It is too difficult to understand very well your very interesting 
discussion.

***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Tor raid [was: cease and desist from my vps provider...]

2011-02-12 Thread Martino Papesso

Il 07/02/2011 09:47, Marco Predicatori ha scritto:
 morphium, on 02/04/2011 03:08 PM, wrote:

 Oh and yes, they took only my hardware @ home, not the Server in
 the data center that actually DID run Tor and that the bad IP
 belonged to.
 That's interesting, because it means that running the node away from
 home doesn't affect the chance of being harassed at 5 AM. :-(


Ciao Marco,
leggo che la tua email presenta un nome italiano.Parli italiano?
Ti ho già scritto una e mail e ho ricevuto una e mail di risposta che
non posso leggere perchè non ho la chiave segreta richiesta per poter
leggere il messaggio.
Martino.

***
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-02-12 Thread John Case



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?

2011-02-12 Thread John Case



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?

2011-02-12 Thread Gregory Maxwell

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: Yet another UDP / DNS quiestion...

2011-02-12 Thread tagnaq

On 02/12/2011 05:30 AM, Tomasz Moskal wrote:
 I was reading Transparently Routing Traffic Through Tor 
 https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy
 and although I don't need to run Tor as transparent proxy I like the
 idea of routing the UDP/DNS requests to localhost. If I will reroute
 all those requests with iptables to the port on which Tor is
 listening I should have no problems with DNS leaking, right?

Yes if you redirect DNS requests to Tor's DNSPort you should be safe
against DNS leaks.

 3. iptables
 
 iptables -t nat -A OUTPUT -o lo -j RETURN iptables -t nat -A OUTPUT
 -m owner --uid-owner $TOR_UID -j RETURN iptables -t nat -A OUTPUT -p
 udp --dport 53 -j REDIRECT --to-ports 53 iptables -t nat -A
 PREROUTING -i $INT_IF -p udp --dport 53 -j REDIRECT --to-ports 53 
 iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
 iptables -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT iptables
 -A OUTPUT -j REJECT

I guess you are talking about a local setup without a middlebox
involved. If my assumption is correct you want to refer to the following
section in the document:
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy#LocalRedirectionThroughTor

as far as I can see you copied parts of the iptables rules from the
middlebox setup from this section:
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy#LocalRedirectionandAnonymizingMiddlebox


***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Sent e-mails going into spam folders.

2011-02-12 Thread Matthew




On 09/02/11 09:06, Karsten N. wrote:

Am 07.02.2011 20:00, schrieb Matthew:

I am wondering to what degree people on this list have problems with
e-mails going into spam folders because they are using tor nodes.

Many Tor nodes are listet in some anti-spam DNSBL. We have had a
discussion here about SORBS DNSBL some times ago. All tor nodes are
listet in the The Abusive Hosts Blocking List www.ahbl.org

The IP address of the tor exit node appears in the mail header. It is
the senders IP addres.

If the recipients mail provider uses a DNSBL which contains many tor
nodes the mail will be flagged as spam.

You can use a clean exit node for sending mail with SMTP. Check your
prefered exit nodes at http://www.dnsbl.info/dnsbl-database-check.php
If it is not listet, you can add a map address to your torrc:

   MapAddress smtp.provider.tld smtp.provider.tld.$6D3EE...(Fingerprint)

The GPF keeps one exit node clean from DNSBL. The tor node gpfTOR3 is
only listet at www.ahbl.org (impossible to remove it, because all nodes
are listet). You can use this if you did not find an other.



Thank you.  The DNSBL link was very useful.

I have checked the three GPF exit nodes and gpfTOR4 and gpfTOR6 are not 
listed by any lists (including AHBL) while gpfTOR2 is only listed by 
barracudacentral.org/rbl.


Incidentally, in http://torstatus.blutmagie.de/ gpfTOR4 is listed as being 
in the Czech Republic while gpfTOR5 and gpfTOR6 are in Netherlands.  Is 
this correct?




ATTENTION: It will decrease your privacy! Use only very well trusted nodes.

(I did found an other solution for SMTP)

Greetings
Karsten N.


***
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/

Macports tor broken?

2011-02-11 Thread Jerzy Łogiewa

Updated my ports and see this:

dyld: Library not loaded: /opt/local/lib/libevent-1.4.2.dylib
  Referenced from: /opt/local/bin/./tor
  Reason: image not found
Trace/BPT trap

--
Jerzy Łogiewa -- jerz...@interia.eu



Jedz ile chcesz i chudnij!
Sprawdź  http://linkint.pl/f2904

***
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-02-11 Thread John Case



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: Macports tor broken?

2011-02-11 Thread Nicolas Pouillard

On Fri, 11 Feb 2011 11:25:51 +0100, Jerzy Łogiewa jerz...@interia.eu wrote:
 Updated my ports and see this:

Maybe you can give a try to the Homebrew [1] package manager.

[1]: http://mxcl.github.com/homebrew/

-- 
Nicolas Pouillard
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Yet another UDP / DNS quiestion...

2011-02-11 Thread Tomasz Moskal


I feel that I should explain something before I start asking any
questions so here we go: I'm a fresh convert to Linux (barely few week
on Ubuntu!) and as much as I'm fascinated by the matters relating to
networking, security and anonymity in equal measure I'm intimidated by
them. I don't posses any deep knowledge of those topics, I still barely
can handle the basics. But with the wealth of knowledge out there and a
healthy dose of experimentation I intend to change this. So if my
questions are naive (or plainly stupid) please bear in mind that I'm new
here. And now for what is bordering me...

I was reading Transparently Routing Traffic Through Tor
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy 
and although I don't need to run Tor as transparent proxy I like the idea of 
routing the UDP/DNS requests to localhost. If I will reroute all those requests 
with iptables to the port on which Tor is listening I should have no problems 
with DNS leaking, right? That should do the trick then:

1. torrc 

DNSPort 53
DNSListenAddress 127.0.0.1

2. resolv.conf

nameserver 127.0.0.1

3. iptables 

iptables -t nat -A OUTPUT -o lo -j RETURN
iptables -t nat -A OUTPUT -m owner --uid-owner $TOR_UID -j RETURN
iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A PREROUTING -i $INT_IF -p udp --dport 53 -j REDIRECT
--to-ports 53
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT
iptables -A OUTPUT -j REJECT

I'm not an expert regarding iptables and 'man iptables' is *very*
frightening for someone who barely slides on the surface of all this.
From steep three above I sort of understand purpose of rules three and
four but rest of them... Are they needed in this example or they can be
safely omitted? If in fact they are required for this set-up to work
what is their purpose? I will of course replace $INT_IF and $TOR_UID
with required values.


-- 
Tomasz Moskal ramshackle.industr...@gmail.com
Encrypted mail preferred. Key ID: 2C323C82




signature.asc
Description: This is a digitally signed message part

Re: Is gatereloaded a Bad Exit?

2011-02-11 Thread Geoff Down



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/

Problem with downloading attachments in torbrowser for osx

Hey guys,

I thought i would bring this to the attention of those concerned in case
they already did not know. I am still unable to download any attachments,
whether yahoo or gmail, when running tor. The message which appears is

 [JavaScript Application]

Torbutton blocked direct Tor load of plugin content.

Use Save-As instead.


This is a real pain and i was hoping it would be fixed with the update, but
alas


Also, the same message appears sometimes on normal pages, such as when you
fill forms, or just loading pages like:
http://groups.yahoo.com/group/X-clusive_Stuffs


Please try to fix this issue in the next update... its a real pain!!!

Re: Problem with downloading attachments in torbrowser for osx

2011-02-11 Thread Roger Dingledine

On Sat, Feb 12, 2011 at 05:08:17AM +, M wrote:
 I thought i would bring this to the attention of those concerned in case
 they already did not know. I am still unable to download any attachments,
 whether yahoo or gmail, when running tor. The message which appears is
 
  [JavaScript Application]
 
 Torbutton blocked direct Tor load of plugin content.
 
 Use Save-As instead.

Have you tried using Save-As instead?

 This is a real pain and i was hoping it would be fixed with the update, but
 alas

I believe the trouble is that Firefox doesn't make it easy for extensions
to tell if the website is trying to get you to run an external application
vs just trying to give you a file to download.

But I'll turn the question around on you: which trac entry on
https://trac.torproject.org/projects/tor/report/14
did you report your issue on? If it's not on the bugtracker it's nowhere.

--Roger

***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Problem with downloading attachments in torbrowser for osx

2011-02-11 Thread krishna e bera

Bugs tend to get fixed faster and/or more efficiently 
when they are entered into the bug tracking system.
I copied this email into a new one at
https://trac.torproject.org/projects/tor/ticket/2542

It would be helpful if you can add information such as your
- Operating system version
- Tor version
- Polipo or Privoxy version
- Torbutton version
- Firefox version
- Torbrowser or Vidalia bundle version.

and does it work if you use Save As instead?



On Sat, Feb 12, 2011 at 05:08:17AM +, M wrote:
 Hey guys,
 
 I thought i would bring this to the attention of those concerned in case they
 already did not know. I am still unable to download any attachments, whether
 yahoo or gmail, when running tor. The message which appears is
 
  [JavaScript Application]
 
 Torbutton blocked direct Tor load of plugin content.
 
 Use Save-As instead.
 
 
 This is a real pain and i was hoping it would be fixed with the update, but
 alas
 
 
 Also, the same message appears sometimes on normal pages, such as when you 
 fill
 forms, or just loading pages like: http://groups.yahoo.com/group/
 X-clusive_Stuffs
 
 
 Please try to fix this issue in the next update... its a real pain!!!
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Problem with downloading attachments in torbrowser for osx

On Sat, Feb 12, 2011 at 5:51 AM, Roger Dingledine a...@mit.edu wrote:

 On Sat, Feb 12, 2011 at 05:08:17AM +, M wrote:
  I thought i would bring this to the attention of those concerned in case
  they already did not know. I am still unable to download any attachments,
  whether yahoo or gmail, when running tor. The message which appears is
 
   [JavaScript Application]
 
  Torbutton blocked direct Tor load of plugin content.
 
  Use Save-As instead.

 Have you tried using Save-As instead?



'Save as' does not work with attachments...



  This is a real pain and i was hoping it would be fixed with the update,
 but
  alas

 I believe the trouble is that Firefox doesn't make it easy for extensions
 to tell if the website is trying to get you to run an external application
 vs just trying to give you a file to download.


I forgot to mention that when i try to download attachments with an .odt or
docx extension.. it works fine...every time. hmm However, .doc, and .rar
and other common extensions (as far as the ones i have tried) don't work.





 But I'll turn the question around on you: which trac entry on
 https://trac.torproject.org/projects/tor/report/14


Cant access # 14. link shows the same error message :(


 did you report your issue on? If it's not on the bugtracker it's nowhere.



ok.. didnt know.

Re: Problem with downloading attachments in torbrowser for osx

On Sat, Feb 12, 2011 at 5:57 AM, krishna e bera k...@cyblings.on.ca wrote:

 Bugs tend to get fixed faster and/or more efficiently
 when they are entered into the bug tracking system.
 I copied this email into a new one at
 https://trac.torproject.org/projects/tor/ticket/2542


thanks



 It would be helpful if you can add information such as your
 - Operating system version
 - Tor version
 - Polipo or Privoxy version
 - Torbutton version
 - Firefox version
 - Torbrowser or Vidalia bundle version.


ok



 and does it work if you use Save As instead?


cant save as with attachments...

 And what about this (and also the link provided by Roger:
https://trac.torproject.org/projects/tor/report/14???


 
  Also, the same message appears sometimes on normal pages, such as when
 you fill
  forms, or just loading pages like:
 http://groups.yahoo.com/group/X-clusive_Stuffs

Re: Is gatereloaded a Bad Exit?

2011-02-11 Thread Scott Bennett

 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: Problem with downloading attachments in torbrowser for osx