90% of SSL VPNs are ‘hopelessly insecure’, say researchers

Re: Clickbait.

Quite apart from the fact that they are far to close to advertorials much of the time, the huge conflict of interest from the company whom is carrying out the "research" automatically makes me very wary about the quality. It will call into question the very methodology used and whether there is intentional or unintentional bias just for starters.

Personally I know enough about the methodology to know not to trust it - almost invariably these reports based on automated scans and tickbox marking get a "fuck that" response. There is no reference to what is being secured which is pretty important when determining if a given level of security is sufficient. Demanding that everything has military-grade encryption regardless of need is idiotic, it wastes a lot of time and distracts from protecting the important stuff. No-one has yet broken SHA-1 for example so presenting its use as a clear and present weakness is hyperbole.

Then you have opinion presented as fact with no knowledge of the context. Here the flaw is "untrusted" certs which is used to mean self-signed types. If your own organisation uses it own keys and distributes them to it own systems that is perfectly sensible and perfectly secure. A scan can't detect that so the conclusion is misleading.

End result - a paper from people who don't know what they are talking about and applying it to systems that they also know nothing about. This paper is only fit for cleaning the author's arse after the emission of so much excess verbiage.

Re: Clickbait.

I would agree with the conflict of interest if I could find that the company offers services like VPN or SSL configuration, but apparently they don't.

So if I wanted to be critical with your comment, I would say that you did not have a look on the company's website that would show they make security tests and they don't seem to provide other services (like configuration improvements).

As a result, as their main activity seems to be security testing, they probably don't mind if results are good or bad, they just want to show they can do their job by releasing this research.

Well, yes

If you consider that they just forgot to prefix that sentence with In theory,

Exactly, was going to say the same. They don't trust it, doesn't mean the ones using don't. If its a corporate VPN, no need to buy an externally trusted certificate, you can use your own internal CA to issue it, all the corp computers will trust it.

That was the argument I was going to make, until they mentioned that just sticking with the vendor's default accounted for a good number of those. That's a different kettle of fish.

That aside, using a certificate signed by your own CA doesn't offer any issues IMO, so long as the clients trust your CA. In fact, if you're using a client that can be told to _only_ trust your CA then even a cert from a compromised public CA becomes less of a vector.

Having a cert issued by a publicly trusted vendor has it's value when it's randomers hitting your service (e.g. a https site), but when the end client is one you control (e.g. a work laptop) or operated by someone you're associated with (like a colleague) reducing trust to a CA you control has some benefits

Re: OpenVPN

OpenVPN best practices recommend to use TLS authentication that probably forbid such SSL/TLS scanners to test OpenVPN servers without having knowledge of the key (as this configuration forbid Heartbleed exploitation): https://community.openvpn.net/openvpn/wiki/Hardening

Re: " because they do away with the need to install client software"

"And even worse, many of them route all your traffic through the VPN, even the one for your local network, as if VPN users were always remote workers in an hotel room. Site-to-site VPNs are often a better solution."

Sometimes routing all traffic is really a great way for using e.g. Google services from China. Or when using insecure networks, e.g. "Free Wifi". Or e.g. accessing BBC from abroad. Or having all traffic scanned for malware. As long as there's enough bandwidth at the firewall location - why not?

Site-to-Site is easier to manage but it's better for remote offices than remote users.

Re: TCP over TCP?

Some SSL VPNs (maybe many I am not sure) use a different port for data communication. I know that Pulse VPN (used to be juniper) uses a UDP port by default after authentication though falls back to tcp/443 if that fails.

In my experience I have seen no noticable difference in end user VPN performance with IPSec(in my case sonicwall) or SSL (citrix access gateway or pulse). One benefit to IPsec seems to be scalibility. With every SSL VPN I have seen relies on general purpose CPUS sometimes with an SSL offload chip. SSL vpns have a massive benefit over IPsec(web based I would NOT put openvpn on this list) as far as user friendly-ness.

Web based SSL vpns are nice for one thing above all else for me -- integration with duo security two factor auth. So easy to setup and use for end users it's been unbelievable. Though efforts to kill java in browsers has made it more difficult to do browser initiated VPNs. Pulse recently released an update to address this and Duo promptly emailed me saying don't upgrade until they patch to support whatever it is that pulse does in this new version. I am in no hurry. In the meantime I tell users to use firefox for the best pulse+duo experience.

Having browser initiated vpns helps address the problem of pre installing vpn software on end user computers too. I haven't been in internal IT in 13 years(so no responsibility over internal corporate user computers ) but this is still a big issue in many shops.

I use openvpn for my personal use though is a bitch to setup and manage. Fortunately I haven't had to touch the config in 3 or 4 years now. I gave up trying to get openvpn to work on android the clients I came across wanted the config in a special format and I didn't know how to build that format. I use openvpn between 2 openbsd boxes for site to site(colo aand home). And i use openvpn with an extra key file to connect my mint laptop to my colo'd server.