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.
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.
VPN's are the enabler that ensures status quo remains.
VPNs handle network security, but don't protect you against an attacker able to compromise an endpoint in your corporate environment.
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.
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.
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.
1. The things for compliance.
2. The things for security.
Only rarely does something fit in both categories.
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.
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.
I wouldn't ding someone using SSH tunnels (carefully), but in a de novo design, I would always recommend WireGuard first.
> 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.
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
1 core, 2GB per VM
iperf3 -t 60
OpenVPN: no compression, udp, tun, defaults
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.
You wouldn't have an independent benchmark comparing a GTR and a semi truck.
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.
Cellular networks abroad.
Some client from WG directly is also in the works.
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 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.
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.
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.
> 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...
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.
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.
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.
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.
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.
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.
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.
That's the risk with open-source work though, isn't it?
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.
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.
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.
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.
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).
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.
How does Streisand compare?
It's alpha level software at this point and should not be relied upon or even trusted.
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.
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.
Show me a FIPS140-2 Wireguard implementation.
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.
There is maybe nothing in the industry that has done more damage to cryptographic security than government cryptography standards.
Anyway, compliance doesn’t necessarily imply security.
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!
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.
The “stricter requirements” piece is that the freedom bent sometimes leads towards more restrictive licenses (like GPL)
It is an obscure term but it just isnt old enough or obsolete enough either way for it to be considered an archaic context
+ 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.
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....
"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.
PDF file at the bottom
(I'm assuming they don't sit on all AWS servers/have broad access hence going after less mature businesses...)