Hacker News Reader

Comment by numbsafari | Hacker News Reader

The problem is, in a lot of enterprise environments, you can’t rely on a tool that lists itself as non-production ready, and therefore doesn’t / won’t have CVE, etc.

Scroll to the bottom of the wireguard.com site. It’s right on the tin, so to speak.

I’m very excited for wireguard, but have some empathy for large enterprises on this one.

View on HN

I have a lot of empathy for enterprises on this, and while I don't agree with you about "production-ready" (and don't think Jason Donenfeld does either), I do agree with you about giant insurance companies using WireGuard. They're stuck with horrible commercial VPN appliances. You don't have to be.

The latest release announcement, from Jason Donenfeld, on the wireguard mailing list contains the following:

> Hello,

> A new snapshot, `0.0.20190905`, has been tagged in the git repository.

> Please note that this snapshot is, like the rest of the project at this point in time, experimental, and does not constitute a real release that would be considered secure and bug-free. WireGuard is generally thought to be fairly stable, and most likely will not crash your computer (though it may). However, as this is a pre-release snapshot, it comes with no guarantees, and its security is not yet to be depended on; it is not applicable for CVEs.

> With all that said, if you'd like to test this snapshot out, there are a few relevant changes.

I think he’s being very responsible and transparent here. It’d be great if someone with money and/or skin in the game could help the project undergo an audit...

That's not the latest snapshot.

https://lists.zx2c4.com/pipermail/wireguard/2019-September/0...

You’re right, I was off by one. However, they both contain the same disclaimer, which is also repeated on the wireguard website. It’s not production software, according to its own author, despite being quite stable and based on solid theoretical foundations.

Empathy for a self-inflicted problem? Why?

Because they undergo audits that have arbitrary rules, sometimes making it harder or impossible for them to use tools like wireguard.

This is largely false.

Yes, I know that is the problem, but that doesn't make it any less self-inflicted.

How is having to conform to an audit performed by an external party as required by regulatory agencies or legislation "self-inflicted"?

Regulations (PCI at least) don't prevent you from making your own unaffected COTS VPN server. You may need a FIPS compliant HSM for keying and revocation control but if your a college educated IT professional in an enterprise environment this should be well within your scope.

Of course we all know that's a lie. You could pick 10 random tech executives and none of them would know half the acronyms in this post. Why would they need to? That's why they were paying a vendor. Self inflicted indeed.

For 99% percentage of all setups involving tunnels like this, key revocation (ala OCSP) is a security risk, not a solution. If your standard blindly requires or encourages this, what it's in effect encouraging is a much more complex and hard to audit set up that can much more easily include human error. As in, I've actually seen that happen. It's just waaaay to easy to have somebody, somewhere screw it up. Worse, you probably don't have full access to every agent in communication network like that, and if only one party messes it up...

So sure, if you're running a public service with all kinds of semi-anonymous users that have no preexisting side-channel, then you may really need all that infrastructure. But guess what? Most problems aren't like that. If you're just setting up a secure channel between a small set of known-in-advance actors then leverage that simplicity! You probably already have some pubkey based channel between them, so you don't need another one!

KISS. You should probably be using a shared token, not an asymmetric key, and definitely no revocation... if your system is simple enough to get away with that.

PCI is really rather “good” as far as external auditing bodies go, they give broad guidelines on the kind of policies they expect and it’s up to you to implement policies that make sense and they only seem to care about ensuring access controls and heavy amounts of auditing.

HIPPA however...

You have it backwards. PCI is prescriptive about specific ways you have to implement security, including certain requirements that make very little sense. HIPAA gives broad guidelines and you have flexibility as to how to meet those requirements. You can use a more prescriptive framework such as HITRUST to meet the HIPAA requirements, but you don't have to.

I do not often hear people describe PCI as "rather good", for what it's worth. "An industry scourge" is a more common sentiment.

They could push back instead of rolling over. You don't usually even need to question the law, just your auditors -- the phrasing of the law is often something that provides adequate provision for reasonable action. If your auditors are unreasonable, fire them.

He just explained it.

To add on to his points, there are often times corporate policies (You can argue the legitimacy of them or not) that absolutely mandate that you cannot run beta/non-fully released software in production.

One of the last places I worked last ensured that all of our firewall's (and other appliances I'm assuming, they were not my areas though) were an update or two behind (assuming no security vulnerabilities were identified) to ensure stability.

Reply on news.ycombinator.com