crackedactor@xxxxxxxxxxx wrote: > Fabian Keil <freebsd-listen@xxxxxxxxxxxxx> wrote > > >I don't see the problem here. The option is called "AllowInvalidNodes" > >not "DoNotOnlyUseTrusworthyNodes". > > > >You can't assume that every node not marked as invalid is trustworthy. > I notice you snipped away quite a lot of what I wrote and I'd ask you to > please read some of it again. If you have questions feel free to email > me direct. It was my intention to only snip the parts I didn't comment on. > The term "trustworthy" comes from the passage in the manual, I didnt > write it. > > http://tor.eff.org/tor-manual.html.en > > > I quote > > "AllowInvalidNodes entry|exit|middle|introduction|rendezvous|... > Allow routers that the dirserver operators consider invalid (not > trustworthy or otherwise not working right) in only these positions in > your circuits. The default is "middle,rendezvous", and other choices are > not advised." Yes I know, all I'm saying is that it's a difference if a node is trustworthy or just not marked as invalid. As far as I understand it, if a node is not marked as invalid, it means that the dirserver operators have no reason to believe that it's untrustworthy or misbehaving. In other words a valid node isn't guaranteed to be untrustworthy, but it very well might. After all traffic sniffing nodes can't be detected, unless they intend to be detected. > The term "muster" essentially means > > to gather together (usually an army or troop) > > So you would muster you men - OK so far? > > In this context (tor) it just means anyone who can put together a > server. It has no connotation on that servers ability for or against its > accessing any keys or its ability at all. Im afraid you took a wrong > turn there, sorry. You're right, I thought "muster" was another word for "check". > As for the Levels1..4 pushing folk away - on the contrary, everyone at > the moment would slot into one or other of these categories. Just that > some might not want to or get to the upper levels. There would be no > loss of servers just the ability for the user to choose which level of > security they prefer. Thats democratic yes/no? But unless I failed to get it again, your levels would require the checks you mentioned, so I think most of my concerns still apply? BTW: instead of "levels" I'd prefer more optional "labels". What I'd like to have would be a Tor server option that clarifies if a Tor server provides unmodified content. Similar like the myfamily feature it would be only used by the good guys, but I still think it would be useful. I really hate it when Tor servers are chained with squid and provide modified content without letting me know. Some of them even provide default addresses for failed DNS requests, instead of delivering a decent error message. I think most of these Tor server operators have no wrong intentions and wouldn't mind using such an option if it existed. I would be glad if I could easily exclude them. As far as I remember, the Tor documentation doesn't say anything about if it's right or wrong to chain Tor servers with content modifying proxies, but I for one think it's a bad idea. > Of course you can still use your cryptic keys, if you want to, just > like the internet uses ip addresses today. But for many internal torland > websites, a userfriendly URL like alternative, supported by something > akin to a torlandDNS system, would be an advantage to get the average > man/woman in the street interested. As far as I understood, you intended to have some of your proposed Tor server levels include a check of the Tor server. Is that correct? I'm just saying that this check would weaken the Tor server's security, because the person checking the server would get hold of the server's private key. > You know, you could always argue to do nothing, never create a Tor > network, never use Tor, never encrypt, never invent guard nodes etc. > > Its easy - just think of the exteme case when these defenses dont work > and reason its not worth bothering to do in the first place. I just think your proposed Tor server levels would not only fail in extreme case, but next to always. > But we dont - or at least not all of us do! > > The thing about security is like anything in life - its an uphill > struggle. > > Always changing, always getting more difficult, as your adversary gets > better. > > Really just like LIFE and EVOLUTION, just like living viruses and > bacterial adaptation to drugs etc. > > Everytime you develop something, some monkey with a wrench comes along > and makes all your efforts as nothing. > > > The ONLY way to stay on top of this is to get out there and do something! Hopefully something that changes the situation, I just don't see how your proposed Tor server levels would gain anything. > We ALL know this - its our natural instinct, survival. > > So to keep these flood servers at bay we need to erect barriers, hence > my Levels1..4. > > OK some Agent Blacks may be able to pass themselves off as "home" nodes > but how many and will the tor community get wise to them? I don't think so. There is no reliable way to detect if a Tor server is sniffing traffic. > The way it stands at the moment we do NOTHING! Again I don't think so, the Tor developers do a lot. > So we will eventually be overrun, if we do nothing. > > WHAT everyone needs to understand is that your adversary out there, who > snoops on you, will ALREADY be watching and infiltrating the tor > network, forums, mailing lists, dev teams and the likes. His/her > interest is to snoop on you and what better way to do this than from the > inside. > > ASK yourselves - WHY is it that people keep posting on commonly (for > most tor users?) understood problems of EXIT node logging of passwords > etc, when a successful attack can only really be traced to a source by > both entry and exit node logging and timing solutions, exactly what we > are told is going on in the US. Why arent they screaming from the > rooftops about these highvolume snoop nodes? > > Once again to date we still have no server nicks having been circulated > here for users to exclude. Again thats odd, dont you think? I don't. As there's no reliable way to detect a sniffing server, circulating such a list would only cause a false sense of security, as you would only exclude the harmless ones that want to be detected. > If I were a Tor adversary (a government say) I would first get control > of as much of the development team as possible. I would put in a few > trustable fast nodes - say by using university departments or the like > (those who have an excuse to have high bandwidth/fast servers) - staffed > with a few chosen men/women. > > Then I would alter the code so that it was luke warm. If I was wanting > to use it myself (with military strength) I would write the code with > sections (functions/proceedures) which could easily (by a build server) > be replaced with my hardening code versions. > > I would do my level best to stop any of those hardening techniques from > getting into the actual code. But of course, some items I would have to > add, say like guard nodes, because thats system wide. Entry guards aren't system wide, they are implemented in the client. > Anyone suggesting hardening changes (particularly those I'd fenced off > for the mil.) would be initially given the blarney and run about. For > more serious cases I'd give them a roasting with my planted agents. You > name it anything goes. If this fails I'd use my backup techniques of > distraction, wrong footing - smoke and mirrors stuff that deludes and > redirects the people away from the scent. If this fails then the > ultimate solution would be used.. have a guess what that is? > > Of course, this is hypothetical, what I would do if I was your > adversary, what would you do if you were mine? Maybe I would do the same, but I don't see what it has to do with your proposed changes. They weren't rejected because some evil person infiltrated the Tor development team, but because they just aren't worth it. Fabian -- http://www.fabiankeil.de/
Attachment:
signature.asc
Description: PGP signature