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

Nine in 10 SSL VPNs use insecure or outdated encryption, putting corporate data at risk in the process, according to new research. High-Tech Bridge (HTB) conducted large-scale Internet research on live and publicly-accessible SSL VPN servers. The firm passively scanned 10,436 randomly selected publicly available SSL VPN …

  1. shifty_powers

    Clickbait.

    Coming from a medical, specifically mental health, background these articles really annoy me.

    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.

    Can the register stop regurgitating what are close to press releases uncritically? If you are going to publish them at least have a decent analysis of the strengths and weaknesses of the research and acknowledge the huge conflict of interest.

    Otherwise this article and too many like them on the website come close to clickbait.

    Hardly biting the hand that feeds it.

    1. Anonymous Coward
      Unhappy

      Re: Clickbait.

      I have to agree, I still remember my favourite irreverent article sub-title from 2004

      http://www.theregister.co.uk/2004/02/26/boffins_make_heaviest_ever_element/

      Boffins make heaviest ever element?

      Obesity trend continues

      Over the last few months DevOps has taken over, the conversationalist (or whatever it's called) has been regurgitated regularly and the Space Plane project seems to have stalled. Sad face because one day I may have to tell the children and I'll be a fogey reminiscing on how great it used to be.

      1. ZSn

        Re: Clickbait.

        You also forget about the number of times that they mention the company 'violin'. What makes it so worthy of mention all the time is beyond me.

      2. DropBear Silver badge

        Re: Clickbait.

        "Over the last few months DevOps has taken over"

        You would be surprised how much more soothing reading The Register becomes with the aid of a simple Greasemonkey script that just "disappears" any titles with a set of keywords in it (first filter: DevOps). My front page is about one-third blank "holes" now (zero pictures btw.), but it absolutely saved my sanity.

        1. JeffyPoooh
          Pint

          Re: Clickbait.

          DropBear on El Reg "...script... ...(zero pictures btw.)..."

          What!??

          The pictures are almost always hilarious, sometimes subtly hilarious which makes them even hilariouser.

          Oftentimes they're the perfect representation of a famous meme.

          One does require a sense of humour to enjoy them.

        2. Graham 32

          Re: Clickbait.

          >You would be surprised how much more soothing reading The Register becomes with the aid of a simple Greasemonkey script that just "disappears" any titles with a set of keywords in it (first filter: DevOps)

          I've never got round to doing that, but I have been tempted. My first filter would be to delete anything containing "Elon" or "Musk".

    2. the spectacularly refined chap

      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.

      1. Daniel B.

        Re: Clickbait.

        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.

        Self-signed certs are still insecure, you're thinking about an organization-managed CA. :)

    3. jdl314159

      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.

      1. Tom 13
        FAIL

        Re: they probably don't mind if results are good or bad

        Brrrrrrttttttt!!!!!!!!!!!!!!!!

        Wrong answer. Bad results sell testing. Good results sell nothing.

        Next contestant!

        You don't get to come back next week. You don't even get a copy of our home game. You're a complete loser!

        /w apologies to Weird Al.

  2. Anonymous Coward
    Coat

    Err..

    VPNs allow users to securely access a private network and share data remotely through public networks.

    Not according to the article.

    1. Pascal Monett Silver badge

      Well, yes

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

  3. TeeCee Gold badge
    WTF?

    ....use an untrusted SSL certificate....

    Ah, that old chestnut. Define "untrusted", as your opinion will differ from everyone else's in some manner, especially if your name is Google.

    You may not trust whoever issued it, but that doesn't mean that everyone doesn't and it certainly doesn't mean its necessarily more simple to fake.

    1. Anonymous Coward
      Anonymous Coward

      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.

    2. Ben Tasker Silver badge

      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

  4. JeffyPoooh
    Pint

    "...outdated encryption..."

    "...outdated encryption..."

    The word "outdated" papers-over a recurring theme in the history of cryptography.

    It often refers to an encryption standard that was once believed to be secure, but was then subsequently shown to be less secure than was once imagined.

    Preempting your next thought: Almost all of the time, at least in the history of modern cryptography, the 'outdatedness' has NOTHING to do with the progress of Moore's Law and 'brute forcing'. More often it has to do with the cryptanalysts beavering away until they uncover the seemingly-inevitable subtle flaws; either in the fundamental algorithm, some particular implementation, or (in some applications) an unacceptably high risk of operator error.

    Too many have the incorrect impression that the deterioration over time of an encryption standard is due only to some external process, like the weathering or erosion of a big rock. In fact, 'the rock' was typically internally-flawed from Day 0. The subtle flaws are eventually exposed by close examination, which may take several years.

    The timing of the public pronouncement of 'outdatedness' often comes down to motivation (effort, speed) of the crackers, or even if they wish to keep their success a secret for a while (e.g. Churchill and the Enigma, kept Ultra Secret for decades). An encryption standard may actually be 'outdated', but hardly anyone is in on the secret.

    The adjective 'outdated' tends to support muddled naïve, wishful thinking about whatever cryptography algorithm is the present standard du jour.

    Sometimes the best adjective would be 'flawed'.

  5. Alistair Silver badge
    Windows

    Hang on a minute, I can rewrite that article for you:

    Oh my #$% god, there are SOOOooooo many broken, unsecured, terribly configured, badly managed, broken <insert relevant object here> on the internets!!!!

    Look, we scanned < insert minute portion of the available IP space number > of IP's and found <insert massive statistically irrelevant number> of vulnerabilities!!!

    <buzzword soup opinion piece>

    <Corporate consultancy commentary>

    Sorry, it took one name to mark that advertorial.

    <grumpy as hell since I've got two dropdead timelines a week out and two funerals to go to today, as well as being down a quart of coffee>

  6. SJA

    OpenVPN

    After reading that article I wanted to test what it says about our OpenVPN. After all, it uses SSL/TSL after all.

    However, it couldn't really conduct any test. It was just aborted silently.

    1. Anonymous Coward
      Anonymous Coward

      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

      1. John Brown (no body) Silver badge

        Re: OpenVPN

        @AC, so, does that mean that SSLs/VPNs configured to block heartbleed by definition drop scanning attempts and so the only/majority of results back from SSL/VPN scans are those which are outdated/misconfigured/not patched?

  7. Anonymous Coward
    Anonymous Coward

    Untrusted?

    Just because you don't trust the SSL cert, doesn't mean that the people using it don't.

    Why fork out for a public-ca-signed certificate if the public isn't supposed to be using your Virtual *Private* Network?

  8. Anonymous Coward
    Anonymous Coward

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

    Utterly untrue. For example Windows has a VPN client backed in, which works with standard IPSec protocols. IPSec may have less overhead, and may work without certificates which are an issue, as the article show, because people are too mean to buy the righ one, or to setup their own PKI properly (self-signed certificates are good, aren't they?)

    It was the silly companies that forced the use of their proprietary software like the dreadful Cisco VPN client.

    I've also seen one - Juniper IIRC -forcing you to install their client first, than having to login true a browser because some luser develope thought exactly that SSL/TLS just works over HTTP.

    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.

    1. Sandtitz Silver badge

      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.

  9. Eeeek

    Somebody failed to do their analysis properly.

    I don't know if it was the lazy author at the register or the incompetent researchers at the company that conducted the research but either way there are far too many holes in what is presented to take that article as anything other that spreading fear uncertainty and doubt.

    "Three in four (77 per cent) of tested SSL VPNs still use the obsolete SSLv3 protocol". Of course the biggest commercial VPN products allow for configuration of allowable protocols on a per-user (or group) basis, so you won't actual know if anyone can use that particular protocol to communicate with unless you have credentials to test it. It is quite common to allow any protocol during initial handshake and only reject it when the client attempts authentication. Since this was random, the couldn't have gotten past the initial handshake.

    "Three in four (76 per cent) of tested SSL VPNS use an untrusted SSL certificate" is another completely misleading statement. It is also common for a company to set-up systems and services intended for their own people (and in some cases their clients) using an internally maintained certificate authority. This lets them improve security (by not trusting the practices of 3rd party CAs) while potentially saving money by not having to pay for 3rd party signed certificates. It can also greatly simplify their IT administration in managing end-user (and device) certificates since they won't have to deal with those 3rd parties at renewal time.

    "A similar 74 per cent of certificates have an insecure SHA-1 signature, while five per cent make use of even older MD5 technology. By 1 January 2017". Seriously? The vendors of the VPN appliance and even the article itself say they are only starting to roll out change to remove support for SHA-1. That's pretty clearly an indication that corporations have an entire year to make their own changes. In other words we are still in the transition period away from SHA-1.

    By the time we get down the list to things that might actually be real findings, the article has completely thrown the reliability of the "research" into question. "One in 10 of SSL VPN servers that rely on OpenSSL (e.g. Fortinet), are still vulnerable to Heartbleed." is actually something companies should be worried about, but as someone who works in the field, I'm surprised it's that low.

  10. pyite

    IPsec?

    Why don't people just use IPsec? It is part of the TCP/IP standard and works much better than SSL VPN's (or, god forbid, the worst of the bunch: L2TP).

  11. jeffh322

    SSL/TLS negotiation occurs _before_ authentication even takes place. If that were not the case, any credentials transmitted would be in cleartext and not encrypted.

    The ability to configure a VPN gateway to accept SSLv3 (or earlier), or to require TLS (1.0, 1.1 or ideally 1.2) is a configurable setting on many products. If a VPN supports SSLv3 (or earlier) then it's either a configuration issue and/or the code on the VPN is so old it doesn't permit for selection of these settings.

  12. AlexV

    For how many VPNs is security a barely relevant consideration anyway?

    Sure, you want security if your VPN is for connecting to your corporate network and accessing sensitive data. For a large number of VPN users, though, the only consideration is the IP address you appear to be coming from, whether for bypassing geolocation and content blocking, or for anonymity and privacy from those who consider a list of IP addresses a juicy set of targets for threatening letters demanding money.

    For these use cases, security of the connection is barely relevant. Certainly far less important than location, speed, cost, and security (or preferably absence of) any logging or customer data.

  13. patrickstar

    TCP over TCP?

    SSL VPNs?

    Doesn't running TCP over TCP play havoc with TCPs flow control and thus lead to abysmal performance? Or has this been worked around since I last looked at it (get off my lawn, I tied an onion to my belt, etc.)?

    Are they referring to browser/web application-based stuff? The whole part about not needing to install client software seems to imply that.

    1. Nate Amsden

      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.

  14. laurenaria10

    90% ssl vpns insecure

    90% this is the very big ratio. I am using purevpn that was suggested by vpnranks_com and i am not confirm that either it is highly encrypted or not but still i am not facing any sort of issue till now. Although i did some torrent but still save but i am still confuse after reading your analysis that 90% vpns are using insecure and out dated encryption. If is this joke then it's ok otherwise its really a serious issue.

  15. CropDuster

    Tin Foil Hat alert...

    This is just an opening salvo in Google's push to have EVERYTHING on https with Google issued Certs. Why you ask? Ads, google certifies the ads, with their certs, to slip them by your adblockers.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020