I don't know a lot of serious systems security people who actually believe that. OpenBSD is fine, and smart people work on it, but it's been a long time since the early 2000's.
AFAIK it remains the single most selective platform out there. If a project is included in an OpenBSD release you know it has undergone serious whitebox scrutiny for security issues. I'm not aware of any platform that is quite so pedantic at the source code level.
Security people are always like that (I love that about them). They freak out if a hash function will now take 50 million years to find a collision on a supercomputer, rather than 345 billion. It's worked flawlessly for me and many others the past year in our production environment.
The fact that Ubuntu is including it, means that it's probably passed a critical mass of early adopters and then is probably seeping into the startup mainstream (as opposed to enterprise that wants 20 valid bells and whistles like authentication, auditing, etc).
> should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software)
In ~2 months time Wireguard is reaching 1.0 along with Linux 5.6, I figure it's quite stable already and they say that (as anyone with a sane mind would) to keep their asses safe.
I also use it, and it works, but this tells us nothing about its actual security.
Security people are also subject to fads and fashion just like web developers or indeed any other technical group. Many will endorse the primitives developed for example by Dan Bernstein without understanding anything about how they actually work, or having read and understood papers describing their security. Just because he has some hacker "street cred" (arguably well deserved) as the developer of qmail, etc.
The primitives codesigned/codiscovered by Dan Bernstein have become popular not because of hacker street cred but rather because they are peer reviewed and have good design rationale
This is an extraordinarily weird way to summarize WireGuard's cryptography, which shares primitives with Signal (it's derived from Trevor Perrin's Noise framework) and, while we're at it, TLS 1.3. Bernstein's credibility in cryptography comes from his standing as an academic cryptographer, not as "the developer of qmail".
I'm not remotely a cryptographer. And I'm not saying there is anything wrong with his algos obviously.
But I remember when the algos designed by Bruce Schneier were all the rage, and I think it was similarly based on some sort of guru status.
If I look at Bernstein's most cited papers, they are all about performance, aside from what appears to be a survey on post-quantum crypto and what does seem to be like a well-cited paper on AES cache timing attacks.
So my genuine question is: does he really have an unusual academic standing as a cryptographer?
Granted, it's just a ranking by citation, and this definitely puts him in the top 100, which is nothing to scoff at, but I'm still wondering if there is a similar effect, and if in ten years we won't be using algos all written by some other guy because he's the new cool kid.
Not OP. I do not have issues with WireGuard's cryptography.
I do have issues with wireguard's security - things like silently accepting invalid configuration, changing one peer can silently affect another (only avoided via external means), roaming is default enabled and can't be disabled nor can you bind the tunnel to an interface or an ip, nor does it pad packets even the slightest to reduce "meta"data leakage.
Just because the cryptography is (probably) sane, doesn't mean wireguard as a whole is good for all or most use-cases.
I can only make informed decisions based on the information I have. I don't have the time or expertise to personally audit every piece of code I use. I have to leverage the available resources and evidence that others have put forward.
> Please note that until Linux 5.6 is released, this snapshot is a
snapshot rather than a secure final release.
In other words, over the next ~10 weeks, Linus' kernel tree and Dave Miller's net.git tree will fill up with nice stabilization patches. At the end of that process, 5.6 will be released. At that time, our backports to older kernels (wireguard-linux-compat) will also become a "1.0". This also lines up with the 20.04 LTS release and such.
Great. This will mean wonders for the short-term adoption of Wireguard, as it's now in a "stable" Linux distro. After Ubuntu 20.04 there's a big gap in new "stable/enterprise" releases.
Debian 11 - Mid 2021, probably
OpenSUSE Leap/SLES 16 - Mid 2021, probably
Ubuntu 22.04 LTS - April 2022
Red Hat 9 - probably 2024 ?
So if Ubuntu hadn't included this, we would have to wait more than a year to have it in the kernel of a "server-grade" Linux system by default. Most people don't like running more cutting edge distros or fiddling with the kernel on their servers. Defaults matter, so this will be great for Wireguard adoption.
I can understand why RHEL would still ship ancient PHP versions to keep legacy apps running, but I think WireGuard would be an easier sell considering it's so unobtrusive and has no legacy software to worry about breaking.
Mostly to keep my personal sanity. Joking aside, IMO having to depend DKMS to correctly build the kernel module on kernel update every time for something that is network related isn't something I would consider rock solid for production. It is great when it works. Not so great when it doesn't.
Packaging WireGuard for Fedora, CentOS, and RHEL has been super fulfilling over the years, but DKMS is super fickle and buggy. wireguard-dkms is a package I would love to see drift off into the sunset if RH backports WireGuard into EL kernels.
Actually, that's not even relevant. For the last several years, I've been developing WireGuard on top of the latest kernel from Linus, while maintaining a "compat" layer to seamlessly backport it using horrendous tricks with the C preprocessor. That's allowed me to keep the codebase clean and ready for mainline Linux, while enabling people to use it on all the old kernels. I've maintained this backport layer for every kernel since Linux 3.10, including the RHEL-7 and RHEL-8 ports. This has been quite a lot of ugly work, but ultimately worth it as its given us enormous amounts of testing in odd environments, so what's shipping now in Linux 5.6 is rather polished, as opposed to being brand new and untested. We maintain some CI for this, too, testing lots of kernels and architectures. Scroll down to the "wireguard-linux-compat" section of https://www.wireguard.com/build-status/ to see.
All this is to say that there's not really much work that needs to be done by Ubuntu or RHEL or anyone else that wants to ship WireGuard -- the backporting stuff has already been done and is fairly widely deployed by now.
I thought it was fair to wait for 2022.04 when Wireguard is only about to be included in mainline and few years in the kernel will certainly make it feel stable for the next LTS inclusion, so I was kind of surprised they went for it now as a backport.
Perhaps the code is good enough there aren't many weird bug reports to make it feel unstable.
> WireGuard is currently working toward a stable 1.0 release. Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software). This text will be removed after a thorough audit.
What’s the best “WireGuard as a VPN configuration” doc out there? Many are not clear about what is being set up, why the cidrs are chosen, how it works without DHCP etc. other guides focus on only proxying rfc1918 traffic and not your entire connection. Is my DNS leaking? Is ALL traffic going through it?
OpenVPN, with all of its issues, is simple to set up in a way that’s not leaky.
If you put two /1 routes towards the private vpn endpoint and one route for your public vpn endpoint to your public ip it'll route all traffic over the vpn because it's the more specific route. The rest is your ip rules and your issue if you don't want any traffic in your physically attached subnet to go over the shortest distance. It's not really up to the protocol, it's the tooling around it.
Wireguard needs to put actual logging into the product before anyone should consider using it in production.
I have to deal with it via a vendors product and have spend about 4 weeks in the past 6 months trying to fix a flaky connection by guessing and restarting a lot. Just like anything things will go wrong. But, with wireguard you have no idea what it could even be if it's not an obvious thing that you can diagnose with ping.
Wireguard also needs a better auth mechanism. I really like the simple secure key-based auth for small-scale stuff, but it's not viable for scaling at production levels. Things like user/pass auth (even if as an additional layer of security rather than displacing existing keys), 2FA, etc. will be important to get adoption at scale. I hope wireguard creates a module interface of sorts so people can extend the protocol as needed.
Wireguard doesn't need to change at the protocol level to add those features and I think thats the point. Userspace programs can be written to fetch keys from a server based on SSO or w/e.
The thing about simple, key-based authentication is that it's very extensible, without changing the actual protocol.
What?
Well, what Wireguard's auth actually means is that you can use whatever authentication you want to communicate a shared secret to both ends.
Want to authenticate with, say, SSH keys? Sure- SSH into a server, run a command that generates a new Wireguard key, connect in with that key.
LDAP? Same situation. Whatever SSO you want- as long as you can stick up authentication in front of a service that's able to pull bits from /dev/urandom. Multifactor? Sure.
Wireguard does one thing well. What's missing is not features in Wireguard- it's the ecosystem around it to actually handle key management. For enterprises, Hashicorp Vault or something should probably look into supporting Wireguard; for smaller situations, some SSH-based key exchange, like the way Mosh handles things, seems reasonable.
Complex, pluggable authentication is sometimes necessary...but you want as few implementations of it as possible, and you sure don't want it in the kernel if you can help it.
The problem is lots of organisations in the financial and medical worlds need 2FA. WireGuard needs a 2FA solution - It doesn’t have to be kernel based - but it does need to protect against someone grabbing a copy of the single factor auth in WireGuard (keypair). A solution that rotates/manages/provisions/etc these keypairs is still fundamentally single factor auth of the tunnel.
Nobody is arguing that there shouldn't be IdP-based WireGuard management systems. The point is that they are out of scope for the WireGuard project itself. WireGuard has an extremely straightforward configuration interface; if Okta wanted to manage WireGuard, they'd likely have no problem doing it.
You don’t need a distro for this, and WireGuard has been available and in use for several years. So in that time has anyone developed a practical 2FA solution that is compatible with it?
People have. I'm unaware of any published. It's not hard. Implementing a new IdP-integrated WireGuard authorizer is probably easier than understanding IPSEC or OpenVPN in sufficient detail to secure it.
> WireGuard needs a 2FA solution - It doesn’t have to be kernel based - but it does need to protect against someone grabbing a copy of the single factor auth in WireGuard (keypair).
By this standard, no website supports 2FA- ultimately it's just a cookie that's used to authenticate requests, even though to get that cookie you may have to go through 2FA. Nothing prevents an attacker from just grabbing the session cookies.
In fact, I doubt any VPN supports 2FA by this definition- it would mean requiring authentication on every packet. Instead, of course, what you do is do authentication once, when setting up a tunnel, and then use bearer tokens from then on.
The session info in a browser is not persisted on disk as a long term config file that’s easy to copy and duplicate. Having a session key only ever exist in memory is completely different to storing WireGuard keys on a filesystem.
Edit: Also OpenVPN, which is the tool I’m comparing it with, only ever has session keys in memory. The 2FA part (password+OTP) isn’t saved by OpenVPN.
The problem is that a Wireguard key isn't a session token -- it isn't revoked when the connection ends or goes idle. It's more like an authorized SSH key which in most environments meets the bar for 1FA even if it requires 2FA to set up the key.
WG has the concept of sessions already, the only change would be allowing a process in userspace to instrument the sessions directly without going through the key system.
The the default key-routing system would be just one method of issuing and managing sessions making the core protocol even simpler!
By sessions, do you mean the key agreement/initiation protocol, that is re-run every 2 or so minutes (with the keys having moderately overlapping validity)?
It looks quite good, but I don't see any information on:
1. Is it open-source?
2. When am I going to see the "you have to pay us now" screen, and how much will it cost? I realize it's a business and am fine with that, but want to know what I'm spending before setting stuff up.
The iOS app is very bare-bones and it drops the connection once a day and doesn’t notify you about and doesn’t try to reconnect automatically. I hope Mullvad VPN will release their own app this year.
FTR, WireGuard also available in F-Droid repo for all Android 5.0+ devices.[0]
> If your device has a custom kernel containing the WireGuard module, then the module will be used for superior battery life and performance. Otherwise a userspace version will work sufficiently on all other devices.
Yea, kernel-wireguard on Android is just for people who have rooted their phones and want a little extra adventure. Cellphones have weird networking stacks and unusually written drivers (I'm looking at you, qcacld and rmnet_perf...), so supporting WireGuard's kernel module on Android has been very worthwhile to us for fine tuning things. Plus the performance is as good as can be in kernel space. But it's definitely something for "rooters only."
Could someone please explain what a meaningful example usage of WireGuard might be? The intro seems to imply something that could be duplicated with a terminal + SSH forwarding + a VPS. How is this better and/or different?
Thank you :-)
While I love the product and use it in production, debugging is a royal pain in the ass.
There is zero logging to help understand when and how a connection is established (or not) server side.
Logging that someone tries to conne ct but wrong key, wrong protocol, whatever - that would help tremendously. Today it is tcpdump or wireshark all the way.
90 comments
[ 3.0 ms ] story [ 118 ms ] threadhttps://news.ycombinator.com/item?id=7071219
The fact that Ubuntu is including it, means that it's probably passed a critical mass of early adopters and then is probably seeping into the startup mainstream (as opposed to enterprise that wants 20 valid bells and whistles like authentication, auditing, etc).
> should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software)
I figure they know better than I do.
Security people are also subject to fads and fashion just like web developers or indeed any other technical group. Many will endorse the primitives developed for example by Dan Bernstein without understanding anything about how they actually work, or having read and understood papers describing their security. Just because he has some hacker "street cred" (arguably well deserved) as the developer of qmail, etc.
So my genuine question is: does he really have an unusual academic standing as a cryptographer?
This ranking by citation (which appears to be up-to-date/live) puts him in position 62: https://kodu.ut.ee/~lipmaa/cites/cites.php?data=crypto
Granted, it's just a ranking by citation, and this definitely puts him in the top 100, which is nothing to scoff at, but I'm still wondering if there is a similar effect, and if in ten years we won't be using algos all written by some other guy because he's the new cool kid.
I do have issues with wireguard's security - things like silently accepting invalid configuration, changing one peer can silently affect another (only avoided via external means), roaming is default enabled and can't be disabled nor can you bind the tunnel to an interface or an ip, nor does it pad packets even the slightest to reduce "meta"data leakage.
Just because the cryptography is (probably) sane, doesn't mean wireguard as a whole is good for all or most use-cases.
https://lists.zx2c4.com/pipermail/wireguard/2020-January/004...
> Please note that until Linux 5.6 is released, this snapshot is a snapshot rather than a secure final release.
In other words, over the next ~10 weeks, Linus' kernel tree and Dave Miller's net.git tree will fill up with nice stabilization patches. At the end of that process, 5.6 will be released. At that time, our backports to older kernels (wireguard-linux-compat) will also become a "1.0". This also lines up with the 20.04 LTS release and such.
Debian 11 - Mid 2021, probably
OpenSUSE Leap/SLES 16 - Mid 2021, probably
Ubuntu 22.04 LTS - April 2022
Red Hat 9 - probably 2024 ?
So if Ubuntu hadn't included this, we would have to wait more than a year to have it in the kernel of a "server-grade" Linux system by default. Most people don't like running more cutting edge distros or fiddling with the kernel on their servers. Defaults matter, so this will be great for Wireguard adoption.
I wouldn't bet on a backport unless you have a lot of clout (a.k.a. purchasing power) behind you.
The problem is "RHEL doesn't also ship newer PHP as an alternative and you need to instead rely on third-party repositories".
For CentOS and friends there is https://www.softwarecollections.org/en/
https://access.redhat.com/products/Red_Hat_Enterprise_Linux/... are maintained by RedHat directly.
Packaging WireGuard for Fedora, CentOS, and RHEL has been super fulfilling over the years, but DKMS is super fickle and buggy. wireguard-dkms is a package I would love to see drift off into the sunset if RH backports WireGuard into EL kernels.
All this is to say that there's not really much work that needs to be done by Ubuntu or RHEL or anyone else that wants to ship WireGuard -- the backporting stuff has already been done and is fairly widely deployed by now.
Thanks for your work. I know I will benefit from it.
(I mean that in a positive way. I'm a fan of both... although only theoretically about WireGuard.)
Perhaps the code is good enough there aren't many weird bug reports to make it feel unstable.
> WireGuard is currently working toward a stable 1.0 release. Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software). This text will be removed after a thorough audit.
IMHO roaming should be opt-in iif you specify the remote endpoint.
OpenVPN, with all of its issues, is simple to set up in a way that’s not leaky.
https://www.wireguard.com/netns/#routing-all-your-traffic
There's probably some guides out there.
I have to deal with it via a vendors product and have spend about 4 weeks in the past 6 months trying to fix a flaky connection by guessing and restarting a lot. Just like anything things will go wrong. But, with wireguard you have no idea what it could even be if it's not an obvious thing that you can diagnose with ping.
The thing about simple, key-based authentication is that it's very extensible, without changing the actual protocol.
What?
Well, what Wireguard's auth actually means is that you can use whatever authentication you want to communicate a shared secret to both ends.
Want to authenticate with, say, SSH keys? Sure- SSH into a server, run a command that generates a new Wireguard key, connect in with that key.
LDAP? Same situation. Whatever SSO you want- as long as you can stick up authentication in front of a service that's able to pull bits from /dev/urandom. Multifactor? Sure.
Wireguard does one thing well. What's missing is not features in Wireguard- it's the ecosystem around it to actually handle key management. For enterprises, Hashicorp Vault or something should probably look into supporting Wireguard; for smaller situations, some SSH-based key exchange, like the way Mosh handles things, seems reasonable.
Complex, pluggable authentication is sometimes necessary...but you want as few implementations of it as possible, and you sure don't want it in the kernel if you can help it.
By this standard, no website supports 2FA- ultimately it's just a cookie that's used to authenticate requests, even though to get that cookie you may have to go through 2FA. Nothing prevents an attacker from just grabbing the session cookies.
In fact, I doubt any VPN supports 2FA by this definition- it would mean requiring authentication on every packet. Instead, of course, what you do is do authentication once, when setting up a tunnel, and then use bearer tokens from then on.
Edit: Also OpenVPN, which is the tool I’m comparing it with, only ever has session keys in memory. The 2FA part (password+OTP) isn’t saved by OpenVPN.
WG has the concept of sessions already, the only change would be allowing a process in userspace to instrument the sessions directly without going through the key system.
The the default key-routing system would be just one method of issuing and managing sessions making the core protocol even simpler!
1. Is it open-source?
2. When am I going to see the "you have to pay us now" screen, and how much will it cost? I realize it's a business and am fine with that, but want to know what I'm spending before setting stuff up.
The kernel already has this:
Then you'll get useful messages in your syslog.> If your device has a custom kernel containing the WireGuard module, then the module will be used for superior battery life and performance. Otherwise a userspace version will work sufficiently on all other devices.
[0] https://apt.izzysoft.de/fdroid/index/apk/com.wireguard.andro...
https://github.com/WireGuard/android-wireguard-module-builde...
Wireguard is much easier to set up than either IPSec or OpenVPN, and seems to outperform at least the latter.
There is zero logging to help understand when and how a connection is established (or not) server side.
Logging that someone tries to conne ct but wrong key, wrong protocol, whatever - that would help tremendously. Today it is tcpdump or wireshark all the way.