Yes!
Hoping this will will have a pervasive effect like https in the networking world, esp for point to points that glue things together behind the scene. Encrypt all the things!
Hoping this will will have a pervasive effect like https in the networking world, esp for point to points that glue things together behind the scene. Encrypt all the things!
I recently had to start using PulseSecure. For authentication that damn thing loads a full blown webpage in the background, actually executes the JavaScript therein, fills some forms and submits that via POST. There's a PulseSecure module for openconnect, but it's unable to send the keepalive reauthentications, because it's unable to correctly associate the presented form inputs with the credential fields, so I'd have enter them manually, on each keepalive.
I can only hope that WireGuard is going to drive a solid piece of hardwood through every "commercial grade" VPN appliance out there, and then desintegrates their heads, too, just to be sure.
But given the inertia of big orgs, and the that public and governmental institutions for one reason or another seem to trust "BIG" names with "BIG" (i.e. bloated) products and marketing more, than small, easily auditable stuff, I don't see it happening… sadly.
Security is largely about checking boxes to reduce liability, and FIPS is a checkbox.
Corporate IT is unbelievably conservative. It's all still about Active Directory, Windows domains, and SSL VPNs with FIPS certification and AD support.
Sure you can use Samba / OpenLDAP / half a dozen of IMAP/SMTP servers for groupware but holy hell administering it is an utter hellhole of a mess compared to the MS offerings.
Corp IT cares about two things: retraining costs for employees and admins, and efficiency. And Apache Directory Studio just doesn't cut it compared with AD Editor.
It's actually rather stable, and can integrate with nearly everything.
AD can optionally replicate by sending email (SMTP) between sites.
i know this option has existed till atleast 2008.
The more productive approach is to work on convincing stodgy enterprises that FIPS is a bad thing (which it is).
Industry prefers FIPS 140-2 because cryptographic expertise is extremely scarce and, prior to AES, commercial products were choc-a-bloc with broken hand-rolled cryptography. It's a rational decision to delegate selection of primitives to NIST.
I think FIPS 140-2 is aging poorly, but I think that's in part because all cryptographic standards are aging poorly; like, the whole concept: top-down standardization efforts with whole cryptosystems designed by committee have a very poor track record, and probably aren't the right vehicle to improve cryptographic soundness in the industry.
https://csrc.nist.gov/publications/detail/fips/186/5/draft
NIST SP 800-186 (Draft) has the curve definitions. But says only for Ed25519, not for X25519. They have a Weierstrass curve W-25519 that is isomorphic to Curve25519 that might allow using X25519 code, but that's way above my ability to judge. 'tptacek or 'jedisct1 or others will know.
I use Linux since 1993 and love it. All my servers are on Linux. Managing them as a group is a nightmare. I would love to have an umbrella à la AD to have all servers and users unified inside.
The strengths of AD are more related to client software, where many of them uses the policy mechanisms therein for management. Maintaining servers isn't what it does best.
This is a large part of the reason why "the cloud" is pretty much Linux native.
It has limited to no use to manage users and their passwords or authorizations, their control over machines, remote access to a share and zillons other usages you need specialized software for. AD has it all natively.
- users management? NIS
- configuration management? ansible / salt
- machines management? none (we use a homebrew system based off salt)
- shared storage? NFS
- policies? salt or ansible if they are common to groups of machines, or NIS if for people
etc.
I would love to have a unified tool (similar to what Zen was trying to do 20 years ago) but I do not know any. What AD does for Windows is nice (though I do not use Windows servers but I see their management from the side), Linux was intended to be standalone and this is what there are so many specialized, but disconnected management systems.
Take NFS as an example. Let's say all your users with meets certain criteria needs an NFS share named after their user and with an ACL that gives some running software access to drop files there. Maybe this share should be mounted on every machine where this software is present, regardless of who own it or where it runs. You write this rule in Puppet code and then it is guaranteed to be true for everyone forever.
Note that we didn't even need to feed Puppet any new information to do this. All the data required to implement the change was already in the configuration database. (Which is not even a real database but only the result of existing rules.)
Compare with a product such as AD. It doesn't really do the management for you. You can store the data there, but then you need to write a script to implement this change across your server farm. This need to be maintained, and regularly checked re-run to check for changes. Someone has to schedule this. When conditions change, the software which got access changes id, or is installed in another way, the script needs to be maintained accordingly.
Having this version controlled adds another aspect to this. Since everything is text, if you find this rule you can follow the commits and see exactly who brought this into production and when.
It's interesting that you refer to Linux as a standalone system. Linux and other unices have their roots not in single instance "personal computers" but in multi user environments. This is why to this day Linux admins treat everything as text and work mostly by text commands. Others may find this archaic but without this and without version control we could never maintain large homogenous environments. You might say that automation is built into the very way we use these systems.
If security companies adopt WireGuard, expect things like PulseSecure to remain as a wrapper around WireGuard. They'll at least standardize on a performant and verifiable VPN solution.
Right now there exist the "default" tools, which require a manual exchange of key pairs and do only very rudimentary user mapping and authorization.
However: It is perfectly possible to implement much more complex authorization schemes, with all the two step auth, logging, etc. you desire. Somebody has to write the tools for that, still. But the nice thing is, that this is a pretty much independent task, which you could do over any transport/protocol you desire (HTTPS, SSH, custom made, etc.).
An idea I've had for a longer time, but don't have the time to actually invest developing it, is using wireguard for a pure IPv6 mesh VPN.
- The ULA network part would be the key-id (lower bits) of the mesh public key (i.e. with knowledge of the mesh private key you can join the mesh), used for the mesh setup.
- The Host part would be each individual host's key-id (again lower bits of the public key).
Since wireguard uses Cryptokey Routing (https://www.wireguard.com/#cryptokey-routing) this would directly map.
> IP addresses are derived from cryptographic keys, to reduce the need for public key infrastructure
WireGuard's open source. Also you should bring these points up on the mailing lists. Even if you're not the one who writes it, mentioning it should put it on peoples' radar.
But that does not mean that it will stay that way. There's already effort at wg-dynamic, for dynamic allocation of ip addresses (as opposed to static allocation, which is current status quo in wireguard).
Later, it might be worth of effort to try running 802.1x over wireguard for authentication and accounting.
I'm wondering if this would be a use case for eBPF
I'm not sure that will happen. I mean, we had multiple solutions very close to what wg provides already. They're not as trivial to configure, but it would definitely be easier than creating a custom java applet instead.
Whatever makes enterprise VPN so bad, it doesn't seem to be the availability of better tech.
I've used it privately for a while and it is much better than anything else.
This might quite literally be F5’s reasoning behind their BIG-IP Edge VPN client. :)
Whether you can actually trust an HTTPS site or an IMAP connection when you're in a hotel in China is another problem that a VPN can solve. The CA infrastructure is ridiculously fragile, especially now that HPKP is dead in the water.