4 ms·

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.wireg

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 https://www.wireguard.com/#about-the-project

tptacek 9y ago
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.
- deeebug 9y ago
  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.
  - tptacek 9y ago
    "Not eligible for CVEs" means absolutely nothing.
- pathseeker 9y ago
  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).
- zx2c4 9y ago
  I should change the wording there indeed. It's a bit drastic.
nirv 9y ago
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=WireGuard-2017-Maturing https://www.phoronix.com/scan.php?page=news_item&px=WireGuar... [2] https://www.phoronix.com/scan.php?page=news_item&px=systemd-237-Released https://www.phoronix.com/scan.php?page=news_item&px=systemd-...
- tptacek 9y ago
  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
  - baby 9y ago
    > 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))
blacksmith_tb 9y ago
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 https://github.com/StreisandEffect/streisand
- tptacek 9y ago
  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.
  - blacksmith_tb 9y ago
    Good point, though presumably the more it succeeds, the more they'll try...

tptacek 9y ago

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.

deeebug 9y ago
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.
- tptacek 9y ago
  "Not eligible for CVEs" means absolutely nothing.
pathseeker 9y ago
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).
zx2c4 9y ago
I should change the wording there indeed. It's a bit drastic.

nirv 9y ago

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=WireGuard-2017-Maturing https://www.phoronix.com/scan.php?page=news_item&px=WireGuar... [2] https://www.phoronix.com/scan.php?page=news_item&px=systemd-237-Released https://www.phoronix.com/scan.php?page=news_item&px=systemd-...

tptacek 9y ago
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
- baby 9y ago
  > 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))

blacksmith_tb 9y ago

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 https://github.com/StreisandEffect/streisand

tptacek 9y ago
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.
- blacksmith_tb 9y ago
  Good point, though presumably the more it succeeds, the more they'll try...