On Thursday 02 December 2010 19:19:43 Ian Clarke wrote: > So there is a potential threat against opennet that we need to think about > how we can either address or mitigate, hopefully without making Freenet's > performance any worse. > > I call it the Barlow attack, because I've noticed that John Perry Barlow > seems to be connected to everyone I know on various social networking > websites :-) > > The attack is two-stage: > > 1) The attacker attempts to connect to as many opennet peers as possible, > and maintain open connections to them. It does this by announcing a lot, > accepting as many connections as possible, and trying to respond to requests > promptly with a good success rate so that peers stay connected. The > attacker may do this using a number of nodes > > The attacker records the key of every single insert and request coming from > every peer. > > 2) Then, let's say that someone uploads a large file, and the attacker would > like to find the uploader. They simply look at all the pieces of this > insert, and identify the peer from which most of these originated. If they > happen to have a connection to the uploader, then there is a decent chance > that this peer is the original inserter. > > We can make this attack more difficult by thwarting either or both of these > stages, or at least making them more difficult. > > For example, we could make 1) more difficult if, any time we see two peers > in the came class-B address range, we disconnect from both of them, or at > least never route anything to either of them. > > It may not be possible to completely prevent this attack, which is why we do > encourage people to use darknet mode as soon as they are able, particularly > if they have legitimate cause for concern. > > Thoughts? > > Ian.
As I see it there are four stages: 0. Clarify the opennet warning. IMHO we need to ask the user about opennet vs darknet *before* we ask them about network seclevel in more detail. We need good wording that explains that opennet is not particularly safe, and is essentially a testing mode. Klaus has a good first draft for this. WE NEED TO DO THE FIRST STAGE ASAP. 1. Low hanging fruit. Stuff like should we random route while at max HTL, can we make the attacker do a bit more work before he gets local/high HTL requests, can we make it possible to require peers to be in different countries, IP address restrictions on a single node, etc. Some of this might happen in the near future. 2. Global IP-level restrictions. I have a proposal for this, in another mail. The catch is on opennet you will need to re-authenticate with the seednodes every time your IP address changes, and it may be slightly easier to find the IP addresses of all live opennet nodes. However that is pretty trivial already. We can require that only one node be run on any given IP at a given time, and we can limit the number that can run under a given /24. We could limit it by /16's but I am worried that sometimes we will have problems with a group of people on the same ISP etc. Another possibility is we could try some PeerGuardian-style range blocking e.g. only allow IPs classed as domestic to use opennet at all. This could be quite a bit of work, but should increase costs considerably when the network is large. 3. Tunnels. There are two types of tunnel: a) Rendezvous tunnels: These are over Freenet, and don't require setting up any new connections. They involve sending a series of anchor requests through different nodes, each routed partly randomly and then to a location, each with a part of a shared secret, which is used to set up an encrypted connection when they meet. However, to get a reasonable anonymity set, the tunnel would have to be many hops - comparable to the network diameter, at least 5 hops, probably more. On darknet, the real threat is mobile attacker source tracing (gradually working towards the originator based mostly on predictable requests), so tunneling only those blocks that are predictable in advance may be useful without hitting performance too badly. The really paranoid would want to tunnel everything of course. b) Onion-style tunnels. These would require setting up new connections purely for onion routing. This is very similar to Tor or I2P and would reuse very little of Freenet's existing code beyond the transport layer. IMHO it is not worth us implementing our own onion layer, it would be a lot of work for little purpose. Ian is strongly opposed to integrating with somebody else's onion layer. This is worth thinking about for the long term. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101207/9c5b7f9e/attachment.pgp>
