fake colocation with MITM

[dominictarr]

The score function has a heavy penalty for colocation, the reasoning being that it's then cheaper to run a sybil attack. But I think you can fake colocation causing the scores of other peers to be reduced, leading to disconnections. So sybils could use this to cause honest peers to distrust each other, and then break up a good mesh.

libp2p connections are secured with a secure channel protocol. (noise, tls, that custom one) one of the main purposes of such a protocol is to prevent a man in the middle attack.
But this does not mean a MITM can't happen, just that they can't interfere with or decrypt any of the data sent. The MITM is reduced to providing a proxy, which isn't useful. Usually.

In this attack, a malicious peer (Mallory) waits to receive a connection from Alice and then they proxy that through to another peer, Bob. Now Alice and Bob are securely connected, but they both think that the other one has Mallory's ip address. If this process is repeated, it will appear that a number of peers are colocated at Mallory's ip address.

Or, even worse, once A and B are connected though M, M just initiates more connections back to A and B with new identities. A and B then both heavily penalize each other for colocation, since the weight factor is at least (N-1)^2

M does not need to spend much bandwidth, because the colocation penalty still applies to gossip connections (metadata only peers) it doesn't have to be on the mesh.

There are maybe some details to the connection protocol that could make this attack a little harder to pull off, like if a secure channel fails unless the server has the expected pubkey, that would make it harder because M would have to convince A to try to connect to B at M.ip.

I'm not optimistic about a simple remediation.

Maybe it could have a more complicated weighting system, so that metadata-only peers on the same ip weren't penalized? But that would only make it a little bit harder.

Or the peers could communicate what ip (through the secure channel) what ip they think they are using. This would be not be entirely reliable, especially for node's running in people's homes.

The other option of course, is to ditch the colocation rule. being able to lower another peer's score because of something they didn't do is worse than being able to run many peers on one machine.

oh, maybe the simplest way: score the ip addresses not the peers? then A&B will distrust M.ip, not A/B? hmm, that might actually work!

[vyzo]

I think having the peers exchange their IP addresses and drop the connection if they detect a MITM would be a reasonable solution for this.

[dominictarr]

@vyzo also pointed out to me in slack that peer exchanges require signed claims that a peer id will be coming from an ip address. that means I M can't just claim that B is at M.ip, and trick A into connecting.

I understand that libp2p is migrating to signed records only

[vyzo]

Yeah, the attack is predicated on convincing Alice to connect to Bob through Mallory.
This can happen if Mallory poisons the peer discovery service or bootstrap with fake addresses records.
However, we do have a general libp2p mitigation in the works, which is to use and trust signed peer records only.
This would defeat the attack as Mallory wouldn't be able to poison the peer discovery service.

[dominictarr]

currently open PRs to fix that:
libp2p/go-libp2p-kad-dht#516
libp2p/go-libp2p#747