Artificial truth

The more you see, the less you believe.

[archives] [latest] | [homepage] | [atom/rss/twitter]

Wireguard and forward secrecy for clients
Sun 08 March 2020 — download

Wireguard got merged upstream: time to deploy it, throw OpenVPN in a fire, and to celebrate!

Unfortunately, there is a major design issue with Wireguard if you're using it with a VPN provider: the lack of forward secure identity hiding. This means that an attacker recording your traffic and gaining access to the server's private key would be able to retroactively tie users (via their public keys) back to their connections.

This property isn't really hidden away, but I haven't found significant discussions about it, and it took me a bit of reading of the spec to realize that.

Wireguard is using Noise_IK for its crypto protocol, meaning that to initiate a connection, the initiator (client) will send its public key to the responder (server), but as the documentation says:

Message contents benefit from message secrecy and some forward secrecy: the compromise of the responder's long-term private keys, even at a later date, will lead to message contents being decrypted by the attacker.

This is a deliberate design choice: it keeps the protocol simple, saves roundtrips, and it allows to simply drop unauthenticated packets.

After this article was published, some people asked about other tunneling protocols: Tor doesn't have this property, nor does I2P OpenVPN with modern ciphers, and IPSEC.

So keeps this in mind before blindly using a commercial VPN provider with Wireguard.

(Thanks to joe for spending some of his time discussing this with me, which resulted in this blogpost.)

Edits: