Just wanted to add my 5 cents

[idealist 0]

I am not a big wireguard fan, but I've just found this old AirVPN staff reply and want to address factual errors that are starting to spread through the internet
 

Quote

• Wireguard lacks dynamic IP address management. The client needs to be assigned in advance a pre-defined VPN IP address uniquely linked to its key on each VPN server. The impact on the anonymity layer is catastrophic;

Those are internal IP, no one would see them instead of a client himself. It wouldn't impact anonymity. [IT DOES IMPACT ANONYMITY SEVERELY, Staff, see below]
 

Quote

• Wireguard client does not verify the server identity (a feature so essential that it will be surely implemented when Wireguard will be no more an experimental sofware); the impact on security caused by this flaw is very high;

Client literally specify servers public key in the config. MITM with fake server identity is impossible.

[go558a83nk 364]

It doesn't matter if the assigned IP are internal.  Keep in mind that security must not only be for network attacks but against physical seizure as well.  If any records exist on a server that can be tied to users it is a serious anonymity breach.

[idealist 0]

What do you mean? The server knows your key and other credentials anyway

[Staff 10014]

12 hours ago, idealist said:

What do you mean? The server knows your key and other credentials anyway

Hello!

No it doesn't. Our VPN servers do not store clients keys (and have never kept them).

At the time the article was written, with Wireguard you needed to pre-map the VPN IP addresses for clients on each server. That's unacceptable. Of course a VPN is not meant to provide you with an anonymity layer so we add a series of essential features which could not be replicated with Wireguard when the post you refer to was written. We have been told that the mentioned problem will be resolved before a stable version is released.

Same thing with client/server authentication, if both pre-auth (what OpenVPN calls "TLS Auth" or "TLS Crypt") and client/server certificate verification in TCP have been implemented in the meantime, we welcome them, but they were anyway NOT available at the time the article you refer to was written.

Kind regards
 

[idealist 0]

go558a83nk imply that an attacker can get a physical access to a multiple running servers with open connections and track down all the open connections you have by internal IPs. An attacker would see your real IP of an OpenVPN connection, he can also terminate OpenVPN connection wait for reconnection and log the key wherever you store them. The server can't establish a connection without the credentials of a particular client, only if you don't share them among many clients which is not the case. Wireguard don't make it any worse for online server. On an offline server wireguard configs with their public keys and internal IP don't provide him any info about users because those are internal IPs not external IPs and he didn't see them outside before.

Quote

they were anyway NOT available at the time the article you refer to was written

The server public keys were there from the very beginning, they surely be in the config at the time when the comment was written. Proof from November 2017

Edited ... by idealist

[Staff 10014]

Quote

go558a83nk imply that an attacker can get a physical access to a multiple running servers with open connections and track down all the open connections you have by internal IPs. An attacker would see your real IP of an OpenVPN connection, he can also terminate OpenVPN connection wait for reconnection and log the key wherever you store them.

You can see the obvious difference. In our setup the attacker needs to wait for a connection to that server from a customer to try to wiretap the private key, while with Wireguard the attacker gets at once all the keys of all the users even when the server is offline.

Furthermore we would need to map on every and each server statically tens of thousand IP addresses and keys, which is unacceptable. The fact that the IP addresses are local to the VPN is irrelevant and obvious and does not change anything about the privacy problems we mentioned.

There could be a workaround to the problem, but we have been told that the problem will be resolved before Wireguard gets out of the beta phase, so it's useless to study the implementation of a workaround during the beta testing as the authors will implement a solution.
 

Quote

The server public keys were there from the very beginning, they surely be in the config at the time when the comment was written. Proof from November 2017

That's not what we needed / asked for. If now Wireguard supports TLS pre-auth (important for us for trivial reasons) and certificate verification on a TCP control channel that's excellent but it was not available when we wrote the article.

Kind regards

[idealist 0]

15 minutes ago, Staff said:

gets at once all the keys of all the users even when the server is offline

Those keys are just random numbers and can't be connected to real IP nor external IP of those clients.

Without the server private key an attacker wouldn't be able to commit a MITM attack. Server identity is verified. TLS is just the one way it is checked by openvpn in particular and only because openvpn is based on TLS, wireguard is based on the other authentication algorithms.

[Staff 10014]

1 hour ago, idealist said:

Those keys are just random numbers and can't be connected to real IP nor external IP of those clients.

Without the server private key an attacker wouldn't be able to commit a MITM attack. Server identity is verified. TLS is just the one way it is checked by openvpn in particular and only because openvpn is based on TLS, wireguard is based on the other authentication algorithms.

True, so what?  It is not the point we made: having all the keys of all users on each VPN is the core privacy and security issue, while having to map statically the addresses of tens or hunreds of thousand clients is the core operational issue in this case.

Having no TCP is a different problem for different reasons (because of systematic Net Neutrality violations). According to stats voluntarily provided by users, at least 50% of VPN users complain about UDP shaping and/or blocking by their ISPs in "Western" countries, and the percentage seems higher in other countries. OpenVPN not only supports TCP for the Data Channel, but also allows tls-crypt, which is important when the VPN software fingerprint detection is used to break the connection, which is routinely enforced by many ISPs especially in mobility.

By the way, as we repeatedly stated, the first problem we have addressed is being worked on according to what devs told us, while it's not ruled out that Wireguard will support TCP in the future (an external software is also available right now, but of course we prefer native TCP support) . Last but not least, we are confident that obfuscation too is being studied since when we tested the software (another mandatory feature for our customers for the aforementioned reasons), as well as connections to SOCKS or HTTP proxies (yet another essential feature for all of our customers who work behind some proxy) so let's see what comes out when a stable version is released.

Kind regards
 

[idealist 0]

31 minutes ago, Staff said:

core privacy and security issue

So what is the issue? The attacker may obtain a bunch of random keys he can't use without a private server key, if he steal an offline server. If he steal an online server or hack it, then the security is compromised much deeper and user connections and their real IP will be leaked the same way they do in case of openvpn server hack.

I agree with the lack of TCP and proxy support. I've only wanted to note errors in the first two catastrophic and MITM prone issues raised in that comment. I also think that introducing a proxy support to kernel module level will be too difficult or alien to original wireguard concept as a fast kernel level packet switching interface so I wouldn't expect it to be implemented in wireguard paradigm anyway. It is more like the IPsec low level protocol stack than the openvpn TLS tunnel. If this is the crucial features you are waiting from it then it is rather safe to say it won't provide them in any nearest future or the target users of wireguard wouldn't use them anyway.

[Staff 10014]

Quote

So what is the issue? The attacker may obtain a bunch of random keys he can't use without a private server key

The issue has been already explained: the keys and the internal IP addresses are all on the server, and they are on every and each server. They can be used to correlate specific targets and disclose their identities, while on our current setup that's not possible.  It makes a world of difference when you consider threat models in which VPN users are specifically targeted. Maybe you don't understand the importance of this menace because you wrote:
 

Quote

Those are internal IP, no one would see them instead of a client himself. It wouldn't impact anonymity.

which is correct in our setup, but incorrect in Wireguard setup. The attacker CAN get the internal IP address via WebRTC for example and:
1) in our setup he/she does not correlate the internal IP address with the client key
2) in Wireguard setup he/she does

Once that's done the attacker may obtain legally (via a court order) the payment data of the user because it can ask us which user is linked to a single IP address (and also the user key for subsequent forensic evidence). Since the VPN IP address is static and unique, we would be of course forced to comply.

We wish to underline for the last time that the problem has been acknowledged by developers and we had been told that it would be resolved.

Kind regards
 

[idealist 0]

3 hours ago, Staff said:

They can be used to correlate specific targets and disclose their identities

No they don't, an offline server has no logs. On online server with open connections openvpn is just as vulnerable.
 

3 hours ago, Staff said:

The attacker CAN get the internal IP address via WebRTC ... and correlate the internal IP address with the client key

So? This correlation is meaningless for offline server inspection. The key is just a random number which they can't use without a server private key. On online server an attacker can do so with openvpn dynamic internal IP as well. Actually we can go further and say that for real serup those configs would be download to the server during its boot procedure anyway and there is no need to actually save them on disk at all, just like you do with server private key or openvpn certificate.
 

3 hours ago, Staff said:

it can ask us which user is linked to a single IP address

And do what? It's an internal IP address which can't be used to analyze outbound traffic.

I still don't see any viable vector of attack in case of an offline server seizure.

Dynamic IPs may be added to wireguard for convenience and ease of use, it is not a critical catastrophic issue that put anonymity at risk.
 

[Staff 10014]

@idealist

You don't understand. With static IP addresses stored on the servers you map uniquely and permanently an IP address to a user. Once that IP address is discovered (no need to crack the server, as we wrote) the correlation is done because we know which user always has that IP address, even if we don't log traffic, and we would give away the information under a court order. Which is exactly what go558a83nk already explained to you.

This is not possible with OpenVPN, as the dynamic IP addresses are never correlated to a user once the session is over, they are lost. So if the attacker asks "who has that IP address?" with OpenVPN in our setup we don't know, while with Wireguard in the current (at the time of writing) stage of development we would know.

If now or in the future Wireguard will allow dynamic addresses assignments, so that no address must be stored permanently for any client, the problem is resolved, but at the time we wrote the article it was not.

Kind regards