WireGuard? #633

New Issue

jonah · 2018-11-26T22:02:07Z

ghost commented

2018-11-26 22:02:07 +00:00

(Migrated from github.com)

Can anyone comment on the security of WireGuard? Should be a faster VPN protocol than OpenVPN.

19h commented

2018-11-26 22:08:27 +00:00

(Migrated from github.com)

Related whitepaper: https://www.wireguard.com/papers/wireguard.pdf

uses NoiseIK handshake
transport is authenticate-encrypted using ChaCha20Poly1305
Curve25519 is used for authenticating VPN parties
protocol doesn't communicate when not used, unless specifically configured to be noisy

Related whitepaper: https://www.wireguard.com/papers/wireguard.pdf - uses NoiseIK handshake - transport is authenticate-encrypted using ChaCha20Poly1305 - Curve25519 is used for authenticating VPN parties - protocol doesn't communicate when not used, unless specifically configured to be noisy

gjhklfdsa commented

2018-11-27 00:21:59 +00:00

(Migrated from github.com)

From a personal experience with Mullvad. It was significantly faster for me, may of been because less people use the WireGuard server over the OpenVPN server though. :)

👍 1

ghost commented

2018-11-27 11:29:47 +00:00

(Migrated from github.com)

Relevant links:

https://airvpn.org/topic/28984-wireguard/?p=76527 & https://www.wireguard.com/#work-in-progress Seems like it hasn't been properly audited yet?

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities (which would not be eligible for CVEs, since this is pre-release snapshot software). If you are packaging WireGuard, you must keep up to date with the snapshots.

Linus on WireGuard: http://lkml.iu.edu/hypermail/linux/kernel/1808.0/02472.html

Btw, on an unrelated issue: I see that Jason actually made the pull
request to have wireguard included in the kernel.

Can I just once again state my love for it and hope it gets merged
soon? Maybe the code isn't perfect, but I've skimmed it, and compared
to the horrors that are OpenVPN and IPSec, it's a work of art.

Relevant links: https://airvpn.org/topic/28984-wireguard/?p=76527 & https://www.wireguard.com/#work-in-progress Seems like it hasn't been properly audited yet? > WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities (which would not be eligible for CVEs, since this is pre-release snapshot software). If you are packaging WireGuard, you must keep up to date with the snapshots. Linus on WireGuard: http://lkml.iu.edu/hypermail/linux/kernel/1808.0/02472.html > Btw, on an unrelated issue: I see that Jason actually made the pull request to have wireguard included in the kernel. > > Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.

ghost commented

2018-11-27 11:45:56 +00:00

(Migrated from github.com)

@KenanSulayman

protocol doesn't communicate when not used, unless specifically configured to be noisy

If we recommend WireGuard on the site, we should "warn" users about this. While this is great performance-wise, we should explain why noise is good for privacy.

Maybe I could even write something about noise on theprivacyguide.org and we could link to it. I think there are programs that one can run to artificially create noise when not communicating.

Privacy-wise, your traffic should ideally look the same when communicating and when not communicating.

https://vuvuzela.io/

@KenanSulayman > protocol doesn't communicate when not used, unless specifically configured to be noisy If we recommend WireGuard on the site, we should "warn" users about this. While this is great performance-wise, we should explain why noise is good for privacy. Maybe I could even write something about noise on theprivacyguide.org and we could link to it. I think there are programs that one can run to artificially create noise when not communicating. Privacy-wise, your traffic should ideally look the same when communicating and when not communicating. https://vuvuzela.io/ ![](https://vuvuzela.io/static/server.gif)

hugoncosta commented

2018-12-19 18:03:06 +00:00

(Migrated from github.com)

@Shifterovich I'd argue Wireguard is more closely related to normal traffic than other VPN implementations, since it only "works" when the requests are made, just like in a normal setting. OpenVPN, etc, our devices are in constant connection with them (if I'm not mistaken), and that would be considered unusual (obviously nowadays not so much, as most pages have autoupdating features, chats and what not).

ghost commented

2018-12-19 18:35:27 +00:00

(Migrated from github.com)

Good point. Though the traffic would have to be indistinguishable from normal traffic, which it isn't (unless I'm wrong), due to communicating with one IP only, rather than tons of IPs -- like regular traffic.

strypey commented

2019-04-17 05:02:44 +00:00

(Migrated from github.com)

@Shifterovich

Seems like it hasn't been properly audited yet?

Have OpenVPN and IPSec been properly audited?

Linus (Torvalds I presume):

Maybe the code isn't perfect, but I've skimmed it, and compared
to the horrors that are OpenVPN and IPSec, it's a work of art.

This is not a formal security audit, but it's a big improvement on not audited at all. In summary, there will definitely come a time when information about using Wireguard needs to be added to the site. Probably worth starting a discussion on what that could look like and where on the site it fits.

@Shifterovich > Seems like it hasn't been properly audited yet? Have OpenVPN and IPSec been properly audited? Linus (Torvalds I presume): > Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art. This is not a formal security audit, but it's a big improvement on not audited at all. In summary, there will definitely come a time when information about using Wireguard needs to be added to the site. Probably worth starting a discussion on what that could look like and where on the site it fits.

19h commented

2019-04-17 05:03:49 +00:00

(Migrated from github.com)

https://courses.csail.mit.edu/6.857/2018/project/He-Xu-Xu-WireGuard.pdf

jonah commented

2019-04-17 13:59:44 +00:00

there will definitely come a time when information about using Wireguard needs to be added to the site

IMO, it doesn't make sense to include it until they finally release a stable release, and not just a beta/alpha/whatever they call it.

> there will definitely come a time when information about using Wireguard needs to be added to the site IMO, it doesn't make sense to include it until they finally release a stable release, and not just a beta/alpha/whatever they call it.

19h commented

2019-04-17 14:25:56 +00:00

(Migrated from github.com)

I’m sure everyone who remotely values their OpSec will already be using WireGuard.

strypey commented

2019-04-20 13:46:11 +00:00

(Migrated from github.com)

@KenanSulayman

I’m sure everyone who remotely values their OpSec will already be using WireGuard.

The WireGuard website currently says:

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come.

I agree with @JonahAragon, it doesn't make sense to recommend using WireGuard until the developers start recommending production use of their own software.

@KenanSulayman > I’m sure everyone who remotely values their OpSec will already be using WireGuard. The [WireGuard website](https://www.wireguard.com/#work-in-progress) currently says: > WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. I agree with @JonahAragon, it doesn't make sense to recommend using WireGuard until the developers start recommending production use of their own software.

👍 1

19h commented

2019-04-20 13:53:58 +00:00

(Migrated from github.com)

There's a formal verification of the Noise protocol, which is the primary component of this program. If you're looking for a full audit of OpenVPN, you're up for a surprise. You should not rely on this code. is a disclaimer -- and it shouldn't be just a disclaimer, it should be your basic assumption with everything related to your OpSec.

There's a formal verification of the Noise protocol, which is the primary component of this program. If you're looking for a full audit of OpenVPN, you're up for a surprise. _You should not rely on this code._ is a disclaimer -- and it shouldn't be just a disclaimer, it should be your basic assumption with everything related to your OpSec.

19h commented

2019-05-13 09:54:58 +00:00

(Migrated from github.com)

jfyi https://hal.inria.fr/hal-02100345/document

jonah commented

2019-05-13 20:24:15 +00:00

"You should not rely on this code" is a given yes, the "WireGuard is not yet complete" and "It has not undergone proper degrees of security auditing" are the bigger concerns in the quote there.

Not that OpenVPN is too much better as you mentioned, but it's in far, far wider use than WireGuard currently is.

"You should not rely on this code" is a given yes, the "WireGuard is not yet complete" and "It has not undergone proper degrees of security auditing" are the bigger concerns in the quote there. Not that OpenVPN is too much better as you mentioned, but it's in far, *far* wider use than WireGuard currently is.

👍 1

ghbjklhv commented

2019-05-27 22:29:47 +00:00

(Migrated from github.com)

@JonahAragon Beta has never really been a reason to remove software on privacytools.io

Just look at Brave or Riot or even TorBirdy. These are all considered beta but also heavily recommended in the privacy community.

@JonahAragon Beta has never really been a reason to remove software on privacytools.io Just look at Brave or Riot or even TorBirdy. These are all considered beta but also heavily recommended in the privacy community.

blacklight447 commented

2019-05-28 10:01:04 +00:00

(Migrated from github.com)

Yeah, people often forget that beta does not mean insecure, just that is has not yet reached its target goal. it can be perfectly secure when its beta software, however, as Jonah pointed out, the developers themselves state that you should not rely on it yet, so i am unsure if we want to recommend it. A worth mentioning might be okay though, with a warning.

EDIT: words

Yeah, people often forget that beta does not mean insecure, just that is has not yet reached its target goal. it can be perfectly secure when its beta software, however, as Jonah pointed out, the developers themselves state that you should not rely on it yet, so i am unsure if we want to recommend it. A worth mentioning might be okay though, with a warning. EDIT: words

Welteam commented

2019-08-19 12:11:05 +00:00

(Migrated from github.com)

I believe this decision to be highly uninformed so I take the initiative to reopen the discussion. Feel free to try and change my mind.

OpenVPN isn't safe: Wrong

The warning on WireGuard's website has been mentioned again and again however it seems you were convinced by the arguments of @19h which are groundless. Yes OpenVPN isn't a good standard. It is old and the code is uselessly long and complex leading to new vulnerabilities found despite the multiple audits. However the chance that a vulnerability will be found in the near future AND is used against lambda users is lower than most vulnerabilities. Moreover, we are a privacy website, not an infosec one. Most of the readers use their computer in VERY insecure ways making a vuln in OpenVPN 1000 times overkill. It completely hides your traffic and doesn't have obvious security flaws. That's all we ask.

WireGuard being in the prototype phase isn't a reason to not recommend: Wrong

While it's true that we can and already have recommended software in active development, WireGuard is a special case. The problem doesn't stand with the protocol itself but with it's implementation. WireGuard currently (last time I checked at least) doesn't have any way to be implemented in a secure and privacy friendly way. Currently it can barely be scraped together to make it works in order to conduct tests. The biggest problem is that it needs to store and make readily available all IP adresses of the VPN's customers voiding all promises of not logging IPs:

One of the challenges WireGuard faces is to ensure anonymity for VPNs. No single user should be statically allocated a single IP address, neither on a public nor a virtual network. A user’s internal IP address might be discovered by an adversary (through WebRTC, for example), who might then be able to match it with records acquired from a VPN provider (through theft, sale, or legal seizure). A good VPN must be unable to match such an identifier to a single user. Currently, this setup is not easily achieved with WireGuard.

ExpressVPN

You can find similar statements from many other VPN providers. You shouldn't use WireGuard and I personally refuse to endorse any VPN actively advertising it.

Edit: In case someone would want to open the box of the baseless ad hominem attacks, I would like to add that I don't work for, nor use, Express VPN or any other VPN. I only use Tor and don't really care what you do with your traffic. I just try to prevent ptio from losing face because of what I believe is a dangerously uninformed decision.

I believe this decision to be highly uninformed so I take the initiative to reopen the discussion. Feel free to try and change my mind. <details><summary>OpenVPN isn't safe: Wrong</summary> The warning on WireGuard's website has been mentioned again and again however it seems you were convinced by the arguments of @19h which are groundless. Yes OpenVPN isn't a good standard. It is old and the code is uselessly long and complex leading to new vulnerabilities found despite the multiple audits. However the chance that a vulnerability will be found in the near future AND is used against lambda users is lower than most vulnerabilities. Moreover, we are a privacy website, not an infosec one. Most of the readers use their computer in VERY insecure ways making a vuln in OpenVPN 1000 times overkill. It completely hides your traffic and doesn't have obvious security flaws. That's all we ask. </details> <details><summary>WireGuard being in the prototype phase isn't a reason to not recommend: Wrong</summary> While it's true that we can and already have recommended software in active development, WireGuard is a special case. The problem doesn't stand with the protocol itself but with it's implementation. WireGuard currently (last time I checked at least) doesn't have any way to be implemented in a secure and privacy friendly way. Currently it can barely be scraped together to make it works in order to conduct tests. The biggest problem is that it needs to store and make readily available all IP adresses of the VPN's customers voiding all promises of not logging IPs: > One of the challenges WireGuard faces is to ensure anonymity for VPNs. No single user should be statically allocated a single IP address, neither on a public nor a virtual network. A user’s internal IP address might be discovered by an adversary (through WebRTC, for example), who might then be able to match it with records acquired from a VPN provider (through theft, sale, or legal seizure). A good VPN must be unable to match such an identifier to a single user. Currently, this setup is not easily achieved with WireGuard. [ExpressVPN](https://www.expressvpn.com/blog/expressvpn-wireguard-update/) You can find similar statements from many other VPN providers. You shouldn't use WireGuard and I personally refuse to endorse any VPN actively advertising it. </details> Edit: In case someone would want to open the box of the baseless ad hominem attacks, I would like to add that I don't work for, nor use, Express VPN or any other VPN. I only use Tor and don't really care what you do with your traffic. I just try to prevent ptio from losing face because of what I believe is a dangerously uninformed decision.

19h commented

2019-08-19 12:56:37 +00:00

(Migrated from github.com)

Are you by any chance affiliated with ExpressVPN?

19h commented

2019-08-19 13:18:03 +00:00

(Migrated from github.com)

it needs to store and make readily available all IP adresses of the VPN's customers

This is incorrect. Any connection, be it via UDP datagrams or a bidirectional TCP connection, requires a valid IP address, and a physical address, to function at all. Therefore, the client IP will be known to any software.

Unless configured to be using a strict allowed-ips configuration, WireGuard does not require the knowledge of a singular and static IP address to identify a user. Their public key is the only required identifier used by the underlying implementations to establish a handshake and the both semi-permanent (per connection) and ephemeral (regularly swapped, for PFS, as part of the NOISE protocol).

You're arguing with a network systems engineer. Unless your arguments become technical to a level that you can point me to the implementation specifics, this conversation cannot serve any purpose anymore.

> _it needs to store and make readily available all IP adresses of the VPN's customers_ This is incorrect. Any connection, be it via UDP datagrams or a bidirectional TCP connection, requires a valid IP address, and a physical address, to function at all. Therefore, the client IP will be known to any software. [Unless configured to be using a strict allowed-ips configuration, WireGuard does not require the knowledge of a singular and static IP address to identify a user.](https://github.com/WireGuard/WireGuard/blob/aeed4d81b6aa22c246918d8e1967e194114aaffd/contrib/examples/embeddable-wg-library/wireguard.c#L1141-L1167) Their public key is the only required identifier used by the underlying implementations to establish a handshake and the both semi-permanent (per connection) and ephemeral (regularly swapped, for PFS, as part of the NOISE protocol). You're arguing with a network systems engineer. Unless your arguments become technical to a level that you can point me to the implementation specifics, this conversation cannot serve any purpose anymore.

Welteam commented

2019-08-19 14:10:18 +00:00

(Migrated from github.com)

I double checked the things I read and now I'm confused. What I believed to be a single issue apparently is two separate ones. Some VPN like ExpressVPN, AirVPN or VPN.ac claimed that WireGuard can't be used without static IPs.
On the other hand, AzireVPN seems to say it is possible however the problem is that the sys admin does have acces to IPs and thus they asked the creator to fix this problem with a rootkit. I haven't looked at the code and don't plan to as it doesn't concern me but if you can enlighten us on these points I think it would benefit everyone.

I double checked the things I read and now I'm confused. What I believed to be a single issue apparently is two separate ones. Some VPN like ExpressVPN, AirVPN or VPN.ac claimed that WireGuard can't be used without static IPs. On the other hand, [AzireVPN seems to say it is possible however the problem is that the sys admin does have acces to IPs and thus they asked the creator to fix this problem with a rootkit.](https://www.azirevpn.com/blog/2017-11-15/wireguard-privacy-enhancements) I haven't looked at the code and don't plan to as it doesn't concern me but if you can enlighten us on these points I think it would benefit everyone.

19h commented

2019-08-19 14:28:34 +00:00

(Migrated from github.com)

From the linked article:

and we came to the conclusion that AzireVPN was going to hire Jason to write a rootkit-like module that removes the ability of an ordinary system administrator to query endpoint or allowed-ip information about WireGuard peers and disable the ability to run tcpdump

That is pretty respectable, I'm amazed.

I agree with the AzireVPN point. The standard configuration makes the connection between IP and user visible via the Wireguard CLI. This is akin to logging connection attempts in the OpenVPN syslog. That's definitely a weakness. That said, you can probably automate the rollout of VPN servers and lock system administrators out, mitigating this issue.

The other claims, however, requiring static IPs, are incorrect and misleading. Even assuming they consider a static IP required to enforce one-public-key-per-user (preventing abuse), reusing a public key would interfere with the connection of another user using that key.

From the linked article: > and we came to the conclusion that AzireVPN was going to hire Jason to write a rootkit-like module that removes the ability of an ordinary system administrator to query endpoint or allowed-ip information about WireGuard peers and disable the ability to run tcpdump That is pretty respectable, I'm amazed. I agree with the AzireVPN point. The standard configuration makes the connection between IP and user visible via the Wireguard CLI. This is akin to logging connection attempts in the OpenVPN syslog. That's definitely a weakness. That said, you can probably automate the rollout of VPN servers and lock system administrators out, mitigating this issue. The other claims, however, requiring static IPs, are incorrect and misleading. Even assuming they consider a static IP required to enforce one-public-key-per-user (preventing abuse), reusing a public key would interfere with the connection of another user using that key.

jonah commented

2020-02-16 16:55:48 +00:00

https://www.privacytools.io/providers/vpn/#criteria

This repo is archived. You cannot comment on issues.