WireGuard deployment considerations for improved privacy

* WireGuard deployment considerations for improved privacy
@ 2019-01-14 10:23 Fredrik Strömberg
  2019-01-14 12:53 ` Matthias Urlichs
       [not found] ` <CAOAVeL0Hv343JWU1m06p-WaspsNFpB6Tnw6EdYr=LdMVQLM0AQ@mail.gmail.com>
  0 siblings, 2 replies; 6+ messages in thread
From: Fredrik Strömberg @ 2019-01-14 10:23 UTC (permalink / raw)
  To: WireGuard mailing list

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 6+ messages in thread