-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Toseland schrieb: > On Thursday 17 January 2008 03:23, Michael T?nzer (vid,smtp2) wrote: >> Matthew Toseland schrieb: >> | It would be good to solve the verification problem without having to have >> | permanent connections from the seed server to the seed nodes. The >> problem is >> | the below doesn't do this: it only verifies that the attacker is >> listening on >> | the stipulated port, and that he runs one freenet node somewhere, it does >> | *not* verify that there is a connectible node on the given node reference. >> >> Okay, so the only way to ensure that is to test it by trying to fetch a >> noderef (maybe our own to prevent that it only delivers refs of a >> honeynet run by the attacker - if that's possible (e.g. by requesting a >> key that matches our location and answer to that request). I don't know >> whether I have understood the Opennet ref swapping process properly) >> through the new Seednode. > > Fetching a noderef wouldn't help. >
As we want to obtain noderefs through the SeedNode, the only way to ensure that it's possible to get them is try it. And that's what we do. What is your suggestion? >> As we probably don't want to run a node on our server itself (we could, >> but would it have enough ressources to serve the important things like >> web pages, SVN and stuff even if we are /.ed?) the Seedserver has to >> have a connection to a node somewhere and as we have some Nodes which >> should be available anyway, why not use them? This also balances the >> load between the Seednodes, avoids another single point of failure and >> makes sure they're online so we don't have to recheck apart from that. >> We don't have to be connected to all of our Seednodes all the time. Just >> if we want to verify a new Seednode we establish a new connection to one >> of our Seednodes on the Port which on which the Seedservice runs and >> verify that it's us. > > You mean for the seed server to connect to the seednodes (easily spoofed), or > for the seednodes to connect to each other (somewhat less easily spoofed)? For the Seedserver connecting to the Seednodes. How is it supposed to be spoofed? - - Each packet that doesn't come from our Seedservers IP is dropped - - To accept the package it has to be encrypted with our public key (which _should_ only be known to us) - - The SeedServer has to verify itself, by sending back a random number encrypted with it's public key (only the SeedServer knows the private key to decrypt it an send it back) >> Doh, just reread the original proposal, that's something which I had on >> my mind but didn't write down: >> Each SeedNode runs a SeedService on a random Port and reports that Port >> to the SeedServer on the initiation process and keeps it up to date if >> it changes. The SeedService listens to requests of the SeedServer so if >> the Seedserver has to verify a new SeedNode it can ask the SeedService >> of an alredy established SeedNode (of course we recheck the identity of >> each other). > > Verify by connecting to it? See above >> This should also be portscanproof as the connection only can be >> initiated from the IP of our Server, so we can ignore the others. >> >> So the following attacks are left: >> - manipulated installer >> - DoS the Seedserver >> - DoS SeedNodes (not a problem if one SeedNode is DoSed but if they're >> all down - attacker needs some power to do this (e.g. big botnet) as >> there (hopefully) are quite a few SeedNodes) >> - Attacker as Seednode > > It's all about attacker as seednode. The trivial attack is to send in > completely bogus noderefs. If we beat that, the attack is to send in noderefs > to your own nodes, which only respond to the seed server, or the other > seednodes. Or to let anyone connect but never do anything useful after that. > And so on. > The completely bogus noderef is taken care of (the helping SeedNode obviously can't connect to a bogus ref) If the attacker only reacts to our SeedNodes (which he knows as he also can download the seednodes.fref) we have to check from "trusted nodes" from time to time. These are not published and will (hopefully) remain anonymous for a while. We have to keep te list of them up to date manually but we don't have to make shure they're online. They check the SeedNodes from time to time, whether they can get good (e.g. their own, as mentioned above) references from it and report to the SeedServer if not. If at least two Trusted Nodes mark a SeedNode as BAD we drop/disable it (drop it if the other SeedNodes are able to connect through it). We also should use a limit until we take new SeedNodes, so we always about 20 online SeedNodes (or more if the load is big) but an attacker can't hold 80/100 SeedNodes which have to be disqualified. So the good SeedNodes supersede the bad ones. >> - Honeynet (the attacker could turn the honeynet off when we check him >> and turn it back on once the check is done - maybe SeedNodes should >> check each others functionality from time to time without announcing it, >> but don't they have enough load to carry? Another solution is, that a >> new Client always tries to get refs from at least 3 SeedNodes and check >> whether the peers are connected (trying to get the refs of peers he got >> from one SeedNode through peers he got from another one)) > > A client tries lots of seednodes. The main thing we want to defend against is > an attacker swamping the seednode collector with many useless or nonexistent > nodes. If he has access to enough IPs, he can swamp it with his own, > functional but malicious nodes, there's not much we can do about that. :| regards Neo at NHNG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHj9gXPUBAMhFf+J4RAhQfAJ4tFtX1SRsqpy63TQp6OgqQtkjnpACgocgx HElZmOd+HBgr/bpSEGxWBY0= =w8XF -----END PGP SIGNATURE-----
