4.2 Bootstrapping Private Overlays 4.3 Full Tunneling over P2P sought a model with easy to user interfaces. In this sec- tion, we present our solution, a partially automated PKI reliant on a redistributable group based web interface. Although this does not preclude other methods of CA interaction, our experience has shown that it provides a model that is satisfactory for many use cases. In order to obtain certificates, a user creates an account and joins a group through a Web interface, providing rel- evant information as to the reason for joining the group. Users can also create VPN groups of their own through the interface, in effect becoming the administrator of the VPN group. One or more group VPN administrators can verify this information and approve or deny the user ac- cess into the group. If a user is granted access, they are then able to download a configuration blob. The blob contains VPN network configuration and a shared key that uniquely identifies the user and allowing them to au- tomatically retrieve signed certificates in the future. The user configures the VPN client with the blob. Upon start- ing, the VPN client queries the group server using the in- formation in the blob to authenticate the server and itself to the server. After which, the user provides the group server a certificate request containing the VPN client’s node ID, which the server signs and returns. At which point, the VPN client can connect to the VPN pool and communicate securely with others in the group. It is im- perative that any operations that involve the exchanging of secret information, such as the shared secret, be per- formed over a secure transport, such as HTTPS, which can be done with no user intervention. Unlike decentralized systems that use shared secrets, in which the creator of the VPN becomes powerless to control malicious users, a PKI enables the creator to ef- fectively remove malicious users. The methods that we have incorporated include: use of a certificate revoca- tion list (CRL) hosted on the group server, DHT events requesting notification of peer removal from the group, and broadcasting to the entire P2P system the revocation of the peer. A CRL offers an out of band mechanism for distribut- ing user revocations. The CRL assist in cases where a malicious user can use common P2P attacks to prevent notification of certificate revocations transmitted via the overlay, as it is significantly more difficult to prevent the retrieval of a CRL. The DHT method acts as an event notification. Upon a revocation, the CA retrieves the values at a DHT key spe- cific to the revoked peer. The values contain node IDs of nodes who want to know of the revocation. The problem with a DHT is that it can be easily compromised if they have not been implemented with significant measures to protect against maliciousness. The most rudimentary mechanism is broadcasting the certificate revocation over the entire P2P overlay. In small networks, the cost of such a broadcast may be neg- ligible, but as a network grows, such a broadcast may become prohibitively expensive. In P2P systems, distributed security may not provide the same level of security as centralized or managed se- curity. A starting point to secure an overlay is to use well-known security concepts such as PKI and SSL to encourage wider adoption of P2P systems. One problem with this approach though is that users who want a pri- vate overlay may not have the resources, i.e. public ad- dresses, to host their own overlays. To address this, we suggest bootstrapping a private overlay from an existing public overlay [7]. Communication within the private overlay is completely encrypted and authenticated with only members of the VPN allowed access. In this approach, members of the VPN are the only participants of the private overlay, providing a model that is synergistic with the group VPN interface described earlier. This prevents malicious users outside of the VPN from attacking it, and facilitates the removal of misbe- having peers, primarily rooted in the fact that the use of a broadcast to signal a certificate revocation is within the scope of the private overlay. The process for bootstrapping a private overlay is as follows. Once the VPN software begins, it starts by con- necting with the public overlay. It queries the public overlay’s DHT at the key “private:groupname”, where groupname is the GroupVPN’s name. The values stored at the key are the public overlay node IDs of the pri- vate overlays active members. The joining VPN software will attempt to form private overlay bootstrap connec- tions with members of this list using the public overlay. During this process, both peers verify each other’s au- thenticity and form a secure connection. This connection is then used to bootstrap direct connections with mem- bers of the private overlay. The reason why the public overlay node IDs are stored at the public overlay’s DHT key and for using private overlay bootstrap connections over the public overlay is to support NAT traversal. This model supports reusing Brunet’s underlying NAT traver- sal techniques. As a member of a private overlay, a VPN node can elect to store information relevant to the VPN in the private overlay’s DHT, relegating the public over- lay for private overlay discovery. VPN traffic can then be kept to the private overlay only or the public overlay can be used for relaying, when direct connectivity is not possible, though this has not been looked into yet. In full tunnel mode, all traffic to both VPN and Inter- net hosts with the exception of VPN “control” messages route over the VPN, as shown in Figure 2. In a central- ized VPN, these “control” messages consist of commu- 6