Greetings fellow WireGuard users, I represent Mullvad, a privacy-focused VPN provider. We and some others think there are currently two aspects of WireGuard that make its deployment in a privacy-focused setting a bit challenging. The goal of this email is to present current thoughts on the issues and facilitate discussion. It contains language and ideas from others who have commented on this elsewhere. Thank you. Feel free to make yourselves known. Any errors are mine however.
The two issues are: * WireGuard does not offer identity hiding forward secrecy * WireGuard does not offer dynamic IP address assignment Together with other interested parties I hope to arrive at a good solution to these issues, which can be adopted by any apps that want to offer privacy. The time to do this is now, before WireGuard reaches massive adoption and multiple incompatible hacks are made. You might care about this if you: * Run a VPN proxy/server where you or your users care about privacy * Use a commercial VPN service * Provide a commercial VPN service -WireGuard does not offer identity hiding forward secrecy- --The problem-- In the context of a VPN service the peers can be viewed as Client(s) and Server. A key compromise of the VPN server's static private key makes an attacker able to decrypt recorded handshakes and thus correlate all connections made using any given client static key, i.e. VPN user. Here's how: 1. An attacker records encrypted traffic flows to/from a VPN server. 2. Time passes. The attacker gets hold of the VPN server's static private key, by raiding a data centre, breaking into a VPN server host, or something else. 3. The attacker uses the VPN server static private key to decrypt the recorded handshakes, revealing client static pubkeys. 4. The attacker uses client static pubkeys to correlate traffic flows with particular users including possibly linking individuals to client pubkeys through other data sources, e.g. VPN provider business records or other IP address metadata. --Nuances-- A successful attack requires both the capability to record traffic flows as well as to compromise the server key. Still, the lack of identity hiding forward secrecy means WireGuard offers worse privacy than e.g. OpenVPN in this respect. It should be noted that both WireGuard and OpenVPN send tunnel session IDs in the clear. A user that roams between networks will probably leak the session ID between them. On the other hand, a user that explicitly disconnects on network 1 and reconnects the VPN tunnel on network 2 will have a new tunnel session ID that is not linkable to the first one. In this case OpenVPN (assuming user/pass auth and not client-cert) will have identity hiding forward secrecy, and WireGuard does not. If a WireGuard user application connects with a new pubkey every time a new tunnel is established, it will provide the same identity hiding properties as OpenVPN. However depending on the position of the surveillance equipment and the method of key compromise neither OpenVPN nor WireGuard would be sufficient protection. That's out-of-scope for this discussion however. --Proposed mitigation-- In order to get identity hiding forward secrecy the suggestion is to have the client change its static pubkey often in order to de-link VPN sessions, in the event of a compromise of the server's static private key. “Often” might be a time limit, a bandwidth limit, and events like reboot of the system, the app, new WiFi, new DHCP lease, or explicitly by the user. To provide the same properties as OpenVPN it should be enough to change pubkey every time the user does a connect/disconnect. This should probably be a functionality on top of WireGuard, which should stay minimal. It should be possible for clients to register new static pubkeys with the VPN service and to ask it to forget about old pubkeys. One current idea is to define a service on top of WireGuard running as a daemon on both client and server, communicating over a WireGuard session. -WireGuard does not offer dynamic IP address assignment- --The problem-- The tunnel-internal IP address can leak through WebRTC and perhaps other ways. A long term IP address assignment could enable a website that exfiltrates the IP address to use it as a unique identifier between website visits, even if the user has cleared all browsing data. There are other ways of doing this. A perhaps more serious consequence of static assignment is that the IP address is stored linked to a user's static public key, which in turn might be linked to a user’s personal identity through the server’s authentication system. If the attacker learns the IP address as well as gains access to the user database, it might be able to link the IP address to a person. In a commercial VPN service setup, the IP address and thus its static public key are probably linked to a customer account, and to payment information. If this is the case, an attacker might be able to identify the user. There are various mitigations and hacks one could do as an operator to prevent this. Regardless, an approach to ephemeral IP addresses that is accepted as standard would be preferable. --Proposed mitigation-- Make it possible for clients to request a dynamically assigned IP address from the VPN server. One idea is to define a service on top of WireGuard running as a daemon on both client and server, communicating over a WireGuard session. The client would need a statically assigned link-local IPv6 address and use that to communicate with the server-side daemon, which then assigns an IP address dynamically. -What's been done already?- An effort has already started regarding the dynamic IP addresses. Read the following for more info: https://www.wireguard.com/todo/ https://docs.google.com/document/d/11RJDDrdIsnGivz8xP5NsOteHdviuV4jfNG1CSl0q8cY/edit https://git.zx2c4.com/wg-dynamic One issue with an in-tunnel daemon is authentication of client and server. It’s possible the client side of the WireGuard tunnel is actually a router for many more clients, who probably shouldn’t be authorized to renegotiate the router’s dynamic IP address or pubkey. An alternative to an in-tunnel daemon would be to use peer-addressed datagrams for control messages instead, but that introduces other complexities as mentioned in the documents above. -Summary- A privacy-focused deployment of WireGuard should provide identity hiding forward secrecy and short-term dynamic IP address assignment. WireGuard provides neither, since it's out-of-scope for the project's goals, for good reasons. One solution would be to define a service that communicates over a WireGuard tunnel. The same service could provide API calls for both needs, as well as other things. Finally, it would be good if the mechanism and protocol remained the same regardless of if one was connecting to a lone WireGuard server, or to a WireGuard server in a network of many, such as a large VPN service provider. I for one expect WireGuard to become the standard VPN protocol for VPN services within a few years, and that they will continue to grow until then. To my knowledge the largest ones today run almost 10,000 servers. Thank you for your time. Best regards, Fredrik Stromberg _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
