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. > > regards > Neo at NHNG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080118/b73f4d20/attachment.pgp>
