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
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl