Document Threat Model and Risk Mitigations

[lidel]

Overview

Let's assume IPFS nodes fetch autoconfig.json from URLs configured during app init (e.g. ipfs init), typically from https://config.ipfs-mainnet.org/autoconfig.json. This dynamic configuration mechanism introduces security considerations that need to be documented and addressed.

Current Implementation

• Nodes fetch config from HTTPS URLs only (no HTTP)
• No authentication or verification mechanism
• Config contains routing systems, bootstrap nodes, DNS resolvers, and delegated endpoints
• Cached up to 24 hours (CacheTTL: 86400)

Threat Model

graph TD
    A[IPFS Node] -->|HTTPS Request| B[config.ipfs-mainnet.org]
    A -->|DNS Query| C[DNS Resolver]

    B -.->|MITM Attack| D[Attacker-Controlled Server]
    C -.->|DNS Hijacking| E[Malicious DNS Response]

    D -->|Inject| F[Malicious Bootstrap Nodes]
    D -->|Inject| G[Malicious Delegated Endpoints]
    D -->|Inject| H[Malicious DNS Resolvers]
    D -->|Send| I[Malformed/Oversized Response]

    F -->|Result| J[Node joins attacker's swarm]
    G -->|Result| K[Traffic routed through attacker]
    H -->|Result| L[DNS queries intercepted]
    I -->|Result| M[DoS/Resource exhaustion]

    style D fill:#f96,stroke:#333,stroke-width:2px
    style E fill:#f96,stroke:#333,stroke-width:2px
    style J fill:#faa,stroke:#333,stroke-width:2px
    style K fill:#faa,stroke:#333,stroke-width:2px
    style L fill:#faa,stroke:#333,stroke-width:2px
    style M fill:#faa,stroke:#333,stroke-width:2px

Loading

The website should include Security section with FAQ how to deal with the above threats.

[lidel]

Below is initial attempt at defining threat model and how it compares to existing risks in ecosystem + how security conscious deployments can mitigate.

cc @aschmahmann + @gammazero @hsanjuan as we've discussed some of this during GO Triage today.

I did not include signing JSON because I feel if someone is worried about the above risks, they will not use AutoConfig at all, and have hardcoded values in config (ipfs config profile apply autoconfig-off), but lmk if you feel its worth making spec, implementations and deployments more complex by adding some type of signature.

Attack Scenarios

1. MITM Attack on HTTPS Config Server

Threat: Attacker intercepts HTTPS connection to config server

• Vector: Compromised CA, BGP hijacking, DNS cache poisoning, Github permisions
• Impact: Limited control over node's routing configuration
• Likelihood: Low (requires significant resources)

1.1. Malicious Bootstrap Node Injection

Threat: Attacker injects malicious bootstrap nodes

• Impact:
  • Node connects to attacker-controlled swarm
  • Potential for eclipse attacks
  • Content censorship or manipulation
• Likelihood: Low (requires perfect timing during the very first time ipfs daemon starts, when it has no peers cached by boxo/bootstrap service that preserves % of random peers as extra bootstrappers)

1.2. DNS Hijacking

Threat: Attacker swaps DNSLink resolver and controls DNS resolution for ENS (.eth) domains

• Vector: Compromise of config.ipfs-mainnet.org or github repository
• Impact: Resolution of .eth domains redirected to attacker
• Likelihood: Low (if someone can hijack config.ipfs-mainnet.org, they can do the same to dns.eth.limo or dns.eth.link)

1.3. Malformed Response DoS

Threat: Server sends malformed or oversized response

• Impact: crash/panic, resource exhaustion, service unavailability
• Likelihood: Low (sane implementations will have max response size limit)

1.4. Privacy Considerations

Threat: IP/PeerID correlation via bootstrappers and /routing/v1 endpoints

• Impact: Limited - nodes already reveal this via DHT/Bitswap
• Likelihood: High
• Severity: Low (compare with how public swarm works)

Implementation Best Practices

ipfs/kubo#10883 prototypes some best practices:

• Input Validation

  • validate URLs and Multiaddrs before use
  • ignore malformed values

• Defensive Parsing

  • set maximum response size
  • ignore unknown fields for forward compatibility
  • interpret nil/null/undefined as empty collections

• HTTP GET failure handling

  • exponential backoff with jitter
  • mainnet: fall back to hardcoded config

Mission-Critical Deployments

We may want to update docs/config.md (in Kubo) and index.html (in this repo) for Mission-Critical Deployments:

• Static Configuration: use hardcoded values instead of dynamic fetching
• Config Pinning: pin/self-host specific known-good config versions
• Fallback to Hardcoded Values
  • implementations may still maintain hardcoded bootstrap nodes and endpoints
  • use as fallback when fetch fails or returns invalid data
  • prevents complete DoS

[aschmahmann]

Something perhaps obvious that I think we should codify to help reduce threats here is that the implementations should not allow the AutoConfig to handle ICANN DNS resolution (i.e. .eth, .crypto, .dwebyolo is fine but .com, .dev, .uk is not).

Probably the scariest risk in this whole section is the ability to get a compromised DNSLink response which misleads you into interacting with the wrong website / application. AutoConfig isn't really worse than relying on something like eth.limo because it's adding a second point of failure (not good) in exchange for allowing the implementers and deployers of the software to better handle issues (good).

Really, I wish IPFS implementations had more native validation here rather than just delegation (in the case of ENS likely relies on things getting better in Ethereum / ENS land) since it can result in getting the wrong data. However, for delegation we're stuck with this anyway.

[aschmahmann]

but lmk if you feel its worth making spec, implementations and deployments more complex by adding some type of signature.

I'm not sure we need to start with this since we're not qualitatively changing the types of attacks that can be done here. IIUC Tor does something like this with its list of Directory Authorities and how they sign their consensus documents. My guess is that the extra complexity in the spec + implementations for handling the signatures ends up being less than the mechanics around who has the keys, how many keys, how to handle key rotation / expected update time for implementers, ...).

If folks feel this needs to be done now though I can be convinced 🙃. Side note: I could also potentially be convinced to use a blockchain anchor, but my impression is that in practice you'd be asking users to choose one centralized endpoint over another because of the extra weight and complexity involved in blockchain light clients today.

[hsanjuan]

from https://config.ipfs-mainnet.org/autoconfig.json

Part of me wants to use one of the existing domains, but I guess it's good to separate.

Re signing etc., it probably doesn't hurt to publish the current configuration/checksum in other places, so that people have an additional source to verify that what the daemon downloads from that url corresponds to what we published somewhere else (ie. in dist.ipfs.io). In case of hijacking it should be "easy" to verify it.

One possible impact that I don't see listed is the exploitation of bugs in the JSON-parser (or in the Kubo config parsers) to achieve exploits, as a result from hijacking of the config.