Since Eleriseth announced he was leaving and we should focus on speed/usability, then opennet security, and only then darknet, I have been looking into options for securing opennet, and discussing this with various people.
The main attacks here are: - MAST: Listen for a predictable request/insert, triangulate roughly where the originator is on the network based on the requests you receive, announce to that location, repeat until you have the target. Cheap. Really, really cheap. - Surveillance: Connect to every node, log all the inserts for a month (freenet content doesn't last long if not requested). Connect it to announced content. Surprisingly cheap, given our relatively low bandwidth usage per peer etc, and it will become cheaper per node as the network grows because bandwidth (and everything else) gets *really* cheap in large volumes. This is a Sybil attack: The only way to beat it is by using some sort of scarcity. Unfortunately, tunnels are still vulnerable to Sybil attacks. In particular, tunnel setup is often vulnerable to such attacks. If we can create meaningful scarcity, then we can have tunnels and an interesting level of security. If not, tunnels aren't necessarily a big gain. Bandwidth requirements / scarcity by bandwidth usage ---------------------------------------------------------------------- We could require that core opennet nodes have some minimum level of bandwidth available, possibly requiring a given uptime as well, in order to stay connected as core opennet nodes. Other nodes - transient nodes - would then not route traffic, and would have limited connectivity to core nodes, so would be slower too. This would significantly increase bandwidth usage on the fast nodes, and improve performance for those able to run core nodes. The question is, what effect would this have on users? Would we lose a lot of core nodes, and thus have much less storage capacity, or would we be swamped with filesharers and gain capacity? Scarcity by IP address ---------------------------- Currently individual seednodes limit announcements per IP address per 24 hours. We could make this a collective limit, and limit the number of different locations you can announce to (which would make some easy attacks harder). More complex schemes would create the random location on the seeds/bootstrap nodes, and allow us to ensure that one IP only has one (or two) nodes, which only have up to N connections each; this would make a lot of attacks harder. Ensuring that there aren't too many nodes per IP address would require that nodes connect to the seed/bootstrap central nodes when they change IP address, and might require them to do so periodically (meaning a DoS attack would not only take out the ability to announce new nodes but also may affect existing nodes fairly quickly). It is also possible to do this in a more distributed way (which would be more robust) but it would be a lot more work. Unfortunately, scarcity by IP address probably doesn't greatly increase the costs of a Sybl attack: - Resetting your DSL modem: For lots of people on dynamic IPs, this is a free way to get a new IP address. Of course you can't use the old IP address at the same time, so some of the more expensive measures mentioned above may help. Spoofing is also a possibility. - Botnets: Illegal, but relatively cheap. Can happen, and not only if your enemy is openly criminal. - VPNs: Roughly a few dollars per IP per month. This is a definite improvement on the status quo. - IPv6: You can get large IPv6 allocations relatively cheaply, and it is not easy to detect this reliably AFAICS. Scarcity by money ------------------------ We could require a small donation to become a core opennet node. Combined with the above measures this would probably be an effective deterrent to moderately funded Sybil attackers, especially on a large network. And the money would be helpful too, although in the long run this is a deterrent rather than a fundraising exercise, so we could have most of it go to other charities. IMHO there are significant costs to running Freenet, most of which can be expressed in $: - Bandwidth, especially if you end up paying for going over limits, your other access gets throttled because of high usage, or you get a more filesharing-friendly ISP (= a more expensive ISP), or more bandwidth (particularly upstream), as a result of using Freenet. - Hard disk space, and wear on hard disks caused by increased load. - Electricity, especially if you run your computer 24x7 just to run Freenet on it. Arguably most of these don't apply to most Freenet users: Either they are students who don't pay their own utilities, or they have to have a fat pipe anyway for other filesharing, etc etc. And then there's the "anonymity" thing: Paying for something isn't "anonymous". The fact of the matter is that installing Freenet from the website and using it on opennet isn't anonymous: At best, what you do with it might be anonymous. But people don't understand what anonymity is, and don't understand the relative cost of different attacks. Making it difficult to have a sensible conversation about anything... How many nodes would this cost us? Would we end up overloaded with transient nodes? Maybe. Note that existing users wouldn't be affected, we can bring them in subject to IP and bandwidth restrictions. But there are always people joining and leaving, and if the joining rate dropped significantly we'd be in trouble. =========================================================================== Conclusions? Feedback has been mixed, and there's been a lot less than I'd hoped for. Most of it negative, and related to the last option; if you have opinions about the first two that'd be interesting. Almost everyone wants a secure opennet and almost everyone argues that darknet is impossible, but if all the plausible ways to implement a secure opennet are unacceptable, it ain't gonna happen.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
