Hacker News Reader

Comment by kube-system | Hacker News Reader

I'm excited for wireguard, but I'm not going to use it in production until the authors advise that it's ready for production.

View on HN

From the most recent wireguard-linux-compat release notes:

https://lists.zx2c4.com/pipermail/wireguard/2020-January/004...

> Please note that until Linux 5.6 is released, this snapshot is a snapshot rather than a secure final release.

In other words, over the next ~10 weeks, Linus' kernel tree and Dave Miller's net.git tree will fill up with nice stabilization patches. At the end of that process, 5.6 will be released. At that time, our backports to older kernels (wireguard-linux-compat) will also become a "1.0". This also lines up with the 20.04 LTS release and such.

Security people are always like that (I love that about them). They freak out if a hash function will now take 50 million years to find a collision on a supercomputer, rather than 345 billion. It's worked flawlessly for me and many others the past year in our production environment.

The fact that Ubuntu is including it, means that it's probably passed a critical mass of early adopters and then is probably seeping into the startup mainstream (as opposed to enterprise that wants 20 valid bells and whistles like authentication, auditing, etc).

The authors say that their current version(s):

> should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software)

I figure they know better than I do.

In ~2 months time Wireguard is reaching 1.0 along with Linux 5.6, I figure it's quite stable already and they say that (as anyone with a sane mind would) to keep their asses safe.

I also use it, and it works, but this tells us nothing about its actual security.

Security people are also subject to fads and fashion just like web developers or indeed any other technical group. Many will endorse the primitives developed for example by Dan Bernstein without understanding anything about how they actually work, or having read and understood papers describing their security. Just because he has some hacker "street cred" (arguably well deserved) as the developer of qmail, etc.

The primitives codesigned/codiscovered by Dan Bernstein have become popular not because of hacker street cred but rather because they are peer reviewed and have good design rationale

This is an extraordinarily weird way to summarize WireGuard's cryptography, which shares primitives with Signal (it's derived from Trevor Perrin's Noise framework) and, while we're at it, TLS 1.3. Bernstein's credibility in cryptography comes from his standing as an academic cryptographer, not as "the developer of qmail".

I'm not remotely a cryptographer. And I'm not saying there is anything wrong with his algos obviously. But I remember when the algos designed by Bruce Schneier were all the rage, and I think it was similarly based on some sort of guru status. If I look at Bernstein's most cited papers, they are all about performance, aside from what appears to be a survey on post-quantum crypto and what does seem to be like a well-cited paper on AES cache timing attacks.

So my genuine question is: does he really have an unusual academic standing as a cryptographer?

This ranking by citation (which appears to be up-to-date/live) puts him in position 62: https://kodu.ut.ee/~lipmaa/cites/cites.php?data=crypto

Granted, it's just a ranking by citation, and this definitely puts him in the top 100, which is nothing to scoff at, but I'm still wondering if there is a similar effect, and if in ten years we won't be using algos all written by some other guy because he's the new cool kid.

I feel like you've answered your own question.

Ah; maybe, yes :)

Not OP. I do not have issues with WireGuard's cryptography.

I do have issues with wireguard's security - things like silently accepting invalid configuration, changing one peer can silently affect another (only avoided via external means), roaming is default enabled and can't be disabled nor can you bind the tunnel to an interface or an ip, nor does it pad packets even the slightest to reduce "meta"data leakage.

Just because the cryptography is (probably) sane, doesn't mean wireguard as a whole is good for all or most use-cases.

I guess you're just left with no VPN software then? If WG isn't suitable for production, then OpenVPN, IPSec & co. definitely aren't.

I can only make informed decisions based on the information I have. I don't have the time or expertise to personally audit every piece of code I use. I have to leverage the available resources and evidence that others have put forward.

And all evidence put forward seems to suggest that all commonly deployed VPN solutions really suck. Do you simply ignore that evidence?

Known weaknesses are actionable. Unknown weaknesses are not.

Known weaknesses such as vast and messy codebases? What's the action there? A full rewrite?

Security is only considered stable after being consumed long enough without holes, so not sure how you're measuring it.

Only out of abundant caution, it seems. I mean, Cloudflare is using it.

The author has specifically said it'll be considered released when it's in the kernel, which makes the parents point kinda mute.

https://grammarist.com/usage/moot-mute/

Cloudflare is not the golden standard for security.

Who is?

OpenBSD

I don't know a lot of serious systems security people who actually believe that. OpenBSD is fine, and smart people work on it, but it's been a long time since the early 2000's.

AFAIK it remains the single most selective platform out there. If a project is included in an OpenBSD release you know it has undergone serious whitebox scrutiny for security issues. I'm not aware of any platform that is quite so pedantic at the source code level.

And yet: https://news.ycombinator.com/item?id=22175431

I've said pretty much all I have to say about this, here:

https://news.ycombinator.com/item?id=7071219

What's the history there?

The protocol yes, but don't they use their own implementation? https://github.com/cloudflare/boringtun

Sure, but the underlying codebase hasn't had a public audit for boringtun or wireguard, so they're both in the same boat.

Cloudflare is also cautioning against using their own implementation in production.

Reply on news.ycombinator.com