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

WireGuard Gives Linux a Faster, More Secure VPN

wired.com

Post reply on HN
Print view View original

231–240 of 306 posts

Re: WireGuard Gives Linux a Faster, More Secure VPN

#231

Post by [deleted] »

tptacek wrote: post #228
wahern wrote: post #215

Earlier quoted context omitted.

Yet Web PKI trounces all of them combined. Signal isn't an apposite comparison as Signal implements key signing and key exchange with Signal as the sole certificate authority. Who do you think attests to the authenticity of phone numbers, and how do you think they do so? Indeed, Signal exemplifies exactly what I was saying: key management is crucial, key management is hard. Secure, trusted key management is like 90%…

Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point. The Web PKI is something we live with because we have to, not something anyone sets out to re-create. There are organizations that benefit from a PKI-ier deployment of SSH, but even there, the "I" part of the PKI is extremely attenuated, and most of the real interesting work is done by a single centralized p…

[deleted]

Re: WireGuard Gives Linux a Faster, More Secure VPN

#232

Post by wahern »

tptacek wrote: post #228
wahern wrote: post #215

Earlier quoted context omitted.

Yet Web PKI trounces all of them combined. Signal isn't an apposite comparison as Signal implements key signing and key exchange with Signal as the sole certificate authority. Who do you think attests to the authenticity of phone numbers, and how do you think they do so? Indeed, Signal exemplifies exactly what I was saying: key management is crucial, key management is hard. Secure, trusted key management is like 90%…

Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point. The Web PKI is something we live with because we have to, not something anyone sets out to re-create. There are organizations that benefit from a PKI-ier deployment of SSH, but even there, the "I" part of the PKI is extremely attenuated, and most of the real interesting work is done by a single centralized p…

> Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point.

I assume then that you exchange the public keys of your Signal contacts over SMS. Over perhaps you scp them to a server you share with friends.

> The Web PKI is something we live with because we have to, not something anyone sets out to re-create.

We have to because it's crucial. If public key attestation didn't matter we would have dispensed with the lock icon and "this certificate is untrusted" popups rather than laud the emergence of Let's Encrypt and the ACME protocol.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#233

Post by Hello71 »

wahern wrote: post #203
Avamander wrote: post #189

Earlier quoted context omitted.

> on OpenBSD is a single line Nice, but it would be nice to know if that is the default or not on Linux as well. I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME. I really hated the PKI on Linux, especially when trying to revoke old keys than on Wireguard. The fact that clients also differed heavily in what they supported was also v…

> Nice, but it would be nice to know if that is the default or not on Linux as well. It's because OpenBSD uses a much nicer, more declarative configuration file syntax, whereas the options on Linux, like Openswan, use a less expressive key-value syntax. To be fair, AFAIU Openswan supports more IKE extensions, and is an older project with more baggage than OpenIKEd or OpenBSD's ipsecctl configuration compiler front-en…

> The SLoC of IPSec kernel code are comparable to the SLoC for WireGuard kernel code.

I haven't checked whether this is true, but even if it is, that's a damning indictment of IPsec, because on Linux, the entire connection establishment is in userspace, and the kernel only handles per-packet encryption and authentication. WireGuard has the entire negotiation sequence, authentication, routing, timeouts, rekeying, etc in the kernel. With IPsec, you need to have a userspace daemon to manage all of that, with significantly more LoC than the bare per-packet essentials. With WireGuard, you just load the keys into the kernel and you're done. I bet that you're also counting Zinc against WireGuard, but not counting the entire crypto API against IPsec (which, unlike with WireGuard, you might end up actually using).

I suspect that it's not actually true though in the first place, once you add in all of the other stuff like iptables -m policy that only exists to support IPsec.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#234

Post by tptacek »

wahern wrote: post #232
tptacek wrote: post #228

Earlier quoted context omitted.

Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point. The Web PKI is something we live with because we have to, not something anyone sets out to re-create. There are organizations that benefit from a PKI-ier deployment of SSH, but even there, the "I" part of the PKI is extremely attenuated, and most of the real interesting work is done by a single centralized p…

> Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point. I assume then that you exchange the public keys of your Signal contacts over SMS. Over perhaps you scp them to a server you share with friends. > The Web PKI is something we live with because we have to, not something anyone sets out to re-create. We have to because it's crucial. If public key attestation…

This is responsive to essentially nothing I wrote.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#235

Post by MayeulC »

tosh wrote: post #124

I think Tailscale [1] can be to WireGuard what Github and Gitlab are to git. If you haven’t checked them out yet: worth taking a look! [1] https://tailscale.com

Yggdrasil and GNUnet seem like more interesting alternatives to me (with cjdns and hyperboria as cousins). Although these do not build on wireguard, they employ the same basic stack (plus some to handle a mesh topology).

Re: WireGuard Gives Linux a Faster, More Secure VPN

#236

Post by ecnahc515 »

atmosx wrote: post #138
ecnahc515 wrote: post #123

Earlier quoted context omitted.

If you want SSO, or fine grained access control, the idea is you would do that at a level above wireguard. For example, I'm prototyping a small CLI that talks to hashicorp vault via OIDC/OAuth2, and then creates a wireguard key pair + configuration locally, submits the public key to vault, and then the wireguard "server" is configured with a simple daemon that pulls all the public keys from vault and generates a wire…

Are you going to open source it?

If it gets anywhere yes, I've been a bit busy with life and it's been in a pause. The other aspect is this isn't super useful yet because I still need to implement the server side, as well as figure out how to make this useful as non-CLI for my mobile clients (iOS), which are the majority of what I use the VPN for.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#237

Post by AceJohnny2 »

api wrote: post #230
AceJohnny2 wrote: post #227

Earlier quoted context omitted.

and how can they tell?

MACs are computed directly from cryptographic hashes. For normal ZeroTier P2P traffic the MAC and Ethernet header are elided entirely too, which saves about 14 bytes of per-frame overhead.

Wait, are we talking about MAC as in cryptographic Message Authentication Code, or MAC as in ethernet Medium Access Control (addresses)?

Re: WireGuard Gives Linux a Faster, More Secure VPN

#238

Post by ryanlol »

wmf wrote: post #221
ryanlol wrote: post #209

Earlier quoted context omitted.

What tooling do you need for this? Shell scripts would be the traditional approach.

Yeah, as long as the shell script has been audited. It would probably be easy to accidentally send the GRE traffic in the clear instead of through WireGuard.

Doesn’t seem that easy to fuck up, you just use internal WG IPs for the L2 tunnel. Packets just won’t go anywhere if WG is down.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#239

Post by prutschman »

v0tary wrote: post #149
jbverschoor wrote: post #143

Earlier quoted context omitted.

Zerotier does a perfect job ..

I disagree - spent a considerable amount of time with zerotier as a possible replacement of a small sized ipsec mesh (4 sites) and it failed horribly. Had commercial support, different hardware and even virtualized it. Latency was a major issue and quality of the links were erratic to say the least. Don't get me wrong, I think zerotier is great, but it's not prime time.

I've had a similar experience. In particular links will just "drop out" for periods of time. The public forwarding nodes were overburdened for quite a while. I set up my own "moon", but one of the sites has a cranky NAT, which will let a connection through for a while, then fail. It seems to take at least 30 seconds for zerotier to "notice" this and switch back to forwarding via the moon. Maybe the new multipath will help?

Re: WireGuard Gives Linux a Faster, More Secure VPN

#240

Post by BlueTemplar »

lapinot wrote: post #142

I really like wireguard, but one thing that bugs me is the fact that it's layer 3 (an ip tunnel) and has no code to support layer 2 (ethernet MAC tunnel). The downside for me is that you have to manage static ips in the configurations (specifically it's not compatible with ipv6 slaac and NDP). There is https://git.zx2c4.com/wg-dynamic but it's very experimental at the moment. The level 3-only tunnel is motivated as "…

Hmm, but MACs (and Ethernet?) are on their way out with IPv6, replaced by specifically software-set GUIDs ?
Post reply on HN