The test looks good, down from 3 criticals and 3 high to just 1 high. I'd be interested if they could expand on the 4 medium findings found. It's not the full report.
You can use the MacOS Network settings to connect to most types of VPN (hit "+" and fill in the forms to add a new connection). For free, open-source clients, Tunnelblick is very common.
macOS and iOS don't support OpenVPN with the built-in client. You can use strongSwan-based VPNs (e.g., as would be deployed through Algo) or Cisco, but for OpenVPN you'll need a custom client which, unfortunately, very likely brings along its own .kext.
TunnelBlick comes with a tun/tap kext that is signed. This is not required on systems where Apple already has tun/tap support compiled in (not sure when that started, but it's been a long time)
From the known issues page:
"If you are running on OS X 10.6.8 or higher and using OpenVPN 2.3.4 or higher and using a TUN device, the default Tunnelblick setting to "Load Tun Automatically" (on the "Advanced" settings window) will avoid this problem by not loading the tun kext — OS X's built-in "utun" device will be used instead of a "tun" device."
Is a .kext actually required for a vpn client? My understanding is that TunnelBlick just creates a tun network in user-space. Why would it need to be in the kernel?
NetworkManager is pretty much the default GUI for most distros and DEs, and has built-in support for OpenVPN, PPTP, L2TP, IPsec, SSH, etc... And it also integrates well with the Wifi setup, so you can easily set it up to automatically connect to the VPN when you connect to certain networks.
Very few software deployment systems make it possible for binaries to be independently reproduced from published sources by the public. AFAIK, it's limited to systems like Nix, Guix, recent Debian, and other participants in the Reproducible Builds project.
However, even within those systems, if you are downloading a compiled binary instead of building it yourself, how can you be sure that you get the "right" binary every time? Does the binary download system periodically "challenge" the binary provider by building from source and comparing with the downloaded binary? If so, does it report its findings anywhere?
It seems to me that even within a software deployment system that enables users to reproduce binaries, you still end up trusting whoever runs the deployment system, because there are no methods of challenging the reproducibility in a meaningful way. The systems I mentioned above sign the binaries, which means that you implicitly trust the holder of the signing key to send you the right binary. But it doesn't mean anything about the relationship of the binary to some source code.
Having said that, if I am using some program by downloading binaries, I am trusting whoever provides the binaries. If I trust them, then a source code audit is valuable to me, even though I can't be sure the compiled binary is related to the source code.
There's NO value in 3rd party vouching for the security (read, quality) of some specific version of the software, because this opinion will be rendered null and void with the next software update.
There is some value in 3rd party verifying the system design (the architecture, the protocol, etc.) and general engineering practices in the company, but this still hinges on the need to trust this company not to be (or being coerced to be) malicious. TunnelBear hasn't established the latter, so - yes, there's little to no value in former. There is some marketing value in it though.
PS. Zimmerman's original secure VoIP project was rooted in the idea of reproducible builds. It was open source, but with a license that prohibited any use except for verifying binary builds. It was 20 (?) years ago.
"NO value" is a huge stretch IMO. Sure, it's entirely possible for gaping security holes to be introduced in future releases, but if past versions have been consistently vouched for as secure, that's still going to increase my confidence in future versions being secure. Or if I'm paranoid, then where possible I can just stick to a specific version which has been vouched for as secure.
Regarding Zimmerman's VoIP, Tarsnap does the same thing. The client source is available but you aren't allowed to use it for anything except building the client for the Tarsnap service.
The trouble with VPN providers is that even with reproducible client builds, it's much easier for them to intercept the traffic on their side. Plus there is a near-zero chance of detection, unlike on the client side where the binary can be decompiled.
I work for an ISP and believe deeply in online privacy. I've had the idea of offering up an as-private-as-I-can-make-it VPN service a few times, but I always end up at the same point: wondering how I could prove that the service wasn't doing anything malicious or nefarious -- "taps", Netflow data, etc. would all be easily available to me.
What would it take to convince you that a VPN service was trustworthy?
Random audits from trusted third-parties would be a nice thing. Allow people to come in at any time and check the systems. Trust is better when distributed over multiple neutral parties.
In terms of features, allow clients to regularly change IP and don't log who is using what IP. Also mix client traffic with Tor exit nodes to add noise to the traffic.
I feel like people who complain about this are people who wouldn't be satisfied with anything unless they rolled it themselves. Of course, you could purchase your own server, use OpenVPN, etc. But anything that you haven't touched yourself is just one more thing that's potentially malicious.
Am I missing something? Nothing TunnelBear produces appears to be open source, so the obvious answer to your question is no. Members of the public can't build binaries at all.
TunnelBear is a great product, one which I've been using for a few years, and I trust them with my business. I wish services like Netflix didn't blacklist their IPs, but it's easy enough to get content off alternative sites when I'm traveling outside the US.
The claims of transparency would be a bit more meaningful if they simply published their source code. It is hard to imagine anything too precious to disclose in the code.
Instead what we have is a pdf (4 pages long) with the title "TunnelBear Security Assessment Summary 07.2017" and an equally long web page claiming how awesome and transparent this is.
Never trust a 3rd party VPN for anything sensitive ever, period. Words of assurance and "security audits" are completely meaningless. HTTPS interception and forwarding is a trivial thing to do. For the public who are unable to setup their own VPN, they will have to accept that everything they do is being monitored by a random internet company rather than their ISP now.
There can be some use for these services if you are very careful with everything you do while connected. But the risk of transmitting usernames, emails, passwords, and CC numbers accidentally while still connected is too great IMO.
If you aren't using their software, you will notice HTTPS intercepts. If your installing their client, they could slip a certificate into your chain, but someone would eventually notice.
I stick to openvpn providers and use my own software.
Seriously. Both get paid and provide Internet connectivity. Both have incentives to do something to your traffic, would it have no negative consequences (financial, legal or just moral) for them.
The only non-technical difference is that VPNs have a lot of competition (so free market actually works) and in some countries/areas telcos have near-monopolistic positions.
That doesn't mean that VPNs are universal friends of your privacy and ISPs are its foes. Just that there is some disbalance.
Yeah, I agree. I don't think there's an intrinsic good guy/bad guy. But I have pretty much zero faith in ISPs in Canada. Maybe it's better where you live.
Just because there are options doesn't mean there's competition n the free market sense. In order to have competition, the market requires complete information (or as complete as possible).
VPN providers are not competing on security as there is (as others have stated on this thread) no ability to validate their relative security claims. Many people are advocating for VPNs as a pure knee-jerk reaction to monitoring by traditional ISPs.
Their Linux support is limited (ie no client), but it is there. You just need to do the configurations (somewhat) manually. Works pretty well when I used it a few months ago on my Mint box.
The test looks good, down from 3 criticals and 3 high to just 1 high. I'd be interested if they could expand on the 4 medium findings found. It's not the full report.