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.
Vulnerabilities exploited in VPN products used worldwide
81–90 of 140 posts
Re: Vulnerabilities exploited in VPN products used worldwide
#82Earlier quoted context omitted.
> 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?
Re: Vulnerabilities exploited in VPN products used worldwide
#83Earlier quoted context omitted.
What do you think about cloudflare's vpn offerings? 1.1.1.1 and cf access?
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.
Re: Vulnerabilities exploited in VPN products used worldwide
#84Earlier quoted context omitted.
> 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.
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.
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.
Re: Vulnerabilities exploited in VPN products used worldwide
#85Earlier quoted context omitted.
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 t…
VPN's are the enabler that ensures status quo remains.
Re: Vulnerabilities exploited in VPN products used worldwide
#86Earlier quoted context omitted.
> 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?
Cellular networks abroad.
Re: Vulnerabilities exploited in VPN products used worldwide
#87Earlier quoted context omitted.
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 b…
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.
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.
Re: Vulnerabilities exploited in VPN products used worldwide
#88Earlier quoted context omitted.
What do you think about cloudflare's vpn offerings? 1.1.1.1 and cf access?
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.
That's the risk with open-source work though, isn't it?
Re: Vulnerabilities exploited in VPN products used worldwide
#89Earlier quoted context omitted.
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?
Re: Vulnerabilities exploited in VPN products used worldwide
#90Earlier quoted context omitted.
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 (caref…
> 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.