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 :-)
LOL. > > 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 One key point you missed: Always path folding to one of its alter ego's. An attacker would have several virtual nodes (whether they actually have separate datastores is irrelevant), with separate IP addresses. Given the bandwidth required for this sort of attack, this may well be the cheapest way to do it, but it certainly helps avoid some of the more trivial countermeasures, and more importantly *it keeps you connected even when announcement is flooded out*. Also, IMHO at present it is not necessary to answer most requests successfully, but we may be able to force the attacker to do so. Options include: - Only sending high HTL requests to well-established peers. Unfortunately there would have to be an exception for peers obtained via path folding (since we might have path folded to a distant peer due to a local request, and if we don't send it high HTL requests we won't send it *any* requests) - but newbie nodes from announcement could be excluded from high HTL requests. > > The attacker records the key of every single insert and request coming from > every peer. > > 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. > This is worth implementing, although it is relatively easy to workaround by e.g. using three servers on different IP addresses on different hosting companies. If you need a large number of separate IP's it gets more difficult, and VPNs are likely not a viable solution due to bandwidth concerns. Nextgens, just how cheap are IP addresses on unique Class B's? We do have a variant which relates to a single IP address, but it's buggy atm. Also, this might reduce performance quite a bit by making it less likely nodes connect to other nodes on the same ISP. Opennet does take performance into account via means of LRU. I wonder if we could create a collaborative mechanism for identifying ubernodes - either single nodes or IP ranges with very large numbers of connections? Making it secure without giving too much information away might be a big challenge... > 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. Right now an attacker can obtain up to 30% of a node's total outgoing requests, and probably up to 100% of its local/high HTL requests. FOAF enables the attacker to customise its locations to grab the largest possible slice of the keyspace, and the more of the keyspace you have, the more local requests you get. Remote / low HTL requests don't matter, in fact we don't want remote requests. The 30% limit prevents them from monopolising everything. Also, even without FOAF, if a node is distant from its neighbour, it is likely to see a significant proportion of its requests: We aim for a few long links and a lot of short links. Most of the local or high HTL requests will be routed to the few long links. If we do a lot of local requests we have more long links; if we do few local requests we have fewer long links. FOAF amplifies this, but it also improves performance significantly; abolishing FOAF would not in any case solve the problem. Thus it might actually make sense to random route for the first few hops e.g. while at maximum HTL. This would limit each node to its fair share of our high HTL requests. The catch is most of the guesstimates of what it would cost to pull off this attack *assume we are already doing this*, so at best this takes us from a ridiculously easy to a merely pathetically easy one! Practically it would mean that an attacker needs more samples i.e. it would increase the minimum size of the file, or the minimum number of chat posts, needed to do the correlation. > > We can make this attack more difficult by thwarting either or both of these > stages, or at least making them more difficult. IMHO with the steps listed above, we can: 1. Force the attacker to obtain multiple IP addresses on different class B's. (Increases cost in that he can't use two nodes on the same host, so may need a big system instead of many small ones, and that he needs to use multiple hosts) 2. Force him to at least occasionally answer requests. (Increasing bandwidth requirements per peer from hundreds of bytes per second to *maybe* approaching kilobytes per second; given that nodes severely limit the number of nodes they accept, always path folding to oneself probably doesn't remove the need to hang on to connections once you have them) 3. Ensure that he never sees more than his fair share of our local requests on the originator node. Without these steps he probably needs hundreds of bytes per second per peer and can use many nodes on whichever host is cheapest. With these steps he probably needs kilobytes per second per peer and will have to use multiple hosts, and may have to use either a lot of hosts or very large nodes on them. IMHO in both cases this is feasible relatively cheaply on the current network: a plausible worst case estimate is 9000 * 3KB/sec * 2 connections/peer = 54MB/sec, sustained (although you don't necessarily have to keep doing this attack for months if you're looking for people inserting big files), plus hardware, plus development costs (small imho, much less than a full time geek). With ubernode detection (which probably isn't feasible) we could maybe force him to hire one IP address per virtual node (so he'd need approx 225 of them). What the cost of that would be I have no idea, I suspect it could be obtained more cheaply than a typical end-user VPN but otoh he'd need a reasonably good VPN as he'd be using a fair bit of bandwidth constantly... $10/mo would add another $2200/mo, the costs mentioned above probably aren't much more than that and could be considerably less ... > > 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. Right. And we need to consider exactly what we can say about opennet's security on the first-time wizard. PS I wonder if it would be possible to have a fixed topology? We have fixed locations already on opennet and a lot of opennet peers have quite high time-since-connect. If we didn't need to dynamically move connections, we could tie the whole thing to some scarce resource - the problem then being defining such a scarce resource: Hashcash is far cheaper for an attacker than for a newbie with a slow computer, CAPTCHAs are an essentially intractable problem which will sooner or later be conclusively lost and in any case solutions can be bought very cheaply, but OTOH there are some very creative CAPTCHA solutions, some of which may be hard to automate (and despite it being an arms race, whole industries depend on CAPTCHAs working); realcash (e.g. donations) is a possibility but has its own difficulties (e.g. getting people to cough up!!). > > Ian. -------------- 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/20101202/b45eb416/attachment.pgp>
