6 ms·

One would wish so! I recently had to start using PulseSecure. For authentication that damn thing loads a full blown webpage in the background, actually execute

One would wish so! 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.

thequailman 7y ago
WireGuard is actually pretty awful from an IT security org perspective. There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. Additionally, there is no concept of two step auth, so if your key is compromised, anyone can connect without anyone knowing about the compromise. 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.
- inetknght 7y ago
  > WireGuard is actually pretty awful from an IT security org perspective. There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. Additionally, there is no concept of two step auth, so if your key is compromised, anyone can connect without anyone knowing about the compromise. 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.
- olah_1 7y ago
  See this comment here https://news.ycombinator.com/item?id=21742178 https://news.ycombinator.com/item?id=21742178
- vetinari 7y ago
  As you noted, Wireguard is only a part of what makes the current VPN solutions. 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.
- ssebastianj 7y ago
  > There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. I'm wondering if this would be a use case for eBPF
- datenwolf 7y ago
  There are (at least) two pieces to WireGuard. The wireguard "wire" protocol itself, which is implemented in the kernel. And the authentication and key exchange, that are done by userspace tools. 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 https://www.wireguard.com/#cryptokey-routing) this would directly map.
  - flas9sd 7y ago
    If you haven't already, you should give Yggdrasil (https://github.com/yggdrasil-network/yggdrasil-go/blob/master/doc/Whitepaper.md#addressing https://github.com/yggdrasil-network/yggdrasil-go/blob/maste...) a read. > IP addresses are derived from cryptographic keys, to reduce the need for public key infrastructure
- fairramone 7y ago
  I tend to agree with this statement. I have been tracking WireGuard as a potential replacement for PulseSecure and it's a far ways off. We need 2FA and SAML support along with dynamic address assignment and logging before we can make the case to replace PulseSecure.
- samgranieri 7y ago
  Apologies for sounding flippant: this sounds like a good opportunity for someone to build tools that use wireguard as a foundation to achieve what you want.
viraptor 7y ago
> I can only hope that WireGuard is going to drive a solid piece of hardwood through every "commercial grade" VPN appliance out there 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.
- deleted 7y ago
  [deleted]
api 7y ago
I can tell you that as long as the crypto in WireGuard is DJB stuff that can't be FIPS certified, Cisco and Juniper and such will still do a strong VPN business and you will rarely see it in BigCo, at least in the US. 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.
- samgranieri 7y ago
  Humor me: What would prevent DJB's crypto from being certified by FIPS?
  - api 7y ago
    Bureaucratic inertia. I've been hoping for years that it'll be certified. They've talked about Curve25519 and Curve448 for a while but no movement so far. My insider sources tell me there's opposition, but I have no clue why... either the NSA prefers weaker crypto or (more likely) industry wants the status quo because they fear competition from open source superior products like WireGuard among many others.
    - tptacek 7y ago
      I feel like having a restricted set of algorithms in FIPS 140-2 is kind of the whole point of having things like AES in the first place. First you get everyone to agree on an algorithm, then you mandate that algorithm for your own applications. I don't expect them to budge from that, and I don't think it has anything to do with quality. At the point NIST certifies XSalsa20 as FIPS-compliant, they might as well rename it AESbis. 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.
close04 7y ago
> 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. This might quite literally be F5’s reasoning behind their BIG-IP Edge VPN client. :)
Hikikomori 7y ago
Currently looking at new vpn solutions where I work. Would like to use WG but it's just not suitable for a corporate environment (and neither is openvpn really, though we use it today), and it likely never will be because of how its designed (not a bad thing). I've used it privately for a while and it is much better than anything else.

thequailman 7y ago

WireGuard is actually pretty awful from an IT security org perspective. There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. Additionally, there is no concept of two step auth, so if your key is compromised, anyone can connect without anyone knowing about the compromise. 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.

inetknght 7y ago
> WireGuard is actually pretty awful from an IT security org perspective. There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. Additionally, there is no concept of two step auth, so if your key is compromised, anyone can connect without anyone knowing about the compromise. 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.
olah_1 7y ago
See this comment here https://news.ycombinator.com/item?id=21742178 https://news.ycombinator.com/item?id=21742178
vetinari 7y ago
As you noted, Wireguard is only a part of what makes the current VPN solutions. 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.
ssebastianj 7y ago
> There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. I'm wondering if this would be a use case for eBPF
datenwolf 7y ago
There are (at least) two pieces to WireGuard. The wireguard "wire" protocol itself, which is implemented in the kernel. And the authentication and key exchange, that are done by userspace tools. 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 https://www.wireguard.com/#cryptokey-routing) this would directly map.
- flas9sd 7y ago
  If you haven't already, you should give Yggdrasil (https://github.com/yggdrasil-network/yggdrasil-go/blob/master/doc/Whitepaper.md#addressing https://github.com/yggdrasil-network/yggdrasil-go/blob/maste...) a read. > IP addresses are derived from cryptographic keys, to reduce the need for public key infrastructure
fairramone 7y ago
I tend to agree with this statement. I have been tracking WireGuard as a potential replacement for PulseSecure and it's a far ways off. We need 2FA and SAML support along with dynamic address assignment and logging before we can make the case to replace PulseSecure.
samgranieri 7y ago
Apologies for sounding flippant: this sounds like a good opportunity for someone to build tools that use wireguard as a foundation to achieve what you want.

viraptor 7y ago

> I can only hope that WireGuard is going to drive a solid piece of hardwood through every "commercial grade" VPN appliance out there 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.

deleted 7y ago
[deleted]

api 7y ago

I can tell you that as long as the crypto in WireGuard is DJB stuff that can't be FIPS certified, Cisco and Juniper and such will still do a strong VPN business and you will rarely see it in BigCo, at least in the US. 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.

samgranieri 7y ago
Humor me: What would prevent DJB's crypto from being certified by FIPS?
- api 7y ago
  Bureaucratic inertia. I've been hoping for years that it'll be certified. They've talked about Curve25519 and Curve448 for a while but no movement so far. My insider sources tell me there's opposition, but I have no clue why... either the NSA prefers weaker crypto or (more likely) industry wants the status quo because they fear competition from open source superior products like WireGuard among many others.
  - tptacek 7y ago
    I feel like having a restricted set of algorithms in FIPS 140-2 is kind of the whole point of having things like AES in the first place. First you get everyone to agree on an algorithm, then you mandate that algorithm for your own applications. I don't expect them to budge from that, and I don't think it has anything to do with quality. At the point NIST certifies XSalsa20 as FIPS-compliant, they might as well rename it AESbis. 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.

close04 7y ago

> 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. This might quite literally be F5’s reasoning behind their BIG-IP Edge VPN client. :)

Hikikomori 7y ago

Currently looking at new vpn solutions where I work. Would like to use WG but it's just not suitable for a corporate environment (and neither is openvpn really, though we use it today), and it likely never will be because of how its designed (not a bad thing). I've used it privately for a while and it is much better than anything else.