-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Toseland schrieb: > On Thursday 17 January 2008 23:06, Michael T?nzer wrote: >> Michael T?nzer schrieb: >>> Matthew Toseland schrieb: >>>> On Thursday 17 January 2008 03:23, Michael T?nzer (vid,smtp2) wrote: >>>>> Matthew Toseland schrieb: >>>>> 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) >> Doh, of course the public key is known by someone else (otherwise it >> wouldn't be public) it should be only known by the _SeedServer_ because >> he's the only one we gave it to. But it also shouldn't be a problem if >> it get's known in public, then the second part of the identification >> process comes into play: > > That's not what I mean. I mean an attacker's bogus seednodes know the IP of > the seed server and can easily only respond to that IP address, thus saving > lots of bandwidth and not providing any useful service to any other node. > Also, if it's only verified shortly after adding, they can use this info too.
That's what my proposal in the other mail prevents: There are a few trusted nodes (not SeedNodes) which report to the SeedServer when they've found a SeedServer wich is not responding/only sending bogus but they will connect on random not on command of the SeedServer, so it should be harder to discover who our trusted nodes are (maybe every Node reports but only a few are trusted (maybe with a certain probability to reduce traffic), so the traffic of the trusted Nodes is covered by the untrusted ones). But I think we would still need the other check to avoid good SeedNodes getting blacklisted because if we can't connect with at all (neither with Seednodes nor with trusted peers) that's likely to be a nodecrash or something but if a SeedNode is connectable to other SeedNodes but not to trusted peers that is likely to be malicious and the IP should be blacklisted for 24 hours. And I believe it's important to set a limit to the number of SeedNodes. So if we've got 20 good SeedNodes an attacker can do whatever he wants (ha can do perform headstands as we say in Germany) he won't appear on our seednodes.fref. If some attacker is on our list and we detect it, we'll kick him from our list and hopefully another good SeedNode will turn in for him. Backdraws: - - an attacker will try to turn down the good SeedNodes so they will be listed as disconnected (maybe we should keep a list of disconnected good SeedNodes which we will try to connect to on their SeedService so another good SeedNode can take turn for the DoSed one) - - If an attacker has turned down a SeedNode he will start to connect with his fake nodes immediately but our unlisted good SeedNodes probably don't know when to connect and when they check back whether a slot has been freed, they will be too late. As an attacker will (hopefully) be likely to not stay long on the list, we probably want to add some Captcha/hashcash/essay why he should be on the list/whever to prevent scripting (maybe provide some timed captcha (a captcha which times out, so it needs to be answered quick and is less likely to be passed on) which is asked for when the "SeedNode-mode" is enabled and all SeedNodes which solved that captcha are kept on a list (the list also includes NodeRef, SeedService-Port and public key), from which a node is choosen at random to go through the verification process (another SeedNode fetches ref through it etc.). Well this is getting pretty complicated but it should do the job and as we don't want the access to freenet (the process on which we afterwards build our anonymity) to be insecure or not working (this will push people to return to the "old ways" (ref trading)) and haven't come up with a better/easier solution we could either stay with the old system (which afaics not working because people actually have to do a bit of work (they have to paste the noderef into an email, adress it to toad and enable encryption) which is against the 5-clicks rule, which is solved when people only have to enable SeedNoding and solve a captcha) or implement the new (although pretty complicated) system. But maybe someone has a simpler solution or can point out where we can reduce complexity in the given one. >>> - 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) > > I accept that you can't MITM the SeedServer ... but you can watch its traffic > and identify seednodes. That's probably unavoidable. As SeedNodes are public anyway (unless we do it even more complicated and let one user only see 3 SeedNode-refs which is IMHO not working) they don't need to be identified via watching traffic, so yes that's unavoidable. regards Neo at NHNG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkPLdPUBAMhFf+J4RAlJEAJ0QiVSvbbQlam6Fwwsr0O7ToSNI/gCfT0Ig UThty9MS2xsYTydUcSPkjkQ= =pr7r -----END PGP SIGNATURE-----
