Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuard is submitted for Linux kernel inclusion

marc.info

Post reply on HN
Print view View original

131–140 of 189 posts

Re: WireGuard is submitted for Linux kernel inclusion

#131

Post by poizan42 »

rhblake wrote: post #114
exhilaration wrote: post #103

Earlier quoted context omitted.

How did you install it on your router? I'm assuming this isn't a throwaway $30 consumer router?

I use it on an EdgeRouter Lite 3 which is about $99. See: https://github.com/Lochnair/vyatta-wireguard https://community.ubnt.com/t5/EdgeRouter/Release-WireGuard-f... (discussion)

The EdgeRouter Lite 3 also happens to be one of the few generally available Mips64 platforms (Cavium OCTEON CN5020). Actually I have just ordered its big brother EdgeRouter Lite 4. It costs double as much, but it also packs a quad-core 1GHz OCTEON CN7130.

Re: WireGuard is submitted for Linux kernel inclusion

#132

Post by chasil »

Hello71 wrote: post #83
StavrosK wrote: post #32

Earlier quoted context omitted.

> it'll complain about unknown keys/values or something if you use a wg-quick config with extra firewall rules and the like with plain wg. Really? I didn't even know that, thanks. > if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config Ouch. Yeah, these things definitely need to be documented, I had no idea about this either. I would also like to see an easier way t…

> I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc. The config file is designed to be very straightforward and contain only the bare minimum required configuration stanzas. If you want to separate the keys, or use a higher level key negotiation protocol (e.g. TLS), you can write your own script that c…

What I am wondering is why they chose 25519.

It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection.

https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...

Re: WireGuard is submitted for Linux kernel inclusion

#133

Post by harshreality »

StavrosK wrote: post #113
zx2c4 wrote: post #106

Earlier quoted context omitted.

> but I believe Wireguard is held back by its lack of documentation. Indeed having good documentation is super important. I'm not so arrogant as to proclaim, "I don't have time to write docs! Understand it yourself!", but I am stretched super thin, and I suspect that often times documentation from somebody who _isn't_ the creator winds up being a bit better, because exterior perspectives are useful. So it's my hope t…

I had, indeed, not found the man pages, thank you. I also intend to write up how to deploy Wireguard with a simple "access the home LAN from the outside" configuration in the next few days, which will hopefully be useful to people.

If you want to document "How I access my home network remotely" but you're really spending a few paragraphs repeating the wireguard docs before moving on to other things like your choice of IPs, your logging setup, how to retrieve mail, how to ssh places, and stuff like that, please realize that none of that other stuff has anything to do with wireguard. You could just as easily be documenting those things with an OpenVPN or IPsec vpn or even an unencrypted tunnel. That's why those things are not in the wireguard docs.

If there's something that involves wireguard itself that's missing from or unclear in the docs, could you please clarify?

Re: WireGuard is submitted for Linux kernel inclusion

#134

Post by tialaramex »

chasil wrote: post #132
Hello71 wrote: post #83

Earlier quoted context omitted.

> I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc. The config file is designed to be very straightforward and contain only the bare minimum required configuration stanzas. If you want to separate the keys, or use a higher level key negotiation protocol (e.g. TLS), you can write your own script that c…

What I am wondering is why they chose 25519. It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection. https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...

Doing DH with Curve25519 is a broadly understood conventional public key based key agreement scheme. We have good reason to think these are an excellent, fast, secure way to do things, unless your adversary has a working large Quantum Computer so that they can use Shor's algorithm.

NTRU Prime is for a post-quantum KEM. This does, yes, solve the same piece of the puzzle in a sense. But it's essentially one enormous experiment. Huge breakthroughs in cryptanalysis for this stuff happen all the time, by next week you might believe NTRU Prime is a joke and nobody should ever have used that, which makes requiring it at the core of a new "secure" service in Linux seem like maybe a bad idea. Bernstein and co. caution, in their submission of NTRU itself, that "the security of lattice-based cryptography is not well understood. There are serious risks of further advances".

Re: WireGuard is submitted for Linux kernel inclusion

#135

Post by StavrosK »

harshreality wrote: post #133
StavrosK wrote: post #113

Earlier quoted context omitted.

I had, indeed, not found the man pages, thank you. I also intend to write up how to deploy Wireguard with a simple "access the home LAN from the outside" configuration in the next few days, which will hopefully be useful to people.

If you want to document "How I access my home network remotely" but you're really spending a few paragraphs repeating the wireguard docs before moving on to other things like your choice of IPs, your logging setup, how to retrieve mail, how to ssh places, and stuff like that, please realize that none of that other stuff has anything to do with wireguard. You could just as easily be documenting those things with an Op…

> none of that other stuff has anything to do with wireguard

Sure, none of it is specific to Wireguard, but my personal use case was "hey, Wireguard looks cool, maybe I could use it to access my home LAN when I'm away. Hmm, how do I talk to the other machines from the VPN server?".

It's like saying "if you want to bake a cake, none of the baking has anything to do with our flour". You're technically right, but it'll benefit you to put a recipe on the box.

Re: WireGuard is submitted for Linux kernel inclusion

#136

Post by Zenig_ »

rurban wrote: post #88

The only thing I don;t like about current WireGuard is that the single config file contains both the private key in clear, and all the public keys. IMHO the private keys should be in a separate file.

https://wiki.archlinux.org/index.php/WireGuard#Store_private...

Re: WireGuard is submitted for Linux kernel inclusion

#138

Post by harshreality »

StavrosK wrote: post #135
harshreality wrote: post #133

Earlier quoted context omitted.

If you want to document "How I access my home network remotely" but you're really spending a few paragraphs repeating the wireguard docs before moving on to other things like your choice of IPs, your logging setup, how to retrieve mail, how to ssh places, and stuff like that, please realize that none of that other stuff has anything to do with wireguard. You could just as easily be documenting those things with an Op…

> none of that other stuff has anything to do with wireguard Sure, none of it is specific to Wireguard, but my personal use case was "hey, Wireguard looks cool, maybe I could use it to access my home LAN when I'm away. Hmm, how do I talk to the other machines from the VPN server?". It's like saying "if you want to bake a cake, none of the baking has anything to do with our flour". You're technically right, but it'll…

"How do I talk to the other machines from the vpn server"

The same way you would if everything on your side of the VPN tunnel was on the other side of the VPN tunnel, there was no VPN, and the VPN server was just a router joining the two subnets.

Re: WireGuard is submitted for Linux kernel inclusion

#139

Post by tialaramex »

Hello71 wrote: post #86
tssva wrote: post #57

Earlier quoted context omitted.

This is certainly not true. Tunneling and VPN protocols have distinct characteristics and capabilities which greatly affect network design. The reason for this is that they are not all designed to accomplish the same objective.

Only if you're using the ridiculous IPsec protocol and its ridiculous modes. Nobody actually needs a mode that authenticates the header but doesn't encrypt it, and nobody can understand this mode anyways. Nobody needs ECB or 3DES or any of the other zillions of IPsec methods. The great thing about WireGuard is that it removes all the crap and has one mode: Fast and Secure.

The slightly dated TLS 1.3 talk from Rescorla talks about this briefly, this is not a situation with easy answers and the approach taken in WG, which is also the approach in TLS 1.3, may yet turn out to be a bad idea. In TLS 1.3 they have left themselves a fire exit they can run out of, hair ablaze, but it's not clear to me whether WG has a way out.

From an API point of view, "Fast and secure" sounds pretty good. It maybe infantalizes the Software Engineer, which we're not really ready for yet‡, but we get more ready all the time, so I'll let that go. It's certainly better than "No real security unless you're an expert" which was historically what such APIs tend to offer.

On the implementation side "fast and secure" is just a wish, not a fact. Individual elements, picked for being "fast and secure" may turn out not to be as fast as we'd like on tomorrow's hardware, or they may not turn to be as "secure" as we'd have liked. IPsec's Chinese Menu approach lets the software engineer pick something else, but WG's approach doesn't permit this. So, the entire protocol must perhaps be re-designed.

‡ Twenty years ago, we had no good "This just works" answers for a great many things software engineers expect from cryptography. Today we have good answers for many of them, e.g. AEAD modes for block ciphers do roughly what a non-expert software engineer foolishly thought the encryption did anyway. But for others we're still in the dark. Padding for example. For privacy we should pad lengths to hide the true nature of the data being transferred. But... how much should we pad? Today our answer is that hopefully the software engineer using the API knows. In almost all cases they do not.

Re: WireGuard is submitted for Linux kernel inclusion

#140

Post by y4mi »

swsieber wrote: post #69

So, since lots of people here have experience with VPN, I'd like to ask theoretical project question: I have distant family memebers, and it'd be nice to have a simple way to get devices on the same network easily. My initial thought would be to setup a VPN server somewhere central and fast, and then distribute wireless routers with custom firmware that they could plugin to their network. Then anything they connect t…

Its doable and is called a site-to-site VPN.

There a various options to implement VPNs and each has its own problem

--

a) The option everyone else here tries to tell you about is a Client-to-Site VPN. Its downsite is that you'll need to connect each client separately and the VPN isn't entirely 'transparent' (the client and programs can and do know that they're not directly connected to the internet)

your performance will suffer unless your VPN server has enough upstream to offset the combined downstream of all connecting clients. You can offset this by manually routing all internet traffic along the normal gateway and just use the VPN for inhouse connections.

  ie.
  192.168.111.0/24 (vpn) gateway 192.168.111.1 (VPN HOST)
  0.0.0.0/0 192.168.0.1 (Router)
--

b) a true Site-To-Site VPN is possible with enterprise routers. You'll probably have to define static route across all routers as routing protocols will probably add more maintenance than they'll prevent. Each has to be manually added on all routers but remote management is generally possible at that price point. Expect at least $300 for the very cheapest router, and you'll probably want to spent at least $500 per device.

The VPN is entirely transparent and at that price point, you'll be able to configure the routers remotely. Management won't be as big as a problem as you'd expect, as these devices are very stable.

  i.e.
  house a 192.168.111.0/24
  house b 192.168.112.0/24
  house c 192.168.113.0/24
What you were probably hoping for was to get a cheapish router, flash DD-WRT or similar and just use that? if so, i don't believe thats viable. they just don't have the CPUs power to handle this amount of package inspection (its probably using IPSEC, so each IP Package should be flagged and needs to be validated separately)

--

c) ISPs can provide you with a network across sites. Expect to pay thousands though. really good performance however

--

d) client-client VPNs. Zero Tier is one of these. Each client needs to install a software and all communications are directly addressed.

You don't need a central server anymore (still have one for initial authentication however). You'll however have to force people to

1. install the software,

2. start the software,

3. update the software. You probably don't want to do that with family members though. Its very ... annoying

performance is pretty great and you can actually buy appliances which give you the same Site-To-Site capabilities. Beautiful technology which is just as expensive as the enterprise routers. No idea about managing them however. Never had one of these appliances myself

/edit it might be possible with the edge router? i don't have any experience with that, but it does look like it. https://news.ycombinator.com/item?id=17660518

Post reply on HN