On Mon, Jan 01, 2001 at 08:29:01PM -0800, Mr . Bad wrote:
> >>>>> "OS" == Oskar Sandberg <[EMAIL PROTECTED]> writes:
>
> >> Shy nodes ("Don't talk to strangers."). I realize it's a
> >> social rather than a technical solution, but it might be the
> >> only one that would even help.
>
> OS> I have a better solution: Nodes don't talk to each other at
> OS> all and reside only on computers not connected to the
> OS> Internet.
>
> Well, that would be the most secure option, yes.
>
> I was just pointing out that the best way to keep hostile elements out
> of Freenet is to require that they be vetted by an existing node
> runner before even starting. Also, if a hostile element has obviously
> "bad" data coming through, its peers can remove it from their trust
> list, and it's essentially isolated and powerless.
>
> Example: take A, B, C and D here.
>
> A - B - C - D
>
> OK, every node here is shy (except maybe B, who we don't really care
> about. Screw B!). Unfortunately, A and C have been a little
> promiscuous with their trust and provided an entry into Freenet for a
> cancer node, B. The B stands for "bad" (and not of the Mr. Bad
> variety). This -will- happen, no matter how much we emphasize the
> importance of trust -- look at PGP signatures for an example.
>
> Anyways, the node operator for A notices that it's been getting cancer
> data from B (and not of the breast self-examination variety). She
> sends a message to B* saying that he better knock it the hell off or
> she's taking him out of her trust list. B ignores her, and A drops
> him.
>
> A B - C - D
>
> Now, D notices the cancer data too. He gives C a warning like A did
> with B. C does some investigating and warns B. B fails to respond, and
> C drops B from her trust list. C then tells D about having fixed the
> problem, and D does -not- drop C (although he keeps a very good eye on
> data coming from that direction, believe you me). Now the network
> looks like this:
>
> A B C - D
>
> The threat of B has been isolated and removed relatively easily.
>
> As an alternative scenario, imagine that C is a dumb, lazy or
> obstinate node runner and fails to investigate the problem that D has
> reported. Then B and C will stay connected, but D will sever its trust
> of C. So the network looks like this now:
>
> A B - C D
>
> You can imagine a kind of "DumbAndEvilNet" growing out of the nucleus
> of the B-C pair, where ruthless cancer nodes feed on idiot node
> runners. Too bad, so sad. If you feel sorry for them, remember that
> without trust lists or some other mechanism, EVERYONE is part of
> DumbAndEvilNet, without much recourse to fixing the situation. One bad
> apple really does spoil the whole barrel.
>
A cancer node can do the following Bad Things:
a) return a bad KSK
b) not find a key and take up excess HTL or clock time
c) log connections, node addresses, etc
a) is your own fault for using KSKs; they are necessary to bootstrap the network,
mostly. Hence a potential DoS
b) will normally be routed around. a targeted cancer node could behave normally for
most keys, and drop a few known keys. if the user then tries again immediately, the
cancer node would still be closest to the target key, so would permanently block the
request? what attacks are possible here? workarounds include parallel requests after a
certain time, but that screws scalability and is possibly ungood for anonymity?
c) is pretty much unavoidable, although a closed trust network may be able to minimize
this.
> One thing I find a little strange is that we haven't had to deal with
> cancer nodes yet. It's not like we're not wide open to the problem
> right now. It kind of sucks that we have literature about cancer nodes
> on the Web site and nobody been interested enough to give it a try.
>
Because they require considerable resources to implement and run and rarely give
useful results, beyond just finding more nodes? For example, we rely on not knowing
what the contents of our nodes are. For information to be findable on freenet, you
need searching or indexing of some sort. It would be quite possible to construct a
freenet trawler which not only indexes hypertext but also creates a mapping from keys
without the decryption secret back to both the decryption key and the KSK/SSK/etc
pointed from. The argument then becomes "Why did you not use FredView, Mr Bloggs, when
you knew you might have illegal materials on your node? We used it after we seized
your PC and it shows you have $5200 of pirated software and twenty files of illegal
porn in your datastore.", which is rather more persuasive than the current situation.
The public network will always be vulnerable to such attacks, it is a function of the
network being usable.
> ~Mr. Bad
>
> * Can be email (since they ostensibly know each other OOB) or
> freenetmail. Actually, I was thinking it might be nice to make a
> convention of having "mailbox/[node address]/operator" be a
> freenetmail mailbox for each node's node operator.
>
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
