A few observations and concerns about general security defaults as well as network traffic encryption.
- IPFS Directory
ipfs init creates a folder for all ipfs settings and storage at
~/.ipfs … This is fine, and works well as a basic default location for most general purposes. The permissions on the directory are set such that all users on a multiuser OS have read access. Again, this is a fairly standard default setting for most *nix systems.
However, there are significant security issues with allowing all users read access to the ipfs directory. A saner default would be to mimic ssh and set the directory to 700 permissions, xrw for the owner and none for everyone else. This change to the default init would ensure that the node’s private key is not readable by other non-root system users.
- swarm keys
Private IPFS swarm keys don’t seem to have any checks for appropriate filesystem permissions. As with the IPFS Directory permissions, private network swarm keys would probably be a little safer if the daemon would reject any keys that don’t have 600 or 400 permissions.
- IPFS traffic cover
Private IPFS networks using swarm keys seem to authenticate using a swarm key derived one-time use session key. This may or may not work well against a replay attack. I haven’t tested it and probably don’t have time to go through the go code base since I’m not familiar with the go language. However, it seems possible at first look for an attacker to sniff the authentication and grab the session key. I would feel much better if the traffic was encrypted via some opportunistic cryptographic function. At the moment, I’m utilizing an ssh reverse tunnel for traffic cover. It would be helpful if IPFS included the ability to create secure tunnels to private nodes on WAN addresses before the authentication credentials are exchanged.
- Perhaps I don’t know what I’m doing…
If this is the case, please correct my misunderstanding.