Censorship resistant bootstrapping (e.g. for wikipedia)

[ianopolous]

Version information:

N/A

Type:

Enhancement

Severity:

Medium (unless you're in Turkey, then High)

Description:

I was thinking about the attack vectors for censorship of the recently hosted wikipedia in Turkey, and I believe a significant weak point is the bootstrap process. Currently it is a hardcoded (in a config file) list of domains/ips. This is public and easy for an oppressor to add to a blacklist.

One proposed mitigation to this would be to have a fallback bootstrap method which used Tor. Tor have thought a lot more about attacks in this area, and using them would be easy. The simplest would be a Tor client that just contacts one of the bootstrap nodes through Tor to then bootstrap via. Clearly this is only as strong as the Tor bootstrapping mechanism, but as mentioned above that is a well studied problem.

This would mean that a binary of ipfs that was distributed in Turkey through USB sticks would still work even if ipfs.io and all the public ipfs bootstrap nodes were blacklisted.

[Kubuxu]

Ides which we had was to use already known nodes for "after the first" launches. Also we could ship IPFS with hundreds of nodes weight sorted according to some criteria and use both of those mechanisms at the same time.

[ianopolous]

@Kubuxu I thought that once a node had bootstrapped once it didn't need the bootstrap nodes again? Does it use them every time it restarts?

[ianopolous]

I think if they are going to blacklist your bootstrap node list, then it doesn't matter how long the list is.

[Kubuxu]

Unfortunately, currently yes.

[ianopolous]

Ok then that's an independent problem to address, but I would say that is a lower priority than a proper Tor based fix (which would solve both problems for many threat models).

[Kubuxu]

How does the TOR bootstrap? Wouldn't it face similar problems?

We for sure can run TOR hidden service with ever updating list of nodes one could bootstrap off.

[ianopolous]

Tor does face similar problems, but they have spent a long time trying to solve them, for example using unpublished bridges rather than the public directory servers.

[ianopolous]

Note I wasn't suggesting running a Tor hidden service in the simplest case, just using Tor to access a public ipfs bootstrap node.

[djdv]

@Kubuxu

Also we could ship IPFS with hundreds of nodes weight sorted according to some criteria and use both of those mechanisms at the same time.

Would something like a dynamic list be useful, where it's populated with nodes sorted by daemon uptime (as well as adding some randomness to the selection process)?
For instance a list of nodes that's generated/published to ipns every few hours. It might help against static blacklists that are manually updated, but I don't know how common that kind of setup is, so it may be pointless.

In addition there's still the matter of connecting to grab said list for the first time, either through IPNS or something else. The only connections you could really rely on communicating with would have to be things something like mDNS would pick up on, physically close ad-hoc networks used for bootstrapping, then you could either do peer exchanging or maybe message relaying. I've got no idea on that aspect.

[matthewrobertbell]

A possible option would be to take inspiration from how botnets work: Use a dynamic set of domains / subdomains (changing over time) to publish a list of bootstrap nodes which change over time, either via HTTP or DNS TXT records.

Another idea is domain fronting it e.g. with google cloud: libp2p/libp2p#18

[elitak]

I suggest adding cmdlets for as many methods to circumvent that can be imaginied, e.g.:

ipfs bootstrap scrape raw file:///mnt/usb/bootstrap-list.txt # provide support for as many URI schemes as possible, including ssh://, magnet:
ipfs bootstrap scrape tor # grabs a list from wellknown1.onion, wellknown2.onion and adds it to bootstrap list, via the http proxy hooked up to tor on localhost port NNNN(changeable in config)
ipfs bootstrap scrape domain-front reputable-domain.com #sends some standardized request over https, requires complicity by the reputable-domain
ipfs bootstrap scrape dns fast-or-double-flux-bootstrapper.com
ipfs bootstrap scrape irc irc.efnet.net ipfs-bootstrap # talks to a bot on that server+channel in a predefined way
ipfs bootstrap scrape twitter @username # reads tweets in rev-chrono order on this account and interprets them as URIs to dial until N successes
ipfs bootstrap scrape bittorrent-dht # use bittorrent DHT to find potential endpoints; i.e., ipfs running on same addresses. That subset is selected by fetching a specific torrent that signifies the host also acts as an ipfs bootstrap node
ipfs bootstrap scrape netscan # last hope; just dials IPv4/6 addresses randomly on port 4001 until it hits something

Some of these are trivial to implement as bash scripts. In Go, it would take (me, at least) a bit more effort, but each could be written conforming to a simple plugin API, then static-linked in along with whatever meta-bootstrap data are needed.

[kpcyrd]

@elitak that might integrate nicely. Given the command ipfs bootstrap scrape foo arg1 --arg=2, ipfs could try to execute ipfs-bootstrap-scrape-foo-fetch arg1 --arg=2 and read addresses from it's output. This way you can write plugins for bootstrapping in any language, similar to how git works. Preferably the command would be shorter.

As an alternative, I think you can always add nodes using the ipfs api with a project seperate from ipfs.

[whyrusleeping]

ipfs does have a method for allowing git-style pluggable programs as subcommands (ipfs update works this way). Its currently whitelisted so ipfs has to at least know it should try searching for a given external subcommand before it will work.