Vulnerabilities exploited in VPN products used worldwide | Hacker News Reader

Vulnerabilities exploited in VPN products used worldwide

ncsc.gov.uk

233 pointsinfodocket133 comments

Commercial enterprise VPN products are an open sewer, and there aren't any, from any vendor, that I trust. I don't like OpenVPN or strongSwan, but you'd be better off with either of them than you would be with a commercial VPN appliance. The gold standard, as ever, is Wireguard.

Why do you prefer Wireguard over Openvpn?

Wireguard is an extremely simple protocol, basically as simple as it is possible for an encrypted VPN protocol to be.

OpenVPN uses TLS (in TCP mode) and a custom protocol based off of TLS in UDP mode, its design is vastly over complicated by the use of x.509 certificates, and in general is just kind of ugly and kludgy (and slow).

It's "simple" in a way that is very difficult to achieve, and in many ways more modern than OpenVPN. The better word might be "clean".

There's also a formal proof of Wireguard's security (not that it means much in practice, but I find it extremely interesting): https://prosecco.gforge.inria.fr/personal/bblanche/publicati...

I spent over two days setting up OpenVPN the first time I used it and less than an hour the first time I set up Wireguard. Wg seems a bit more reliable too, sometimes my OpenVPN sessions would time out and require manual intervention, but since switching to wireguard it always seems to "just work".

Others pointed this out already, but I'd like to second the simplicity. It's much, much easier to set up wireguard, especially compared to the mess that is openvpn. I had to use algo to set up openvpn originally, and God help you if you're not on ubuntu.

Secondly, wireguard is faster. If you're dealing with lots of users, CPU could be limited; in such environments, wireguard has allowed me up to fifty percent more throughput than with openvpn. It's also newer and probably not as optimized, so may get better. Finally, the new tap/tun driver on windows is orders of magnitude better than the openvpn one.

Wireguard codebase is tiny at it has been reviewed by a lot of skilled eyeballs.

> it has been reviewed by a lot of skilled eyeballs.

Any details on this?

It's probably better than the mess of other code bases, but wireguard is in active development, so even if secure and bug-free a few months ago, it would not necessarily imply secure now.

Old thread, but I also really appreciate the simplicity. Configuring wireguard takes a little knowledge of routing (either iptables or firewalld, etc) but is vastly simpler to understand compared to OpenVPN. When things aren't working, there's a lot fewer thing to check.

Oh and it's blazing fast. I often times get better connection speeds when connected to the wireguard VPN than not, presumably because the TCP overhead all happens in the cloud rather than locally where latencies are much higher and bandwidth is more limited.

The roaming of Wireguard also makes it completely seamless. I'll often forget I'm even connected for days at a time.

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.

Empathy for a self-inflicted problem? Why?

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.

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

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"?

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.

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.

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

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

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.

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.

This is largely false.

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.

Lots of loose language in your post.

Show me a FIPS140-2 Wireguard implementation.

I could be wrong, but it’s superseded by FIPS140-3.

Anyway, compliance doesn’t necessarily imply security.

Unless you are purposely trying to pedantic, one should know that FIPS140-3 just came out. You can't even search the Cryptographic Module Validation Program (CMVP) tool for FIPS140-3 standard level yet. FIPS140-2 for all practical purposes is the current standard to measure against.

And if you really are negating FIPS140-X and what it means to large organizations and government entities... you should do some reading to understand why it exists. It isn't standards hand-waving. It is fairly in-depth and aims to ensure your cryptographic primitives and low level operations are not totally fucked out of the box.

It doesn't solve most security issues by a long shot, but it does try to give you some minimum levels of assurance that it doesn't totally suck crypto operations-wise.

Anyways - I up-voted your reply regardless because I wanted to engage in some meaningful dialogue, and I believe we have. Cheers!

It is great that FIPS140-3 has finally become effective. The previous standard, was getting long in the tooth (FIPS140-2)...

That post yesterday : https://news.ycombinator.com/item?id=21147865 shows a side channel attack on smartcards. In the links we can see the FIPS140-compliant affected hardwares. Maybe it contributes to show that FIPS140-02 is not as much a reference than it used to be?

I mean this seriously and have chosen these words carefully: FIPS can shove its entire self up its own ass.

There is maybe nothing in the industry that has done more damage to cryptographic security than government cryptography standards.

Unfortunately, if you sell crypto software to the defence sector in the US or Europe, FIPS is still a thing.

As someone in the infosec space, it still boggles my mind that anyone gives a flying feck about FIPS, especially after the Snowden/NIST revelations, and after even Microsoft has recommended to disable FIPS mode in Windows.

Thankfully I think it's on it's last legs - people are realising it's more a curse than a blessing. Single data point and all that, but I've had far fewer FIPS-related queries in recent years - and for the first time, some of those I have had are from defence sector companies asking how to ensure FIPS mode is not activated!

I'd encourage the WireGuard devs to not waste any time and money on FIPS validation.

What do you think about cloudflare's vpn offerings? 1.1.1.1 and cf access?

I don't know about them really but Cloudflare Warp is using the Wireguard protocol.

My opinion is that Cloud Flare forked WireGuard, taking Jason Donenfeld's design work without compensation or, from what I can tell, even a sincere thank-you, and built something from it that isn't fully compatible with WireGuard itself. I hope someone else builds a real Rust WireGuard and crushes them with it.

> taking Jason Donenfeld's design work without compensation

That's the risk with open-source work though, isn't it?

I'm not saying Cloud Flare committed a crime.

There's nothing in the GPL about compensation or saying thanks. This is part and parcel of licensing your software in a way that respects user freedom.

Also, I doubt Cloudflare forked WG, because 1) that could very well violate the terms of GPLv2 if they don't make the source available (at the very least, the client source code which utilises code lifted from WG would have to be open source), and 2) their offerings don't seem to be as good or as fast as WG, but YMMV.

"There's nothing in the GPL about compensation or saying thanks."

Thank you. I think you may be helping me wrap my head around the notion of "cultural appropriation".

One of my besties beats me over the head with all sorts of things that I'm supposed to be upset about.

One example, we were looking at an art display with a bunch of those origami cranes. I quite liked it. Which is apparently the wrong answer. Because the artist is not Japanese. So that's cultural appropriation.

Here I've been thinking learning from each other, gleaning the best ideas, and putting one's own spin on it is the whole point.

But as a former publisher of my own shareware and public domain stuff, who was widely plagiarized, I do kinda get that lack of attribution, even a nod of the head in the general direction of the original works, feels rude somehow.

To wrap up, I'm now going to reread the GPLs, CC, BSD licenses, thru a lens of cultural appropriation, see if any of it makes more sense to me.

Thanks.

I'm not accusing Cloud Flare of violating the GPL.

If you’re not saying that Cloudflare has done anything wrong or illegal, then I don’t get the point of what you’re saying. What are you trying to say?

The GP is saying Cloudflare did something ethicaly wrong, but not illegal.

Wireguard isn't even stable yet - it's not even been mainlined by the Kernel which is one of the main selling points that it will eventually be included.

It's alpha level software at this point and should not be relied upon or even trusted.

I've been using it for almost a year with literally zero issues. The closes to a problem was the lack of a windows client (though there was a third-party option a used for a while), which is now fixed. If this is alpha-quality software, I look forward to seeing like what the beta and release versions look.

I'm also using it, but the reality is that the Wireguard team states it's not production ready for good reason. If your threat model includes state level actors or you are a high value target to sophisticated cracking groups, I wouldn't use wireguard yet.

A lot of cryptographic protocols have come and gone, once thought secure. And 10-100x as many implementations of a specific protocol have fallen to mistakes, even built on secure protocols.

That said, if your threat model consists of relatively low level threats, like blocking your ISP from spying on you to sell your info to advertisers, I'd highly recommend wireguard. It works really fast and well.

I don't think you'll find a lot of software or cryptographic security engineers who would tell you that you'd be more secure using OpenVPN or strongSwan instead of WireGuard, since the reverse thing is actually true.

Do you know anyone who can say specifically what kind of security wireguard provides? Not the NoiseIK Wireguard IKE protocol proven secure stuff¹, but in practice, what can it be relied on to prevent and what does it not prevent?

For example, copying ECN bits was documented only after I bugged Jason about it. In the whitepaper it is mentioned 0 times.

I tried asking on the mailing list, but got nowhere.

¹ The protocol is the foundation. But just because an idealized part is proven secure under some assumptions, doesn't mean the whole is secure, implemented as described or suitable for a particular purpose.

> Commercial enterprise VPN products are an open sewer,

Commercial enterprise VPN products exist for one reason:

To allow the enterprise security office to tick off the checkbox on the quarterly compliance forms that essentially says: "using a VPN to provide secure communications".

Security is only a secondary consideration, if it is even considered at all.

Honestly, isn’t 90% of compliance like that? Checking boxes...

The thing is, people are very good at checking boxes, and not very good at remembering important things.

So while it may seem inane, plain old checking boxes is almost certainly part of a good strategy for dealing with tedious, repetitive tasks where one error can cause serious issues - and this kind of security is probably one of those.

Obviously, it's not enough, nor an excuse to turn off your brain - but it's a pretty proven behavioral pattern.

Sure I mean it’s a lot of CYA regulation-wise. Because if you chose a solution which is arguably better but not part of the list and the one on the list which is a worse solution isn’t checked, well you’d better have your resume ready when something happens.

Flying is a great example of 'checking boxes' saving lives.

Having worked a lot with security compliance, I'll say there are two types of things you do:

1. The things for compliance.

2. The things for security.

Only rarely does something fit in both categories.

From my experience corporate VPNs exist to allow employees to access internal resources remotely. They aren't typically used for security although they can provide some form of security for remote workers.

Of course they're used for security -- VPNs are a hassle for users and admins, it'd be easier for everyone (except security!) if all internal apps were just public on the internet.

VPNs are a band-aid / work-around for "we don't have strong authentication and authorization on all services". That's fine, not everyone can do the latter, and they can provide some safety v.s. the anonymous attacker case. But too often they lure IT environments into a false sense of security.

You're ignoring the reality that most enterprise software is a tire fire (from a security standpoint) and that it's not feasible to secure hundreds (or even dozens!) of enterprise apps.

VPN's are the enabler that ensures status quo remains.

Can you propose an alternative solution?

I agree — band-aids aren't per-se a bad thing. However, a VPN isn't the ideal end state. Even if you can't modify the underlying application, the goal should be "wrap in a reverse-proxy that handles authn / some-amount-of-authz so you can minimise the risk".

VPNs handle network security, but don't protect you against an attacker able to compromise an endpoint in your corporate environment.

Some protocols/services are designed with a local network in mind and would require modifications to work on the internet. A VPN is invisible to the apps and can easily save a lot of work in a large IT environment with numerous internal services.

How is a local network different from the internet, presuming there is no firewall or nat between the client and the server ?

On a local network, you make the assumption that there are only authorized users.

Uh oh, that assumption is a big no no.

depends

Can you elaborate? Honestly asking.

I wouldn't recommend it with PCs, notebooks, phones, random crapware, but:

When you control¹ all the devices on the network, the network is small enough and the danger from the non-authenticated protocols isn't too high, then I would say it is reasonable to assume being present in the network is sufficient authentication. Not saying it could not be improved, but there are probably many more pressing concerns.

¹ you don't fully control anything anymore, but you're not going to fix that either.

Thanks a lot. That gave some perspective. I'll keep that in mind.

The air gapped power plant networks I work on have unused Ethernet ports shut off and the ones in use only accept traffic from the MAC address of the device that is meant to be there. So you can’t just show up and plug in.

> presuming there is no firewall or nat between the client and the server

That's one of the issues though. If you can't access a machine via its internal IP, many useful usage patterns break.

Someone complained that the issue is that services aren't secure, but there's more to it than that: good security depends on defense in depth, and firewalls are an important part of that.

You're probably alluding to things like PXE or mDNS, or some proprietary industrial control protocols? This is true but deploying a VPN to cover them is a pretty high price to pay in operational complexity and security cost. There's usually other ways to address the task at hand.

Yep, using VPNs makes the organisation lazy in security. But insecure apps in a "company internal network" is still not ok IMO. In the exceptional cases that you can't fix, the way to go is separate dedicated environments for the risky apps, and disconnected from central services.

>The gold standard, as ever, is Wireguard.

Not disagreeing with you about the state of commercial VPN products, but regarding WG specifically. Something I don't see in the other replies just yet is that Wireguard doesn't yet have an ecosystem around it, but is designed for that in a good way. By which I mean, it follows the Unix philosophy of focusing on one specific task and doing it very well, and it has succeeded in that admirably even at its early stage of development. And long term I think that will result in better, more secure and more reliable solutions. But in the immediate term solutions/ecosystems around it don't exist and I think that makes for legitimate scalability problems for anyone who doesn't want to roll their own infrastructure. It very explicitly doesn't want to deal with integrating with key management/HSMs/AD policies/whatever. Eventually WG itself will be used along with those, and there will be nice GUIs on it, and so on. Hopefully it'll simply become the standard for VPN products to rely upon and the world will be a better place for it.

But in these early days it can't slot in everywhere because it's not even meant to. That'll take more time, maybe kernel mainlining (maybe after the WG port to the crypto API Jason announced last week?) and integration with the *BSDs. It's still in a fairly significant growth phase.

> It very explicitly doesn't want to deal with integrating with key management/HSMs/AD policies/whatever.

If you look at the list of vulnerabilities, they're all precisely in those parts of the stack that Wireguard doesn't address.

So what value is Wireguard providing, exactly? It's a beautiful protocol, but security isn't a beauty contest. It's easy to create a beautiful solution when you avoid dealing with the difficult problems.

>If you look at the list of vulnerabilities

If you look at THIS list of vulnerabilities, sure. That's not an exhaustive list of every problem standard VPNs have had though, you understand that right?

>So what value is Wireguard providing, exactly?

Even ignoring vulnerabilities entirely, OpenVPN and the like are full of footguns and are very, very easy to fuck yourself with. You talk about the value of practicality and solutions, which is very true, and that's just the point. One of the core aspects of modern security practice is making it hard to fuck up, the few knobs and dials the better. For example, older protocols still have obsolete awful crypto options that you shouldn't use, but precisely because they exist as choices at all you have to worry about misconfiguration or classes of issues like downgrade attacks. There are plenty more, like if you remember back during Logjam, tons of SSH/VPN/HTTPS servers were using identical prime numbers for Diffie-Hellman key exchange.

WG aims to be a better foundation for the VPN component of things. Contrary to your assertion, the problem it deals with isn't trivial and does matter. Having something that is focused on that rather then part of a gigantic blob makes it easier to verify, and also makes whatever auth and other systems it's ultimately tied into easier to verify. Also just plain lower overhead.

I mean, I'm barely touching on things here but there are good reasons a lot of people are enthusiastic about its potential.

I'm not defending SSL-based VPN servers. They exist because people didn't understand how IPSec IKE worked or want to put in the effort to make it work better, and as is typical in the industry worse-is-better won the day.

But the value those SSL-based and similar bespoke VPN servers brought was automated key management, end-user based authentication, route setup, etc. They've done so horribly in terms of correctness and security, but nonetheless in a way that companies value.

Yes, Wireguard avoids all the pitfalls of the transport security. But so do the crappy SSL-based solutions, because they also have the benefit of hindsight.

What's the practical value of Wireguard over IPSec? AFAICT, it has marginally better NAT traversal; IPSec requires NAT-T (a UDP wrapper) which is marginally more complex. But what's the biggest impediment to IPSec uptake? It's IKE, which is a purely userland service. Most IKE implementations suck. Whatever solutions will be built around Wireguard, they'll ultimately look almost exactly like IKE in terms of their relationship to the in-kernel component--a userland daemon for PKI and/or general user authentication management which does some setup like installing the secret transport key and policy of the otherwise simple in-kernel components. But if those better IKE solutions don't exist (outside of OpenBSD), why would Wireguard magically make them appear?

At best what we'll get (what we are getting, as manifest in every VPN service and open source project announcement) with Wireguard is a recapitulation of the mess we have with SSL VPN products. All the same security issues revolving around horrible key management and poorly written software, all the same incompatibilities and vendor lock in stemming from the diverse "solutions". Except we'll have a beautiful transport layer protocol to soothe ourselves with.

I don't mean to criticize Wireguard. From a low-level engineering perspective it's beyond reproach. My concern is with how it's being received and the fantasies people have about how it will change things. And IMO (which I admit is my opinion--not a hill I'd choose to die on, but something I'd still wager on and orient my plans around) is that long-term security would be better spent by fixing (mostly deprecating old modes) and reinforcing IPSec and IKE, which is already very mature. macOS, iPhone, and Windows have mature IKEv2 support. Linux, and Android in particular, does not have mature IKEv2 support, at least not out-of-the-box. Implementations like FreeS/WAN are too complex and have too many pitfalls, which is why startups either avoid it or flounder in their attempts to build on it. If I could order open source engineers around, I'd order them to improve IKEv2 support. Why? Because IKEv2 addresses in a reasonable fashion 80% of the things that compromise the value-add of commercial VPN products. That last 20% still leaves maneuvering room for novel key and user management solutions, but without as great a risk of really f'ing things up.

I think the value in WireGuard is that by making things simple enough, you can do the "hard" parts manually, and thus don't need all this fragile machinery around it.

It depends on what you're using a VPN to accomplish. If you're talking about rolling out an enterprise-wide solution that does site-to-site and small branch offices and remote access, I agree: WireGuard isn't there yet (an enterprising security engineer might get it there!).

But most of the VPNs I encounter in my work are not that; rather, they're simple remote access mechanisms, addressing the same problem an SSH tunnel would, but more cleanly. WireGuard is better than the alternatives for these common-case simple remote access VPNs.

Additionally, there are lots of random tasks that you might want to deploy a simple point-to-point VPN to solve (peering, cross-account cloud access, etc) that OpenVPN and strongSwan are just too painful to set up. WireGuard is approximately as easy to set up as an SSH tunnel; the tunnel wants you to map ports, and WireGuard wants IP addresses. I imagine it might see a lot of deployments that legacy VPN protocols won't.

If all of my remote access can be done via ssh {+ local/remote forwarding}, is there a reason for me to consider wireguard?

Yes. WireGuard is cryptographically superior to SSH, attaches at a network layer without fussy interactions with a Unix shell (that then also needs to be accounted for in a security model), has higher performance, is practically bulletproof in terms of keeping connections alive, and gets you direct access to whatever resources you've provisioned the network to provide.

I wouldn't ding someone using SSH tunnels (carefully), but in a de novo design, I would always recommend WireGuard first.

> WireGuard .. is practically bulletproof in terms of keeping connections alive

Try switching between IPv4 and IPv6 networks, or reaching a peer on non-default/primary network on Windows.

Not denying it would usually have better connectivity than TCP based ssh.

Where do you encounter IPv6 in the wild?

There were multiple complaints on the mailing list about roaming not working on IPv4/v6 transitions. I believe it was mobile vs. wifi.

Cellular networks.

Cellular networks abroad.

I've come across it on Wifi hotspots as well for some reason, it felt like the were deployed by a telecom company (cellular being most common way for non tech people to use IPv6 on my sites).

As an anecdotal point, I’ve been using always-on WireGuard (using a setup that’s essentially a fork of Algo) on my iPhone, iPad, and MacBook for months, via the native clients for each. I routinely hop between countries, SIM cards, WiFi networks, etc. I hit issues with Apple’s built-in captive portal detection (which has to kick in so it gives me the captive portal outside of the always-on VPN), but the WireGuard tunnel itself has been pretty much solid.

Wireguard does not have better performance or is faster verses Openvpn in any independent Benchmark released up to now.

Do any independent benchmarks show it to be no faster?

Yeah, but nobody cares. OpenVPN is horribly slow and wireguard isn't, there's no point in comparing these two.

You wouldn't have an independent benchmark comparing a GTR and a semi truck.

Sure there are, many threads about wireguard include performance comparisons to openvpn. Most home routers that can install both see a significant increase (I saw about 3-4x if I remember correctly).

Also see the endless discussions on how to deliver 100 Mbit/s for single connections on OpenVPN. It is absolutely insane, you have to spend many hundreds of dollars on hardware to have a fighting chance. And even if you get hardware acceleration that doesn't help nearly as much as you'd expect. And aside from cost the power consumption required for such hardware is very prohibitive for most.

Meanwhile my phone (first gen. Pixel (so three generations behind)), over wifi, gets at least 60 mbit/s over wireguard to a weak home router and then out to internet.

I was just benchmarking routers in VM. I also tested Openvpn vs Wireguard. Results:

  Openwrt 18.06.4 32-bit
  wireguard: 645 Mbit/s ping 1.1ms
  openvpn: 164 Mbit/s ping 1.2ms

  Openwrt 19 (snapshot r11159) 64-bit:
  wireguard: 1.16 Gbit/s ping 1.1ms
  openvpn: 230 Mbit/s ping 1.2ms

  pfsense 2.4.4-p3 (amd64):
  openvpn: 115 Mbit/s ping 1.2ms

It was tested by moving traffic between two virtual bridges, Debian>router>Debian, on KVM (libvirt), CPU E3-1270, kernel: 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64

1 core, 2GB per VM

iperf3 -t 60

  Settings:
  Wireguard: defaults
  OpenVPN: no compression, udp, tun, defaults

I would also note that I setting wg took about 5-10 minutes while setting openvpn took about an hour.

>> If all of my remote access can be done via ssh {+ local/remote forwarding}..

> WireGuard .. has higher performance ...

Note there are circumstances where ssh port forwarding (-L, -R, -D) is faster than any L2/L3 vpn because it breaks TCP connections in two segments, so any flaky retransmission causing issues are localized, RTTs are smaller, TCP ramp-up is faster, etc.

On the other hand, ssh tun/tap forwarding will almost certainly be slower.

If you are connecting over a flaky wifi/2g/3g connection, possibly to a flaky/distant counterpart, and have performance issues, I would recommend trying (L4 is it?) ssh/socks or even http forwarding via a stable middle host.

Last I checked it did not have a a Windows client, so I'm still using OpenVPN. CLI clients are of course next to useless for Windows users. I would really like to use WG instead.

It does now, and it has a much better UX than OpenVPN.

Tunsafe is there since quite a while.

Some client from WG directly is also in the works.

AnnyConnect from Cisco is ok and I'm pretty sure wiedly audited.

I am sure you have valid crypto concerns, but outside of FUD, is there anything specific you have against, for example, GlobalProtect? Or any particular platform, for that matter?

Problem #1: they are closed source. Good luck verifying their security.

Problem #2: it is in the best interest of nation states to be able to break the VPNs and it's in the best interest of large vendors to quietly cooperate with the government.

If you are worried about your secrets being revealed to a nation state, then chances are you shouldn’t be putting any of them over the public internet - VPN or not.

There is a large amounts of secrets that fall between the two extremes 'not very secret at all' and 'should never be spoken of or touch a digital device'.

Corporate espionage backed by nation state actors is a real thing, and there is nothing wrong with wanting to secure yourself against it while running a normal business.

That's a big strawman.

> I don't like OpenVPN or strongSwan, but you'd be better off with either of them than you would be with a commercial VPN appliance.

How does Streisand compare?

I would avoid Streisand and recommend Algo, which does approximately the same thing, but safer.

WireGaurd keeps getting mentioned as the new alternative to OpenVPN, but it sounds like it isn’t available on a lot of BSD’s and doesn’t have much for GUI’s and the like for configuration.

Why would I want to use WireGaurd compared to something like ZeroTier as a VPN layer? Maybe I’m more of a programmer and the notion of a decent api controller for authentication seems nice.

"Isn't available on a lot of BSDs?" Like a lot of people, I'm running it full-time on macOS, and there are FreeBSD and OpenBSD ports.

That’s good to know. I’m going off some other comments which made it sound like it’s not available on BSD’s.

It seemed strange BSD’s wouldn’t be available but I know little about WireGaurd and a little curious how it compares to other systems out there that I’m familiar with.

What do you recommend for a personal use?

dsvpn https://github.com/jedisct1/dsvpn

>These vulnerabilities are well documented in open source.

Seeing this awkward use of "open source" a lot lately. Its almost as if people think "readable on the internet for free" equals open source.

It does mean that. Free software and open source mean different things.

Is this open source or source available? There is a meaningful distinction.

What is the distinction?

Open Source fullfills the open source definition: https://opensource.org/osd-annotated. Source available is software where you can look at the source, but do not have the rights you have with Open Source.

Free software follows a philosophy of “all people have a right to use computing knowledge” which has a very similar set of license scenarios but a different underlying driving culture:

https://www.gnu.org/philosophy/free-sw.en.html

The “stricter requirements” piece is that the freedom bent sometimes leads towards more restrictive licenses (like GPL)

No. Open source has a precise defition that is equivalent with Free Software:

[1] https://opensource.org/osd-annotated

[2] https://en.m.wikipedia.org/wiki/Open_source

It's not equivalent with Free Software. Free Software has stricter requirements.

What are the stricter requirements?

I actually was wrong. Free Software is often used to mean Copyleft, but not actually defined that way.

To me "source" implies code though. Not article.

Open source as a term predates any software context.

It is an obscure term but it just isnt old enough or obsolete enough either way for it to be considered an archaic context

In this case, I think they're using "open source" in the intelligence sense, meaning publicly available [1]. NCSC is part of the GCHQ (UK intelligence agency) after all.

[1] https://en.wikipedia.org/wiki/Open-source_intelligence

The APT referenced in the NCSC alert is APT5: https://www.zdnet.com/article/a-chinese-apt-is-now-going-aft...

Thank you, did not want to enable JS to read...

The architecture (of classic VPN) is the vulnerability. imo, we need to move towards architectures which design in:

+ Least privileged access and isolation. Worst-case, 5-tuple, session-by-session. Best-case, app level bindings, independent of addressing. Isolation to prevent lateral attacks.

+ Zero trust. Yes the ZT term seems to have been taken over by marketing, but the architecture itself is sound.

+ Telemetry data for proper visibility.

+ Programmable-by-Design. Integrate into overall app and security constructs and tooling; no (mainly) separate VPN islands.

And not written in C, as some of these CVEs are the typical issues C has plagued the industry with.

Well, still better then having all internal infrastructure exposed by default. At least there is something that needs to be circumvented.

Companies that do BeyondCorp dont even have that level of protection. Most blindly follow that, without realizing that security of their internal systems is bad and therefore they should not do BeyondCorp. I have seen companies put their production infra without any fire walling out on the Internet (e.g jumpboxes and bastions) - that's also mind boggling.

Zero Trust is a journey not a solution....

BeyondCorp isn't incompatible with VPN solutions -- if anything they're highly complementary. Why not use both?

Exactly my point, Zero Trust is good strategy and mindset. BeyondCorp though is short sighted and seems more like a solution from a company that wants to sell its cloud sooutions, by trying to make VPN evil by suggesting you should not have a network perimeter at all:

"Connecting from a particular network must not determine which services you can access."

I argue, that a simple source IP check is still one of the most significant and effective defense in depth measures that can be put in place. Not doing it seems like lack of due diligence to me. Its the first level of defense to which more security needs to be added on to.

end users: "vulnerabilities" government security offices: "opportunities"

:-)

Reply on news.ycombinator.com