[HN Gopher] WireGuardNT, a high-performance WireGuard implementa...
___________________________________________________________________
WireGuardNT, a high-performance WireGuard implementation for the
Windows kernel
Author : zx2c4
Score : 374 points
Date : 2021-08-02 17:39 UTC (5 hours ago)
(HTM) web link (lists.zx2c4.com)
(TXT) w3m dump (lists.zx2c4.com)
| bob1029 wrote:
| This is exciting to me. I have tripped over every VPN technology
| listed on Wikipedia at one point or another during my career.
| Always open to something better.
|
| I think IPSec or OpenVPN are probably the opposite of what WG is
| offering here... Microsoft's SSTP offering is actually not
| causing me any major frustration at the moment. I _almost_ like
| using it. But, seeing these other comments telling tales of 600
| megabit VPN wifi experiences... I 'll check it out for sure.
| midasuni wrote:
| I had an sstp tunnel refuse to establish a few weeks ago.
| WireGuard was fine. Turns out the provider was MITMing tcp/443
| traffic
| planetafro wrote:
| Wouldn't they need a cert/custom CA on your box to do that?
| SahAssar wrote:
| They could just block all tcp/443 traffic that they
| couldn't MITM, that's not uncommon in those kinds of
| setups.
| Panino wrote:
| Very impressive performance:
|
| > While performance is quite good right now (~7.5Gbps TX on my
| small test box), not a lot of effort has yet been spent on
| optimizing it
|
| > Jonathan Tooker reported to me that, on his system with an
| Intel AC9560 WiFi card, he gets ~600Mbps without WireGuard,
| ~600Mbps with wireguard-go/Wintun over Ethernet, ~95Mbps with
| wireguard-go/Wintun over WiFi, and ~600Mbps with WireGuardNT over
| WiFi.
|
| Congratulations to Simon and Jason! Very happy WireGuard user
| here.
| brian_herman wrote:
| Yes, I am gonna reinstall wireguard on my raspberry pi again.
| This is amazing news. And I will try and getting my windows
| server ryzen pc to be a router so I can benchmark all four
| configs.
| eptcyka wrote:
| If you're running a recent enough kernel, it's technically
| already there, maybe without the userspace tools.
| zinekeller wrote:
| While the driver can be licensed under GPLv2 (all kernel drivers
| needs to be signed by Microsoft*, and VirtIO is a precedent$?
| that you can do it), I'm not sure if the header should be
| licensed under GPLv2, mainly because it would stifle Wireguard
| adoption.
|
| * In ordinary conditions. Test-sign mode does exist.
|
| $? ... for example, these Red Hat versions:
| https://www.catalog.update.microsoft.com/Search.aspx?q=Red%2...
| Denvercoder9 wrote:
| The header is dual-licensed under GPLv2 and MIT.
| vetinari wrote:
| You can get them here:
| https://fedorapeople.org/groups/virt/virtio-win/direct-downl...
| packaged in a nice iso, ready to use for iso store of your
| hypervisor.
|
| (It might be also slightly newer; v204 is 100.85.104.20400).
| kzrdude wrote:
| What is WireGuard, is it a new protocol? Or a new algorithm for
| implementing an existing thing? (Or something else)
| Scaevolus wrote:
| Wireguard is a UDP-based VPN protocol that focuses on
| simplicity and security. Its Linux implementation is a mere
| 4000 LOC and the protocol has been formally verified. OpenVPN
| is over 100,000 lines of code PLUS OpenSSL.
|
| https://www.wireguard.com/talks/lpc2018-wireguard-slides.pdf
| TedDoesntTalk wrote:
| It's point-to-point.
| nicoburns wrote:
| It's a VPN protocol whose USP is being dramatically simpler
| than OpenVPN, which should mean that it is both easier to use
| and more secure (and consensus seems to be that it generally
| delivers on both of those fronts).
| basch wrote:
| dramatically simpler than IPsec.
|
| IPSec is Internet Layer, while TLS/SSL (OpenSSL) are
| Application Layer
| netr0ute wrote:
| >IPSec is Internet Layer
|
| Technically not, since IPSec can also be tunneled over UDP
| which then turns it into an application layer protocol.
| hujun wrote:
| the main reason IPsec is more complex is because it has
| more features, like multiple CHILD_SA under same tunnel
| each with different transform and traffic selectors, and
| also much more authentication choices
| puzzlingcaptcha wrote:
| I honestly think "ipsec is too complex" is overdone. Yes,
| you need to know your networking basics and understand
| routing but that's probably a good thing when setting up
| a VPN. Then you pick your crypto primitives from e.g.
| https://www.keylength.com/en/compare/ and you are
| basically done.
|
| But no, it's the typical groupthink of 'old is bad' so
| instead of reading two pages of documentation and having
| native support across all major platforms people would
| rather re-invent the wheel.
| Denvercoder9 wrote:
| _> It 's a VPN protocol whose USP is being dramatically
| simpler than OpenSSL_
|
| What? WireGuard is a VPN protocol (and implementation), while
| OpenSSL is an implementation of TLS. They're not competing
| with each other, and you can't compare them.
| freedomben wrote:
| GP probably meant OpenVPN
| cosmosgenius wrote:
| i think it was meant to be openvpn instead on openssl
| nicoburns wrote:
| Yep, got the wrong Open* software. Not sure how I managed
| that.
| [deleted]
| dsr_ wrote:
| wireguard is a VPN technology that is now integrated into the
| Linux kernel, and is available on all major platforms.
|
| It distinguishes itself from other VPNs by not having knobs to
| twiddle. Should a security issue arise, it will be necessary to
| replace it with a wireguard2 or such. This also means that it's
| very hard to get it wrong in config; either it works or it
| doesn't, and if it doesn't, you haven't got it working yet.
|
| It's very fast and very nice to work with.
| Sesse__ wrote:
| Wireguard is pretty much half of what you'd expect from a
| VPN. It does the low-level part (encryption, packetization,
| session setup, NAT traversal, etc. -- the "actual VPN")
| brilliantly, but everything around key distribution is left
| to external systems. (Tailscale is a popular choice, but by
| no means the only one.) E.g., you can't connect to
| vpn.example.com with user foo and password bar and that's it;
| there needs to be an Ed25519 public/private keypair set up on
| both sides, an IP address range (essentially a routing
| table), and so on.
|
| Of course, if you want to connect two static networks, wg-
| quick is all you need. But for the typical "remote worker
| VPN", it's pretty much a (great) building block.
| nemosaltat wrote:
| I've been begrudgingly using Tailscale because it's so damn
| simple, but hate that I have to authenticate through
| Google. I recently noticed they've added a "sign in with
| GitHub option," but I don't see any easy way to migrate my
| account (and nodes). Many of the clients are PiHoles I've
| sent off to my family as gifts, so physical access is a
| PITA. The only way I've found to reliably clear the
| Tailscale settings is to `apt purge Tailscale`, which would
| cause me to lose Tailscale SSH access. Looking at the
| hassle of the remote reinstall- I'm thinking to SSH in with
| Tailscale, then establish a reverse SSH tunnel to maintain
| remote access - I think I may finally give Innernet [0] a
| go.
|
| [0] https://github.com/tonarino/innernet
| Serow225 wrote:
| You can also use Microsoft now (both "personal" accounts
| like used for Xbox/Outlook and "Enterprise" accounts like
| Microsoft365 and other AAD based accounts)
|
| I'm sure if you asked them about switching auth methods
| they would help with that.
| netr0ute wrote:
| > but everything around key distribution is left to
| external systems.
|
| That's what I'd like, since authentication is usually a
| pain to set up and with Wireguard, there's none to be done.
| This also means it's totally stateless and is great for
| mobile devices where a connection might be broken and
| crsated again frequently.
| IshKebab wrote:
| Except FreeBSD which is used for pfSense - a popular
| firewall. They're working on it though. There was a bit of
| drama about it a few months ago when a shoddy implementation
| was merged.
| yjftsjthsd-h wrote:
| FreeBSD can use the userspace implementation just fine;
| what almost made it out but was caught before it could
| actually be released was an in-kernel module for it.
| [deleted]
| Trufa wrote:
| That sounds heavenly. I had never really thought about that
| immutability like concept, makes a lot of sense for security
| oriented software.
| tptacek wrote:
| I think you could reasonably look at WireGuard as a repudiation
| of previous VPN protocols, almost from root to branch.
|
| For instance, WireGuard reconsiders what the role of a VPN
| "protocol" actually is, and in WireGuard the protocol itself
| delivers a point-to-point secure tunnel and nothing else, so
| that the system is composable with multiple different upper-
| level designs (for instance, how you mesh up with multiple
| endpoints, or how you authenticate).
|
| Another reasonable way to look at WireGuard is that it's the
| Signal Protocol-era VPN protocol (WireGuard is derived from
| Trevor Perrin's Noise protocol framework).
|
| Notably: WireGuard doesn't attempt to negotiate cryptographic
| parameters. Instead, they've selected a good set of base
| primitives (Curve25519, Blake2, ChaPoly) and that's that; if
| those primitives ever change, they'll version the whole
| protocol.
|
| If you haven't played with it, WireGuard is approximately as
| hard to set up as an SSH connection. It is _really_ a breath of
| fresh air.
| pkaye wrote:
| Does it use key management like SSH or more like certificates
| with TLS?
| Macha wrote:
| It's like SSH, with no Trust-on-First-Use option. Unlike
| more complicated pre-existing protocols, how you handle key
| distribution is explicitly out of scope for the protocol.
| simcop2387 wrote:
| It's more like client certs with tls that are signed by the
| server's key I believe.
| lights0123 wrote:
| Nope. You have a private and public key per connection.
| phkahler wrote:
| >> What is WireGuard?
|
| According to Linus: "...compared to the horrors that are
| OpenVPN and IPSec, it's a work of art."
| stjohnswarts wrote:
| The wikipedia article for it is actually quite informative and
| not hard to read for the layperson.
| https://lmwtfy.joe.gl/?q=wireguard
|
| Also Ars had a great article on it as well if you want a
| readable but more in depth version
| https://arstechnica.com/gadgets/2018/08/wireguard-vpn-review...
| aborsy wrote:
| In some networks, I only have outgoing tcp ports 80 and 443.
|
| Does anyone have experience with udp2raw or udptunnel?
| roozbeh18 wrote:
| WireGuard is so good, sometimes I forget I am on vpn and only
| realize it when downloading a large file that my speed is capped
| by my home speed.
| benbristow wrote:
| I've had good experiences using Tunsafe compared to the official
| client. Get full gigabit speeds from a decent VPN provider.
| karmanyaahm wrote:
| fancy! i'll ask my friends on windows to test this
| nixcraft wrote:
| I would like to see 2FA (app or security key) support built into
| WireGuard. Otherwise, it is perfect as compared to the OpenVPN
| mess.
| jagger27 wrote:
| Isn't that just a roundabout way of asking for PSK support
| (which it already has)?
| yobert wrote:
| Think of wireguard as the plumbing. There will be a plethora of
| things available on top of wireguard that will enable all sorts
| of easy authentication options. (For example, TailScale.)
| londons_explore wrote:
| And will, themselves, lead to a new kind of incompatibility
| mess...
|
| "Oh, I'm afraid the EasySecureAuth wireguard server doesn't
| support the AndroidWireClient client when using a Yubikey
| version 1. Either use version 2 or switch to iOS."
| l3s2d wrote:
| Related: Does anyone know of a PKI-on-WireGuard
| implementation? Specifically I'm looking for a system that
| lets clients join the WireGuard network by presenting a CA-
| signed certificate.
| puzzlingcaptcha wrote:
| I mean, re-inventing IPsec is probably inevitable anyway.
| vbezhenar wrote:
| How this plumbing is expected to be implemented? For example
| Cloudflare Warp uses Wireguard for its VPN solution, but all
| key exchanges and other stuff happens via HTTPS REST calls.
| Is it expected for any non-trivial implementation to build a
| different "control" protocol? For me it sounds like a
| dangerous approach. While wireguard protocol will be safe and
| audited, those additional proprietary protocols will hinder
| cross-platform usage (for example you had to use reverse-
| engineered Cloudflare Warp implementation for Linux until
| recently and I guess that BSDs will use it forever) and might
| expose security vulnerabilities on their own.
| corty wrote:
| Yes, you are exactly right. Wireguard is a typical example
| of a thing I'd call myopic-cryptographer-protocol. Solve
| one problem in the minimal fashion that can be called
| proof-of-concept, do it in a maybe-more-secure way and call
| it done. Everything else, like proper key distribution and
| user management, which you need for a real-world deployment
| that isn't just a personal toy, is left as an exercise to
| the reader. All the readers will screw up in different
| ways, after which the myopic cryptographer will explain
| that his protocol was of course perfect and there is
| nothing wrong with it, you are just holding it wrong...
| kook_throwaway wrote:
| That's one way to look at it.
|
| Another would be "Do one thing and do it well", which is
| Unix philosophy.
|
| https://en.m.wikipedia.org/wiki/Unix_philosophy
| phkahler wrote:
| Another might be that existing VPN solutions will gut the
| bottom of their stack and use WireGuard for that, thereby
| reducing complexity and increasing performance.
| kook_throwaway wrote:
| I think there's already some that do that iirc.
| wmf wrote:
| If people want Wireguard to be a complete multiplatform
| audited free enterprise VPN solution they need to donate
| more. A lot more.
| xvector wrote:
| Even if they donate more that won't happen. It's
| antithetical to the premise of the whole project.
| WireGuard is fine where it is, it's amazing.
| corty wrote:
| Nobody really needs enterprise VPN crap, that stuff does
| far too much weird stuff that is totally unrelated to
| what a VPN should do, like patch management, malware
| scanning, firewalling, and other useless box-ticking.
|
| What we do need is a proper replacement for roughly the
| things OpenVPN plus PAM can do. A VPN plus some user and
| key management.
| unethical_ban wrote:
| It is a completely reasonable requirement of a large
| organization to ensure an endpoint meets certain criteria
| before being allowed access to an internal network.
|
| I'm not arguing that Wireguard has an obligation to
| tackle that problem themselves. I'm arguing against your
| assertion that VPN access should be completely decoupled
| from ensuring endpoint security.
| londons_explore wrote:
| Lets be honest, any malicious endpoint can easily bypass
| those 'endpoint security' checks.
|
| All they're good for is checking that unpatched (but not
| yet exploited/evil) endpoints can't connect to the
| network, which is of marginal benefit compared to
| allowing them to connect but requiring they patch before
| accessing risky resources (like the internet or email).
| clon wrote:
| Not all parts of a system are going to age equally well.
|
| You are going to want to try to avoid that problem, while
| making your tool still useful. Wireguard hits the sweet
| spot particularly well.
| nimish wrote:
| I think this was the point of WG. OpenVPN/IPSec/etc are
| beasts since they include all of the above. OpenVPN is
| TLS based! That makes adding it into the kernel
| difficult, and you need kernel access or exotic stuff
| like VPP/DPDK for speed.
|
| I do agree with your overall sentiment, though. The next
| step is to make a higher level protocol on top.
| anonymousiam wrote:
| WireGuard is not MFA, but the user's private key could probably
| be stored in a smart-card instead of on disk. Software changes
| would need to be made so the key is read from the card instead
| of specified in the wgx.conf file.
|
| To achieve true MFA, it would need either a password, TOTP, or
| SMS in addition to the stored keys.
| corty wrote:
| Nope, can't. Storing a Wireguard key on a Smartcard isn't
| possible, because current cards do not support the key format
| and algorithms Wireguard uses. Only RSA and ECDSA on NIST
| curves are available on Smartcards. And "reading" the key
| from the card would make the card useless, the important
| feature of a smartcard is that it doesn't ever make the key
| available for reading. Instead, the key is used for signing
| or decrypting _on the card_ only. If you can really read a
| key off of a smartcard, sue the manufacturer and never use
| the key or card again.
| pat2man wrote:
| Technically if the card could sign fast enough, you could
| sign packets on the card.
| corty wrote:
| You only need to sign the packets in the key exchange on
| the card. The normal payload packets are protected by
| symmetric algorithms based on the ephemeral symmetric key
| generated in the key exchange, no need (and no use) to
| involve the smartcard there.
| pritambaral wrote:
| WireGuard seems to use symmetric key crypto for packet
| encdec. The card would need to sign only the handshake,
| which occurs "every few minutes"[1] and "is done based on
| time, and not based on the contents of prior packets"[1].
|
| 1: https://www.wireguard.com/protocol/
| the8472 wrote:
| Wireguard uses perfect forward secrecy, so wouldn't signing
| the ephemeral session once with the hardware key do the
| job? Or do they need some more advanced operations that the
| devices don't expose?
| corty wrote:
| No, you just need a signature. But an Ed25519 signature,
| which current commercially available smartcards just
| cannot do.
|
| You could be hacking something together with a Nitrokey
| or maybe Yubikey, those can do Ed25519 signatures. But
| generally, you would need to fiddle a lot with the
| implementation, because currently signatures are done in
| the kernel module, and you'd need to get that into the
| USB-device for signing and back again. Not impossible,
| but not implemented yet.
|
| Another way would (theoretically) be to implement
| different signature algorithms for the wireguard key
| exchange, ideally some that common smartcards do support.
| But wireguards author left out cryptographic agility on
| purpose, so any work in that direction will be
| incompatible with the original implementation, or at
| least a very ugly kludge.
| ptomato wrote:
| You'll have to write some glue code, but if all you need
| is standard Ed25519 signatures, current-gen Yubikeys can
| do this. Somebody's implemented a python library that
| does that here https://github.com/tschudin/sc25519
| hlandau wrote:
| Of course, there are smartcards that could do this,
| you're just not allowed to have them. Plenty of
| smartcards nowadays are just flash and an ARM core which
| theoretically could be programmed arbitrarily. These tend
| to be used for credit cards, etc. Of course they might
| have acceleration units for specific algorithms like NIST
| ECDSA but I'd be surprised if Ed25519 couldn't be
| accommodated.
|
| Unfortunately they're all NDAware, so they may as well
| not exist. ...But of course I've written about my
| extensive issues with the smartcard industry before.
| mschuster91 wrote:
| > Storing a Wireguard key on a Smartcard isn't possible,
| because current cards do not support the key format and
| algorithms Wireguard uses. Only RSA and ECDSA on NIST
| curves are available on Smartcards.
|
| There are programmable smartcards on which you can
| implement your own algorithm. ZeitControl sells cards you
| can program in a BASIC dialect: https://www.zeitcontrol.de/
| de/produkte/basiccard/basiccard-p...
| idorosen wrote:
| WireGuard itself doesn't even handle its existing
| authentication fully -- you are expected to exchange peer
| public keys out of band. There are several projects that try to
| tackle this public key exchange. I think what you're asking
| for, indirectly, is support for certificate authority style
| authentication similar to how SSH CAs work, so that wireguard
| could authenticate tunnels using certificates with signed
| pubkeys instead of statically configured pubkeys themselves for
| each peer.
|
| If the wireguard core included any kind of timed partial
| delegation of authority through key signatures (similar to what
| SSH allows now with cert-authority/CertificateFile), that'd be
| enough to build SMS/HOTP/TOTP 2FA, security keys, and much more
| on top of it.
| drexlspivey wrote:
| Adding features like this that should be implemented on a
| different layer is the perfect way to turn it to the OpenVPN
| mess
| stjohnswarts wrote:
| I think you'll have to use other options for that. I don't see
| them ever implementing 2FA as that is outside the goals of the
| project. They want to keep it has slim, performant, and on
| target as possible.
| atonse wrote:
| Tailscale solves all these problems, including SSO.
|
| Can you tell I'm a very happy customer?
| EwanToo wrote:
| Pritunl has wireguard support and works well for this
| ec109685 wrote:
| Any thought if Windows will embed this natively similar to how
| Linux pulled WireGuard into the kernel?
| Macha wrote:
| Not in its current form: https://git.zx2c4.com/wireguard-
| nt/tree/COPYING
___________________________________________________________________
(page generated 2021-08-02 23:00 UTC)