logs archiveIRC Archive / Oftc / #tor / 2010 / July / 10 / 1
tyld
are there any known issues with passive ftp over Tor?
setori
i've never seen anyone complaining about it
tyld
I've set up transproxy
and everything works - but ftp always times out
setori
through privoxy, or directly through tor?
tyld
tor
setori
i guess no available ftp-allowing exit?
tyld
hrrrm
point
I forgot to check on that for the exits I permit
setori
i assume many exits would prefer to block ftp, as it usually means high bandwidth
tyld
sure, http often does as well
you just can't differentiate
:<
         

setori
i know, but ftp is kind of *associated* with that, unlike http
tyld
yup
setori
about transproxy: do we still need it? doesn't tor support it?
that is, support it by itself
tyld
tor supports it
you have to use a kernel firewall
setori
then why do you call it "transproxy". iirc, that's an application name.
tyld
lol
setori
what? :)
tyld
because it takes less time to type than transparent proxy
setori
oh
Sebastian_
tyld: generally, when you exclude many nodes, expect to break Tor in all kinds of interesting ways.
tyld
yup
so far that has been the only issue I've seen
Sebastian__
If you start playing with hidden services you will see many more
Sebastian
Generally before you report a problem/bug, make sure you've tested it with a Tor that allows all exits.
tyld
no need so far
setori
well, your anonymity is also weaker
tyld
ok that was it
taking the strict out
and it works now
setori
Sebastian: why are hidden services more sensitive?
Sebastian
setori: because the hidden service descriptors are hosted at specific relays, and if they are excluded, too bad
also, because the hidden service chooses a few nodes, and if you have excluded those, too bad again
and, when you operate a hidden service, you might not be able to connect to the relay that the client chose.
passive mode ftp generally works well
setori
you mean some hidden service descriptors are hosted at some exits?
Sebastian
sure
         

setori
about taking the strict out: i don't understand the point of this feature
Sebastian
interesting that you would set it
or wouldn't you? :)
nickm
The point of the 'strict' is that people have wildly different expectations of what should happen when they restrict their set of nodes.
tyld
well
I'd like to be strict for everything but ftp
:<
nickm
Some people want only the nodes they selected to get used ever, even if it means that Tor stops working
Or rather, even if they don't have enough allowed nodes to support the operations they want.
setori
that makes sense :)
Sebastian
I've been working on a proposal to make it more clear. But that didn't help much apparently. I'm thinking how to rewrite it.
setori
in an anonymity program
nickm
These people get freaked out if they see any disallowed node in any of their circuits and yell at us for being bad programmers and accuse us of sinister conspiracies.
setori
then the best compromise is to use the correct wording
"prefer these exits"
instead of "use only these exits"
Sebastian
setori: right
but doing that doesn't help
because people still don't get it then
They say "wtf, I want to NEVER use them" without understanding what that means
nickm
Other people want Tor to be able to exclude nodes without breaking things, and expect Tor to keep working even if (say) they try to make an FTP connection but disallow all FTP-supporting exits. ;)
tyld
:P
Sebastian
Unfortunately, we didn't only choose the words in a bad way, we also have bugs in the feature
nickm
These people sometimes get freaked out when Tor stops working, and ask why we let them exclude nodes strictly at all.
setori
at least they get it that they don't get it, which is important in a security/anonymity application
then point them to strict, with a proper disclaimer/warning
nickm
The solution might be to put all our users in one room, and have them fight until the remaining users all agree on which behavior is best. :)
setori
haha
Sebastian
I think the current idea in my head is that it *should* work like this:
setori
the best behavior should be to use both options
"use only these exits, but allow exceptions"
Sebastian
We have an option to exclude the listed nodes/only use the listed nodes for exiting, where exiting is defined as pushing traffic out of the Tor network onto the rest of the internet
setori
"use only these exits, or die"
Sebastian
We also have an option to avoid certain nodes indepenent of their position in a circuit
independent*
setori
"deadly restriction" should be expressive enough :)
Sebastian
and then we have an option to make this last option strict, meaning your Tor can break.
setori
what's wrong with adding warnings in the config file anyway?
Sebastian
If this last option is set, we should explicitly log that Tor is currently breaking because you didn't choose the right nodes.
setori
hdparm is full of them
Sebastian
The same option for exit nodes above also for entry nodes, where entry nodes are your guards and the relays you fetch directory info from.
if you exclude any entry nodes and Tor stops working because of that, we also warn in the log.
setori
here we have no choice. as i emphasized, it's an anonymity application. so i don't think we have a choice. we must use exact language, even if this means a bit more complication.
Sebastian
There. If anyone thinks this is a good idea, I'll write it in the proposal.
setori
yes, a warning is a good addition
Sebastian
nickm: your opinion appreciated too ;)
setori
nickm: also on my suggestion, please :)
Sebastian
I think this would incorporate all the feedback I've gotten on the proposal
setori
so a combination of precise language, config file warning, man page warning, how-to warning, and log warning would be the best solution
Sebastian
config file warnings? I have no idea what you are talking about.
tyld
parse time I assume
startup
the way you warn about GEOIP on older tor versions
Sebastian
ah
I somehow don't think that's it, but maybe :)
tyld
ok
;)
not telepathic here
setori
Sebastian: torrc (which is a "config file") includes #comments (which could include warnings). i am surprised that it wasn't obvious that this was what i was talking about and an explanation would help me improve my style.
tyld
you mean sample config file?
my config file has no warnings :D
Sebastian
setori: I was confused because the Exclude and Strict options aren't even in the torrc sample file
neither do they belong
that's for paranoids who think they know better than the Tor devs
tyld
I wouldn't say paranoids
Sebastian: some people want different things out of Tor than the default
the Tor developers are kind enough to provide that flexibility
Sebastian
Ok, let me rephrase. Paranoids or people who don't want anonymity
Goldstein
I know all kinds of better than the tor devs
:P
Sebastian
Goldstein: that's ok
tyld
Sebastian: there are two kinds of anonymity
(in a sense)
source anonymity
and destination anonymity
Sebastian
tyld: I would be happy to learn about your usecase. If you want to enlighten me
tyld
hrrm
you'll bet at PETS I assume?
Sebastian
Sure
tyld
ok
nickm
So Sebastian's proposal is, "have excludenodes, have excludeexits, have exitnodes. Make a StrictExcludeNodes, but don't let anything else be strict. Warn whenever we can't do what the user wants because StrictExcludeExitNodes is set."
tyld
I can have it conveyed to you
setori
"knowing better than the tor devs" may simply mean they know something
Sebastian
setori: I didn't mean that in an insulting way at all
maybe they really know better.
nickm: I'm thinking entry nodes are strict by default and you can't change that. Unless that's a bad idea?
setori
nickm: this would only satisfy the pragmatic users in your room, but not the paranoids
Sebastian
setori: how would it not satisfy paranoids
nickm
And setori's proposal is to have one option meaning more or less "PreferExitNodes a,B,C" and another meaning "UseTheseExitNodesOrBreak A,B,C".
have I got itright?
setori
nickm: yes, something like that
Sebastian
The problem there is (imo) that the term "exit node" isn't well defined
setori
nickm: with such a wording we won't even need warnings :)
Sebastian
Is it the last node in a circuit? Does every circuit have an exit?
nickm
setori: And probably Tor should log in the first case whenever it uses a non-preferred exit node, and log in the second case whenever it breaks.
setori
nickm: yes, that too
nickm: or "UseOnlyTheseExitsOrBreak" (i added "only")
actually the length will help them think twice before using them. they will only use such options only if they know what they are doing.
the length of the option :)
Sebastian
setori: trust me, people use stuff like PreferTunneledDirConns and ClientDNSRejectInternalAddresses without understanding what it means ;)
but in any case
setori
haha
Sebastian
what is an exit in your definition?
setori
the last node
the one that connects to the destination
why?
Sebastian
Right. Except Tor doesn't only make those typical three-hop circuits that allow you to go to google.com
Goldstein
how about: the last node in a circuit which conects to a non-tor node, provided such exists
Sebastian
There are one-hop circuits for directory fetches, bridged 7-hop circuits for hidden services where you don't even know what the last hop is, etc
Goldstein
excuse me
how about: the last node in a circuit which conects to a non-tor ip, provided such exists
setori
Goldstein: ... and provided that your computer is powered on; too many provisions :)
Sebastian
Goldstein: That one doesn't help for exit enclaves
Goldstein
what is an exit enclave?
Sebastian
:)
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/ExitEnclave
As you can see, of the five people who are taking part in this discussion, we can't reach a consensus. Good luck with all Tor users ;)
hrm, grammar fail. Anyways
setori
Sebastian: what am i disagreeing to?
Goldstein
how about: the last node in a circuit which conects to a non-tor *server*, provided such exists
nickm
Goldstein: One problem with those definition is when people see the last node in a circuit, and it is one that's excluded as an exit node, they flip out, whether it's connecting to a non-tor server or not.
setori
nickm: a log warning and exact/scary wording should silence 80% of them :)
Goldstein
i guess i dont understand how that can happen
nickm
Goldstein: hidden service intro points; hidden service rendezvous points; testing circuits; maybe other stuff I'm not thinking of now.
setori
Goldstein: because they have a crude definition of "only" in "use *only*"
nickm
anonymized directory connections
Goldstein
yeah, if i'm connecting to a hidden service, IMO there isnt an exit node
i'm not exiting
nickm
That's a fine opinion, and it's my opinion too.
setori
Goldstein: oh, now i understand your objection, and here's my answer: "provided such exists" is more like an eula trick
nickm
But when people see one of those nodes at the end of a circuit in vidalia or whatever, they start in with the shouting and the conpiracy theories. :(
Goldstein
too bad. you cant let ignorant people drag you down with them
setori
nickm: can't "inside" exits be marked differently?
Goldstein: drag you down where?
i don't understand the problem
Goldstein
setori: "provided such exists" was my way of excluding the hidden service situation
setori
Goldstein: for people not to worry anymore when they still see the node listed in vidalia?
Goldstein
though i shouldnt even have to really since exit nodes imply a connection to a non-torified server
setori
exactly
Goldstein
to me anyway
setori
nickm: but exits are best defined by whether (1) my traffic is encrypted or not (it is not) and (2) we're dealing with my traffic or merely tor under-the-hood traffic
Sebastian
https://trac.torproject.org/projects/tor/ticket/1090 btw
setori
i consider defining exits a non-issue
nickm
hm. so what you'd _really_ want is not an exit-node restriction, but a port-wise exit node restriction.
Goldstein
I might introduce the concept of a "last node" where last node is either 1) an exit node or 2) the node before a hidden service node
nickm
IOW, you don't care what nodes you use to exit https, but you don't want to send unencrypted ftp to just anyone
tyld
nickm, right
I only really care about restricting exit nodes for ssh
for example
nickm
Why ssh? ssh is encrypted.
setori
nickm: well, this is what i really want when i use the word "exits". i don't know if some people would desire to ban some node no matter what.
tyld
nickm: or http, for services restricted by country
many more exit nodes allow http than allow ftp
and ftp doesn't ever have that restriction
but http often does
nickm
It also doesn't help that the circuit-building node-selection code is some complex and not-very-well-centralized stuff, with little corner cases strewn in various places. The more complex these rules get, the less chance we have of implementing them properly without a big rewrite.
setori
nickm: no, you misunderstood me. i don't care if it's https or not, i care if it's tor-encrypted or not.
Goldstein
nickm: If I thought a node was run by the NSA, should I really trust that SSL is good enough?
« prev 1 2 3 4 next »