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

101–110 of 306 posts

Re: WireGuard Gives Linux a Faster, More Secure VPN

#101

Post by fmajid »

fivesixzero wrote: post #13

Increasingly it seems like heavily opinionated foundational tools and frameworks are overtaking more highly configurable alternatives, at least in terms of breadth of usage or popularity. Could this be a positive change? Does this represent a healthy response cognitive fatigue in a world with configuration options at every possible layer? Or does this shift to less readily configurable tools represent an overall nega…

TLS has shown how the quest for backwards compatibility has the unintended consequence of downgrade attacks. Wireguard's lack of cryptographic agility is a feature, not a bug. Sure, it means everyone has to upgrade when a new version of the protocol comes out, but the entire point of a VPN is security.

That said, OpenBSD's OpenIKEd is just as simple and efficient, and thanks to standard compliance (IPsec, IKEv2 and MOBIKE) it works out of the box with iOS devices.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#102

Post by StreamBright »

nif2ee wrote: post #86
tptacek wrote: post #73

Earlier quoted context omitted.

Last time I talked to him about it, Jason Donenfeld was not upset about Tailscale. You'll have to find someone else to be vicariously outraged for.

Of course I am sure he is extremely happy spending 5 years developing the next big thing then others rebrand it for enterprise and become rich.

This is not how opensource works.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#103

Post by megous »

slim wrote: post #72
slim wrote: post #68

Earlier quoted context omitted.

there is no authentication that would need a second factor in wireguard. in wireguard you authenticate the host, not a user

actually there is no athentication in wireguard. only identification

Each node has a list of public keys of nodes that it authorizes to communicate with it. Those nodes authenticate (provide proof of their identity) themselves via the exclusive ownership of their private keys.

So I don't see yout point.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#104

Post by kova12 »

zoonosis wrote: post #97
lbeltrame wrote: post #62

Earlier quoted context omitted.

Versions >= 1.20 have support for all the bits and pieces (including routing all traffic). Initial support landed in 1.18.

If that is the case, it looks like Ubuntu 19.10 and later have support. https://packages.ubuntu.com/search?keywords=network-manager&...

if it does, I don't see "how"

Re: WireGuard Gives Linux a Faster, More Secure VPN

#105

Post by dave_universetf »

radlad wrote: post #12
ahnick wrote: post #7

Earlier quoted context omitted.

Tailscale looks promising. ( https://tailscale.com/ )

I was impressed how quickly I could go from 0 to VLAN with Tailscale on Windows. Unfortunately I did not have as nice of an experience with the AUR package on Arch. However, it looks like the maintainer replied with a link to instructions on their website with how to get it working!

AUR package maintainer here (also tailscale employee). The poor experience was definitely on me. Relaynode's initial setup flow is a bit weird, and I didn't make the package explain anything. I think you were the first user of the Arch package other than me, so you got to experience the fun :)

Next release will have a better daemon, with a more typical setup flow. If you want to test drive it, `tailscale-unstable-bin` is the AUR package for it.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#106

Post by Hello71 »

Sesse__ wrote: post #50
293984j29384 wrote: post #33

What makes Wireguard more secure? The article appears to make some weak claims about a smaller codebase and less configuration options but I don't think that translate directly into it being more secure?

The main idea (which has a fair amount of merit!) seems to be: If you give people too many knobs, they will invariably get confused and turn them the wrong way, creating an insecure configuration. E.g., IPsec has a “none” cipher!

the "none" cipher isn't even that bad... if you do a packet capture, you can clearly see that the data is unencrypted. the worst part about IPsec is that there are many modes which look secure, but actually aren't secure at all. examples: encrypted but unauthenticated packets, encrypted but unauthenticated channel negotiation, encrypted by default but downgradable cipher negotiation...

Re: WireGuard Gives Linux a Faster, More Secure VPN

#108

Post by megous »

q3k wrote: post #69
0xbadcafebee wrote: post #60

What I don't like about WireGuard: - Basically no real user or admin-oriented docs. There's some example configs and some getting started guides, and then some crypto-nerd look-how-secure-our-algorithms-are docs, but no real guidance on how to set up a reasonably simple network of hosts. - Authentication/authorization is just IP addresses and public keys? What about users and service accounts that you want to rotate…

Very much agreed. While for simple use cases static keys are more than fine, a proper PKI is basically the only sane way to deploy a VPN in an enterprise or even small company setting.

What do you mean by static keys? All keys are changeable at runtime and wireguard uses public key cryptography.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#110

Post by tptacek »

upofadown wrote: post #81
fivesixzero wrote: post #13

Increasingly it seems like heavily opinionated foundational tools and frameworks are overtaking more highly configurable alternatives, at least in terms of breadth of usage or popularity. Could this be a positive change? Does this represent a healthy response cognitive fatigue in a world with configuration options at every possible layer? Or does this shift to less readily configurable tools represent an overall nega…

Opinionated is great as long as it allows for future backwards compatibility. This sort of thing is critical for things like this that depend on cryptography. There has to be a way to support the old thing at the same time as the new thing when it looks like the old thing might eventually have to be swapped out. There has to be a way to do the transition.

This is the opposite of what cryptography engineers believe today.
Post reply on HN