On Aug 27, 2010, at 10:33 AM, xor wrote: > On Friday 27 August 2010 12:22:05 am Matthew Toseland wrote: >> Currently, an attacker can run a malicious seednode, send us it, >> and then >> get connected to a large proportion of new nodes, use bogus >> identities to >> keep connections to the node, and observe their traffic.
Good observation, though I am not sure who/what would be interested in spying on freenet newbies without also trying a hostile takeover of the entire network. Whereas the attack presumes a node still bootstrapping into the network, I think that a good solution would include onion routing (already mentioned). Specifically that pathfolding requests would be included in the onioned/signed response, and a bootstrapping node could then pick out the 'deepest' identities to make such an attack less likely (or at least require more resources/network control). >> We can of course increase costs by requiring nodes to be on >> different /8's >> or /16's etc, but this only slightly increases costs. Some sort of >> onion >> routing involving peers found via different seednodes would be >> possible, >> but clunky as later on seednodes don't really matter, and extremely >> expensive. > > I disagree. It would make the stuff a lot more annoying to set up > and it would > be easy to implement. I'll take a third position. As a strict connection rule that might be bad, but I think that the freenet client having an idea of the ip- network setup could be a good thing. Although technically involved, it may be possible even to do a trace-route to try and avoid as many common routers as possible. > OTOH it might seriously screw performance because it would probably > cause > peers to be chosen from bad locations internet-topology-wise: > Countries like > germany have *HUGE* ISPs which resell their infrastructure to > smaller ISPs so > most german users will probably be in same subnet of some order. (I > have not > checked whether that actually is the case, I'm guessing) ... If we > limit > connections based on subnets, peers might always be chosen from > different ISPs, > leading to bad performance... I think that toad is only speaking with respect to the bootstrapping process. > Maybe the set of possible peers could even get exhausted... In the bootstrapping process that is probably not a bad thing. To me that would indicate the bad guys provided the seed nodes, and if the only available peers were bad guys, that is arguably the correct course of action. > We could even change fred's behavior to auto-enable seednode mode if > the node > detects that > - its opennet port is open > - it's IP stays constant for >N days OR it has a constant host name > (=dyndns) > > That would probably give us a load of seednodes, which would > certainly help > security AND improve the announcement speed because the seednodes > would not be > under very heavy load. This would also help the first time usage > experience. > > AND it would cut down our seednodes.fref manual maintenance cost to 0. I concur with xor's auto-seednode idea provided that nodes can automatically fall off the list too. Using freenet+opennet already implies untrusted connections & network support. -- Robert Hailey
