Hacker News Reader

Hacker News

Comment by Nelkins | Hacker News Reader

Parent Full thread

Nelkins

From the WireGuard website[0]:

> WireGuard is not yet complete. You should not rely on this code.

So...should we not rely on this code?

[0] https://www.wireguard.com/#about-the-project

View on HN

WireGuard is likely going to be merged into Linux kernel[1]. And it's already supported by latest Systemd 237[2].

If you're comfortable with beta/dev software versions, or using ArchLinux/Debian Sid/other distro with the latest software—there's no reason not to rely on WireGuard today. Otherwise, wait until it arrives at your system, being built into the mainline kernel. Also, I would like it to get audited by independent third-party.

[1] https://www.phoronix.com/scan.php?page=news_item&px=WireGuar...

[2] https://www.phoronix.com/scan.php?page=news_item&px=systemd-...

It's reasonable to want to see an audit report but bear in mind:

1. There aren't many audit firms qualified to do that audit, and only a subset of the people at most of the qualified firms are themselves qualified.

2. As a result, none of WireGuard's competition has been meaningfully audited --- all of them have been audited, but the projects are pretty much seen as a well that we can keep going back to for more bugs.

The only exception to that rule is probably OpenSSH, which despite the very complex code base has received pretty significant coverage --- not so much from formal audits (it's had some, but they're the same kind as I just described above) but from a decade of close scrutiny.

Against the desire for an audit, I'd also bank:

- The author is a Linux kernel vuln researcher

- The codebase is deliberately tiny

- The protocol was streamlined specifically to make it possible to implement as simply as it was

> 1. There aren't many audit firms qualified to do that audit, and only a subset of the people at most of the qualified firms are themselves qualified.

I know of one (and we're hosting the dude who wrote the Wireguard go implementation this summer (hey Mathias))

I'd rely on this code before I relied on literally any other VPN codebase. Jason should change the wording here, which I think might be old. Like I said: the protocol just got a set of formal proofs, in addition to the Tamarin prover work Jason did for it.

Just because the protocol has a formal set of proofs, doesn't mean it's production ready. The very fact that the only releases are snapshots and not eligible for CVE's makes me weary of utilizing this in a non-testing environment.

"Not eligible for CVEs" means absolutely nothing.

But how does a set of proofs let you know that it's not going to cause a kernel panic or stop forwarding traffic in edge-cases that aren't well-tested (e.g. lossy and/or high-latency links).

I should change the wording there indeed. It's a bit drastic.

If you have nation-states for enemies, probably not. For most other uses, I'd say give it a try (I am typing this over a Wireguard connection right now, to a Streisand[1] vm at DO).

1: https://github.com/StreisandEffect/streisand

For me, it'd be almost the reverse: state-level adversaries almost certainly have remotes for strongSwan and OpenVPN, but due to its design, it's unlikely that they do for WireGuard.

Good point, though presumably the more it succeeds, the more they'll try...

Reply on news.ycombinator.com