Reading through some old threads (catching up on some of the devl@ traffic I hadn't read yet), Matthew mentioned something that gave me an idea.
Perhaps the seednodes could connect to each other, verifying each other as valid seednodes. If there are trust concerns with just anybody's box being a seednode because of attackers and such, perhaps there could be two tiers of seednode, the first tier would be between only those were manually added to the first tier group of seednodes. The second tier could be automatically joined and verified by the trusted first tier. If this two tier seednode pool approach looks good and is implemented, I see a potential for the seedserver to merely need to talk to the first tier seednodes (to verify they're up ATM) and maintain a roundrobin A record list for a hostname such as seeds70.freenetproject.org (this layer can potentially have a pretty decent level of redundancy to mitigate DoS attacks). Seedclients could then be coded such that they merely need to make a connection to one (or more) of the seednodes listed in DNS at seeds70.freenetproject.org to get a list of FNP-level seednodes (i.e. members of the first and second tier seednodes) to connect to be used for announcement. The first tier seednodes could use a common pool of public/private key pairs, the public keys of which would be shipped with the installer. The installer has already passed a signature check at this point, so either the public keys are good and work on the seednodes listed at seeds70.freenetproject.org or the installer has been compromised and the public keys aren't good on an uncompromised seeds70.freenetproject.org, forcing both the installer mirror network source and the seeds70.freenetproject.org source to be compromised to silently compromise a seedclient. the installer mirror network and the seeds70.freenetproject.org source maintenance could be maintained in separate VMs on emu at a minimum and potentially on separate, geographically separated systems at the extreme. Both could be monitored by a stealth set of parallel operations (private instances of the seedserver software, not made public necessarily outside of the core devs and/or first tier seednode operators and potentially, private jar file build farms, pulling from public SVN/in-Freenet DVCS). If the seeds70.freenetproject.org list doesn't change too terribly quickly, the list could also be published in Freenet allowing potentially anonymous third-party verification. OK, now you can pick it apart... :) Matthew Toseland wrote: > On Friday 18 January 2008 18:41, Michael T?nzer wrote: > >> 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. >> > > Hmm maybe, sounds complicated... > >> 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. >> > > Well he can always try social engineering - ask to be on the list, we'll > probably put him on it. > > But if we can get 20 from people we know, and IF that is sufficient to deal > with a major slashdotting, then we don't need auto-harvesting. > >> 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) >> > > Yeah, this may be a problem.. you've moved from finding trusted seed nodes to > finding trusted verifier nodes, you still have the same basic problem, > although you hopefully don't need may of them. > > >> - 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. >> > > Another problem is preventing the attacker from getting a full seednodes > list. > This we need to deal with anyway, maybe by giving out a different set to each > IP. > >> 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.). >> > > This is to become a super-seednode? > >> 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. >>
