# Introduction
In early June, our team completed a thorough and comprehensive review of the Gossipsub v1.1 protocol design and implementation for Protocol Labs. This security audit was particularly interesting as v1.1 brings with it a series of notable and important updates that weren’t present in v1.0, including efforts to harden and increase the security of the protocol. The v1.1 protocol also introduces a few novel pieces of functionality such as a new peer scoring function, peer exchanges and node list maintenance, in addition to general protocol improvements from v1.0.
Our team was pleased to see that the Gossipsub development team’s stated focus for v1.1 is security, and that significant steps were taken to support that effort, including running tests to simulate potential attack vectors on the network with different connection scenarios resulting in the Gossipsub v1.1 Evaluation Report. This proved very useful, demonstrating a strong security focus, and allowing our team to better understand how the Gossipsub team was testing the network and what had been previously attempted. With that foundation, we developed our own test harness for additional simulations. Given time constraints on the audit and the importance of messaging in peer-to-peer systems, we recommend that additional attack simulations be conducted, including having a more realistic model of latency in simulation, analyzing messages propagation and asymmetries in peer scores during simulation, and simulating an attacker attempting to circumvent the flood-publish mitigation against message censorship and delaying.
# Peer Scoring
In terms of effect, the peer scoring mechanism introduced in v1.1 is the largest change to the protocol and our team immediately identified this area as high risk. The scoring system is a positive and negative tally system that each node privately tracks and while these scores aren’t broadcast to the network, we identified ways in which the nodes can leak scoring information. We spent a considerable amount of our time trying to game and manipulate this part of the protocol, with some interesting end results.
We discovered that under certain circumstances, the peer scoring mechanism introduced a directionality component to the network (e.g. node A could have a very good score for node B, but node B wouldn’t necessarily have a reciprocated and proportionally positive view of node A). During our simulations, this component led to centralization pressures among nodes in the mesh, where many nodes would have very positive scores of a number of nodes, but those nodes would have a nearly neutral score in return – thus causing the number of nodes in the network to be heavily favored in scoring and traffic, creating gravity wells in the mesh as a result. This area of the protocol is under active research.
Furthermore, each node in the network has incentives to behave and there are penalties for acting negatively or breaking the rules. We discovered that it was possible to game a node’s view of an attacking node so that the attacker could manipulate their way into the victim node’s contact list. As a result, this meant that attackers could coordinate a long-term attack, never break the protocol rules, and gain a majority of a node’s contact table, thus creating an eclipse attack vector in the network. Our team’s recommended mitigation includes having nodes accept incoming graft requests only if their contact list is not full or if they’re the ones initiating a graft. This vulnerability was an area of particular interest, given that it was present only when a few variables were aligned in such a way that this was possible.
# Peer Discovery
Peer discovery works in tandem with the scoring system in order to allow new node connections to be made directly from the network without requiring a trusted source. In theory, this facilitates a more homogeneous and uniform distribution of nodes in the network. In practice, we found that care must be taken with the application score and the peer discovery settings. There are several different methods of peer discovery available to use in Gossipsub, including a DHT (the least secure but the least centralized) and the mDNS seed (more secure but much more centralized). Each of these is separately configured and can be enabled or disabled depending on the use case. We found that if incorrectly configured, the peer discovery system could become another gateway to identity attacks.
In addition, peer discovery adds a recovery mechanism against flash attacks. The network can seed itself back to operation from a successful flash attack and can do so with reasonable security guarantees based on the scoring system and peer exchange rules. This means that the network is quite resilient even to large-scale attacks. We recommended that extra care be taken around the application settings and all the peer exchange parameters, but we found this part of the protocol to be robust overall.
Read Protocol Labs’ blog post announcing the audit.
Our final audit report was completed on June 3, 2020.