On Monday 06 August 2007 22:28, Matthew Toseland wrote: > FROM FROST: > > On Wednesday 01 August 2007 21:23, NextGen$ wrote: > > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-07-26 20:01:34]: > > > On Thursday 26 July 2007 04:14, NextGen$ wrote: > > > > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-07-25 18:39:11]: > > > > > I propose that darknet nodes be allowed to forward announcements > > > > > and path folding messages (ConnectDestination etc), without > > > > > including their own noderefs. > > > > > > > > > > Any objections? > > > > > > > > _o/ > > > > It's a bad idea. > > > > Be informed that my node wont behave that way... > > > > > > Why, precisely, is it a bad idea? As far as I can tell it doesn't > > > compromise the nodes which only relay and never send their own noderef? > > > > It makes flow analysis related attackes both trivial and more effective. > > > > I'm really dissapointed that you implemented it before leaving me time to > > respond. You did so even though I explained to you my concerns on IRC... > > > > I told you about an attack vector (flow analysis using request size - > > arguably already present but currently not easily exploitable) then we > > disccused about workarounds (padding noderefs, limitating the number of > > refs per request) and didn't manage to find any 'good' solution. > > > > Your implementation doesn't even feature basic workarounds we talked > > about and you have enabled that 'risky' option by default :( > > > > I don't mind about opennet beeing insecure but don't lower artificially > > the security level provided by darknet. > > > > NextGen$ > > First, what kind of flow attack do you mean and why is it currently not > exploitable but would be exploitable after that new feature? You know, such > stuff is somewhat interesting in networks like freenet, it doesn't hurt to > mention it publically. It might even make it simpler to find a solution you > know ... > > Second, "lower artificially the security level provided by darknet" is what > was done in the past to debug it, or due to time constraints, talking > about "this is alpha, bear with it until it gets removed/fixed in > months/years". I don't see the point why another temporary weakening is > that important to you. It may serve another purpose and that purpose may be > less important or perhaps the security issues are worse (how should I > know?), but contrary to the weakenings for debugging reasons it may > actually get fixed in reasonable time. There is even the chance of fixing > it before releasing another version. > > Third, as said above, it is only available in trunk, not in a live build. > > Forth, not making it the default would render it useless. How about > not "fixing" the problem by removing stuff for which you don't care, > crippling it or rendering it useless, but just fixing it completly, even if > that means waiting with another build for a week. > You know, given freenets history I would bet that else it will just be left > as it is for months if not years, as everything that works somewhat. > Talk about link crypto that allows MITM and is DoSable (the first was fixed > after ~1 year iirc, the second is finally a SoC project after at least one > and a half years), not resuming SSK inserts, not resuming requests, thread > madness, plugin interface confusion, ... > It all works somewhat, possibly not as well as it should, possibly not > helping/protecting as it should but it works in one way or another. Other > things seem more important, thus its left as it is. And left and left and > ... Fix it right away or it will be postponed forever. Not to blame any dev > for that, simple time constraints and the resulting considerations will > cause that if it works, even if just somewhat, and time constraints are > admittedly a huge problem with freenets development. But it still doesn't > make the result any better. > Sorry for this rant but I do get frustrated over such things, given enough > time. :|
The flow attack is real. All an attacker has to do is send an exceptionally large noderef, either from the data source node to trace the requester, or from the requester node to trace the data source. This could be tracked back to source assuming you can observe the packets between each pair of nodes on the chain, because it would cause a very large (fragmented) packet to be sent at each node. However, we *will* solve the problem, most likely by making noderef transfer happen in a bulk transfer (the other option would be binary references). Whether that will be done before the next stable build, I dunno; how vital is it? DoS on link crypto is not a big deal. You can only do it if you have the noderef of the node you are DoSing, and if you do, you can do lots of other fun things to them too (seize their node, kidnap them and render them unto the interrogators...). I accept that there are lots of bugs and even more unfinished features; we have to work on what appears to be the highest priority at the time, right now that's opennet. Request resuming isn't absolutely necessary, but I've made some progress on architecture for it so I may implement it before 0.7. -------------- 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/20070806/697334db/attachment.pgp>
