Questions you need to ask you're VPN Provider!

questions
To download these tutorials for OFFLINE viewing or for archive purposes please (Click here to download)
(Clicking the “.zip” will open the Archive, un-zip the .mht files then use one of the plugins below to view them)

You can open .mht WebArchive files directly inside FireFox Or Google Chrome by installing a plugin


Before you decide to hop onto a VPN contract with one of the many great providers featured on our website.
You might want to slow down just a little, and get lots of information before you decide to lay down any money!

This isn’t just to save you a few dollars, because you choose the wrong VPN provider.
This is to save you millions in copyright fines, losing you’re house/home, going bankrupt!

All VPN providers have different ways’s of dealing with many things that you may actually just take for granted!
Below is a good list of questions to start with.

Is there a monthly bandwidth-usage limit?

This restriction has become less common in recent years. Usage limits are more common for VPN resellers, so it’s probably best to avoid providers that impose them for paid accounts.

Do you throttle connections that use excessive bandwidth?

The best answer here depends on your goals. It’s natural to want the fastest possible connections. However, if you have a very fast ISP link, you might be moving far more traffic than anyone else sharing your VPN exit. And that reduces your anonymity.

How many concurrent connections are allowed per account?

For VPN services with many exits, it’s sometimes convenient to simultaneously work as multiple pseudonyms, each using its own exit. Also, you may want to simultaneously connect from multiple devices. However, this also facilitates account-sharing abuse, which may overload VPN servers and slow your connections.

How many hops are there in your VPN connections?

Most VPN services offer just one-hop connections. That is, you connect to a VPN gateway server, and your traffic exits to the Internet from the same server, or perhaps from another server on the same local network. With one-hop connections, it’s easy for adversaries to log traffic entering and leaving the VPN server.

What type(s) of VPN encryption do you use? Why?

OpenVPN can operate in two distinct modes. One authenticates and encrypts using a shared static key. While that’s very simple to set up, key compromise allows an adversary to decrypt all prior traffic. No reputable provider uses this. But if you receive just one key file from a provider, open it in a text editor, and look at the last line. If it includes “CERTIFICATE”, you’re OK. But if it includes “KEY”, request a refund.

The other OpenVPN mode uses SSL/TLS as a control channel, and encrypts the data channel with periodically changing static keys. If an adversary manages to compromise one of those data-channel keys, they can decrypt only that traffic, and not any past or future traffic. In other words, there is “perfect forward secrecy”.

By default, OpenVPN uses 1024-bit RSA for the certificates that authenticate SSL/TLS control-channel handshakes, and BF-CBC (128-bit) as the data-channel cipher. This is probably good enough in most cases, given perfect forward secrecy. However, it’s arguable that providers using 2048-bit RSA and AES-256-CBC (256-bit) are generally more security conscious.

Both BF-CBC and AES-256-CBC operate in Cipher Block Chaining (CBC) mode. If your provider uses something else (CFB, OFB, etc) they’re either incompetent or have some very good reason. Ask them.

Do you support perfect forward secrecy? If so, how?

Any provider using OpenVPN in SSL/TLS mode provides perfect forward secrecy. Additional hand waving beyond that should make you suspicious.

Do you provide users with Diffie Hellman key files?

This is a trick question. It’s true that OpenVPN uses static Diffie Hellman key files in providing perfect forward secrecy. But that static Diffie Hellman key file (“dh1024.pem” or “dh2048.pem”) is needed only on the server. Any provider that supplies them to users is incompetent.

How do you authenticate clients – certificates/keys, or usernames/passwords?

In SSL/TLS mode, OpenVPN clients authenticate servers by checking whether a server has a certificate signed by the certificate authority certificate (“ca.crt”) that the provider has given them. OpenVPN supports two methods for servers to authenticate clients. One relies on certificates and keys (such as “client.crt” and “client.key”). The other relies on usernames and passwords (via auth-user-pass). Servers can use both, but that borders on overkill.

For point-to-point connections, where full network access may be at stake, it’s very important for servers to authenticate clients using certificates and keys. For VPN services, that’s not an issue, because clients just get to see the Internet. Also, for VPN services, giving each client a unique certificate is a privacy risk.

Do you employ HMAC-Based TLS Authentication? If so, why?

With TLS authentication enabled (via tls-auth), servers ignore SSL/TLS handshake packets from clients that lack the correct HMAC signature. This feature protects VPN servers from DoS attacks, port scanning and other exploits. If implemented, providers may supply a key (typically “ta.key”) or one can be negotiated on the fly.

This is partly a trick question. Any provider claiming that this is essential for perfect forward secrecy is either dishonest or incompetent.

Do you ever email usernames and passwords to customers?

This is a dangerous practice, but primarily for the provider. Adversaries that compromise usernames and passwords in transit can obtain free access, or even lock out paying users by changing passwords. There’s also the risk that adversaries could implicate users in criminal activity.

Even so, if you successfully change your password immediately after receipt, you’re safe. If you can’t login to change the password, complain and demand a new account. For providers that are otherwise attractive, I don’t consider this a fatal error.

Does each customer have a unique client certificate and key?

This is another trick question. Privacy-friendly answers are using the same client certificate for all customers, or not providing one at all, and relying on username and password for authentication.

It might seem like a good idea for each user to have their own certificate and key. And that’s true in an enterprise context. But for VPN services it’s very dangerous, because it potentially links user accounts to logged traffic. Some providers explain that they issue unique client certificates in order to facilitate nuking evil clients. However, it’s just as easy to do that with usernames, and usernames are arguably more readily repudiated than certificates.

If this is a key issue for you, it’s easy to test by purchasing two short-term subscriptions, paying with Bitcoins via Tor, and using temporary email addresses from anonbox etc.

Are your VPN gateway servers hosted, co-located, or in-house?

This is partially a trick question. I would be very suspicious of any VPN provider claiming that its servers are managed in-house. You could ask how they cover the cost of maintaining facilities with high-speed uplinks in multiple countries.

The best plausible answer is that they build their own servers, and ship them to co-location facilities. Give extra points for server hardening. Typical physical hardening measures include embedding RAM in silicone rubber or thermal adhesive, and disabling USB ports.

The most likely acceptable answer is that they use hosted dedicated servers. Give extra points for server hardening, such as using full-disk encryption, and keeping short-term logs in RAM (tempfs).

Are any of your VPN gateway servers running on VPS or cloud servers?

Providers should never deploy VPN gateway servers on virtual private servers (VPS) or cloud servers. Being virtual machines, they are fully controlled by the host operating system, and all activity and data is readily available through the host. Providers should always use dedicated servers that have been properly secured against unauthorized access.

How are your VPN gateway servers protected?

VPN services typically need servers playing three roles. There are gateway servers that establish VPN connections with clients, and also route client traffic to the Internet. For one-hop connections, one server may handle all of that. There are servers that host the service’s website. And there are servers that manage user account information, and provide authentication services to gateway servers and web servers.

All client traffic is routed through the gateway servers. Unless those servers are adequately secured, adversaries could compromise them, and so compromise users’ privacy by logging their traffic. VPN gateway servers should be hardened according to industry standards such as the CIS benchmarks or the NSA baseline guides.

Most importantly, VPN gateway servers should not be running other network services, such as website hosting, or user accounting and authentication. Doing so substantially increases VPN gateway servers’ attack service. You can verify what ports and services are accessible on a VPN gateway by using a port scanner such as nmap. However, keep in mind that many providers expose VPN servers on non-standard ports such as 80 (HTTP) and 443 (HTTPS) to evade firewall blocking.

Where is user account information stored?

Providers should ideally be storing this information on colocated or in-house servers that are suitably encrypted, hardened and protected against adversaries. Also, they should be segregating authentication data, which must be available to gateway servers, from accounting data, which may include users’ private information, such as usage logs, email addresses and payment records.

How is communication between servers secured?

Well designed VPN services comprise networks of specialized servers with distinct roles that communicate securely with each other. For example, gateway servers must contact authentication servers to verify that users are authorized to connect. There are also backend provisioning systems that use rely on sales data from websites to create and update user accounts, and then update the authentication servers.

Given the sensitivity of this data, and its value to adversaries, all communication among these servers must be securely encrypted. Most commonly, this relies on persistent OpenVPN or IPSec tunnels between servers.

Do you allow port forwarding by users?

When you are connected to a VPN service, the VPN gateway server protects your device from potentially hostile incoming connections in the same way that your LAN router or firewall does. However, allowing incoming connections on particular ports is essential for operating servers, or for participating in P2P networks where your node must be visible to other nodes. That process is called port forwarding.

When port forwarding is enabled, your device is directly exposed to the Internet on the ports that have been forwarded, with no protection by the VPN service. An adversary may successfully exploit a vulnerability in a service that’s listening on a forwarded port, and compromise your device. In addition to typical consequences such as botnet membership and data theft, an adversary may compromise your privacy and anonymity by “phoning home” when when you’re not using the VPN service.

Are all client ports ever forwarded by default? If so, on which servers?

Some VPN services forward all client ports by default. Some do so only on designated servers. For some services, it appears that port forwarding varies among servers with no pattern or documentation. Although it’s possible to check for this using port scanning, it’s complicated by the fact that many different clients using the same exit IP address may have the same ports forwarded.

Once you’ve then give them the biggest migraine known to man, they will understand you are a customer that
Does not like to be messed with, so they will either accept you on board or tell you, that the service is not for you.

There is so many VPN providers, that are great! But there is so many that are also complete lemons!
These questions, might just help you decided who’s who! Good luck!