Questions for your VPN Provider.

[Fixxx]

Choosing a VPN service can present some challenges. You may not trust your internet service provider when it comes to privacy protection (and, as the FTC concluded, you really shouldn't). You may even distrust all governments and corporations. Regardless, if you are naturally inclined to research things before using them, this guide will be helpful. If you are particularly concerned about privacy, you will likely want to keep your research on VPN providers private. While many people use VPNs, extensive research could make you appear as someone with something to hide. You can mitigate this risk by using free VPNs and webmail at this stage. For even greater privacy, you can use VFEmail's implementation over the Tor network.

There is relatively little reliable and trustworthy information about VPN services on the internet. It's advisable to ignore websites with titles like "best VPNs" and "VPN reviews". Most of them contain paid reviews and some simply post negative reviews of VPN services that refuse to pay for favorable ones. Even honest sites typically just compile lists of popular services without considering quality. If you ever need information from a specialized VPN review source, look for those that don't use affiliate programs in their outbound links. When searching, it's important to choose VPN providers that will help you achieve your specific privacy goals. It's recommended to thoroughly examine the provider's websites and carefully read their terms of service and privacy policies. Look for clear and unambiguous language and be wary of legal jargon.

For example, if you plan to share copyrighted media files via BitTorrent, it's best to avoid providers that explicitly prohibit such use. If access to numerous locations is important to you, choose accordingly, but consider the trade-off between variety and security. Providers with numerous IP addresses in different countries are more likely to use virtual private servers instead of dedicated physical ones. How potential VPN providers respond to your questions can be as informative as the answers themselves. You need quick, complete, clear and accurate responses. Vague or incorrect answers to technical questions indicate dishonesty and/or incompetence. Delayed responses do not bode well for future customer support. Below are some questions you might ask a VPN provider before purchasing, along with expected answers and explanations. For technical questions, useful resources include the OpenVPN guide and How-to, as well as the official WireGuard page.

Questions​

1. Is there a monthly bandwidth usage limit?
2. Do you throttle connections that exceed bandwidth limits?
3. How many simultaneous connections are allowed per account?
4. How many hops are there in your VPN connections?
5. What type(s) of VPN encryption do you use? Why?
6. Do you support perfect forward secrecy? If so, how?
7. Do you provide users with DH key files?
8. How do you authenticate clients – with certificates and keys or usernames and passwords?
9. Do you use HMAC-based TLS authentication? If so, why?
10. Do you ever send usernames and passwords to clients via email?
11. Does each client have a unique client certificate and key?
12. Where are your VPN gateway servers located – hosted, in one place, or on-premises?
13. Do any of your VPN gateway servers run on VPS or cloud servers?
14. How are your servers secured?
15. Where is user account information stored?
16. How is the security of communication between servers ensured?
17. Is port forwarding allowed for users?
18. Are all client ports forwarded by default? If so, on which servers?

Answers​

1. In recent years, this limitation has become less common, but some providers use it at free tiers so potential customers can try their services before switching to a paid plan. Usage limits for paid subscriptions are more characteristic of VPN resellers, so it's best to avoid providers that impose them.
2. The best answer depends on your goals. It's natural to want the fastest connection possible. However, if you have a very fast connection with the provider, you may be transmitting much more traffic than any other user on your VPN exit. This can reduce your anonymity.
3. Using a VPN with a large number of addresses can sometimes be convenient for working under multiple aliases at the same time. Additionally, you may want to connect from multiple devices simultaneously. However, this also contributes to account sharing abuse, which can overload VPN servers and slow down your connection.
4. Most VPN services offer only single-hop connections. This means you connect to a VPN gateway server, and your traffic exits to the internet from that same server or possibly from another server on the same local network. With a single-hop connection, it's easy for attackers to log incoming and outgoing traffic.
5. OpenVPN can operate in two different modes. In one of them, authentication and encryption are performed using a shared static key. While this mode is very easy to set up, compromising the key allows an adversary to decrypt all previous traffic. No self-respecting provider uses this method. But if you receive only one key file from the provider, open it in a text editor and look at the last line. If it includes 'CERTIFICATE', then everything is fine. But if it contains 'KEY', demand a refund. The other mode of OpenVPN 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 these data channel keys, they will only be able to decrypt that traffic, but not any past or future traffic. In other words, "perfect forward secrecy" is configured. By default, OpenVPN uses 1024-bit RSA for certificates authenticating SSL/TLS handshakes of the control channel and BF-CBC (128-bit) as the data channel cipher. This is likely sufficient in most cases. However, it can be argued that providers using 2048-bit RSA and AES-256-CBC (256-bit) are generally more attentive to security. Both BF-CBC and AES-256-CBC operate in Cipher Block Chaining (CBC) mode. If your provider uses something else (CFB, OFB, etc.), they are either incompetent or have very good reasons for doing so. Find out what those reasons are. The recently emerged VPN protocol WireGuard has gained rapid adoption among VPN providers. This protocol wasn't designed with commercial VPN services and their privacy considerations in mind. Capable providers should demonstrate that they have solutions for the following issues: 1. Public peer IP addresses are stored in memory (e.g, adding key management that removes/restores configuration) 2. Distribution/rotation of tunnel IP addresses (e.g, using callbacks that generate new IP addresses distributed among all servers) 3. Lack of perfect forward secrecy (e.g, using automatic regeneration of key pairs at regular intervals).
6. Any provider using OpenVPN in SSL/TLS mode ensures perfect forward secrecy. Any additional hand-waving beyond this should raise suspicions. As mentioned earlier, the implementation of WireGuard requires special measures to support forward secrecy.
7. This is a trick question. It's true that OpenVPN uses static Diffie-Hellman key files to ensure perfect forward secrecy. But this static Diffie-Hellman key file ('dh1024.pem' or 'dh2048.pem') is only needed on the server. Any provider that provides them to users is incompetent.
8. In SSL/TLS mode, OpenVPN clients authenticate servers by checking if the server has a certificate signed by a certificate authority ('a.crt') provided by the provider. OpenVPN supports two methods of client authentication by servers. One is based 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 excess. For p2p 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, this is not a problem since clients simply see the internet. Additionally, for VPN services, providing each client with a unique certificate poses a privacy risk.
9. With TLS authentication enabled (via tls-auth), servers ignore SSL/TLS handshake packets from clients that do not have the correct HMAC signature. This feature protects VPN servers from DoS attacks, port scanning, and other attacks. If this feature is implemented, providers can provide a key (usually 'ta.key') or it can be negotiated on the fly. Partly, this is a trick question. Any provider claiming this is necessary for perfect forward secrecy is either dishonest or incompetent.
10. This is a dangerous practice, primarily for the provider. Malicious actors who compromise usernames and passwords during delivery can gain free access or even lock paying users out by changing passwords. There is also a risk that attackers could involve users in criminal activities. Even in this case, if you successfully change your password immediately after receiving it, you are safe. If you cannot log in to change your password, complain and demand a new account. For providers that are otherwise attractive, this is not a fatal error.
11. This is another trick question. A provider might provide the same client certificate for all clients or not provide it at all and rely on usernames and passwords for authentication. It may seem like a good idea for each user to have their own certificate and key, and this is true in an enterprise context. However, for VPN services, this is very risky, as it could potentially link user accounts to logged traffic. Some providers explain that they issue unique client certificates to facilitate the neutralization of malicious clients. However, this can be done just as easily with usernames, and usernames are more easily invalidated than certificates. If this is a key issue for you, it can be easily verified by purchasing two short-term subscriptions, paying with Bitcoin through Tor, and using temporary email addresses with services like CIS benchmarks, etc.
12. This is partly another trick question. We would be very suspicious of any VPN provider claiming that their servers are managed in-house. You might ask how they cover the costs of maintaining facilities with high-speed lines in multiple countries. The most plausible answer is that they build their own servers and send them to colocation facilities. Extra points for server protection. Typical physical security measures include embedding RAM in thermoplastic glue and disabling USB ports. The most likely acceptable answer is the use of dedicated servers. Extra points for server hardening measures such as using full disk encryption and storing short-term logs in memory (tempfs).
13. Providers should never host 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 actions and data are easily accessible through the host. Providers should always use dedicated physical servers that are properly secured against unauthorized access.
14. VPN services typically use servers that play three roles. There are gateway servers that establish VPN connections with clients and route client traffic to the internet. With a single-hop connection, all these functions can be performed by one server. There are servers that host the service's website. There are also servers that manage user account information and provide authentication services to gateway servers and web servers. All client traffic is routed through gateway servers. If these servers are not properly secured, adversaries can compromise them and thereby violate user privacy by logging their traffic. VPN gateways must be hardened according to industry standards, such as CIS benchmarks or NSA guidelines. Most importantly, VPN gateway servers should not run other network services, such as web hosting or user account authentication. This significantly increases risks. You can check which ports and services are available on the VPN gateway using a port scanner like nmap. However, keep in mind that many providers open VPN servers on non-standard ports, such as 80 (HTTP) and 443 (HTTPS), to bypass firewall blocks.
15. Ideally, providers should store this information on their own servers, which are appropriately encrypted and protected from malicious actors. Additionally, they should separate authentication data, which must be accessible to gateway servers, from account credentials that may include private user information, such as logs, email addresses and payment records.
16. Well-designed VPNs include networks of specialized servers with different functions that securely interact with each other. For example, gateway servers should communicate with authentication servers to verify that users are authorized to connect. There are also internal provisioning systems that use sales data from websites to create and update user accounts and then update authentication servers. Given the sensitivity of this data and its value to attackers, all communications between these servers should be securely encrypted. This is most often achieved using persistent OpenVPN or IPSec tunnels between servers.
17. When you are connected to a VPN, the gateway server protects your device from potentially hostile incoming connections just like a router or firewall in a local network. However, allowing incoming connections on specific ports is necessary for running servers or participating in p2p networks, where your node needs to be visible to other nodes. This process is called port forwarding. When port forwarding is enabled, your device directly connects to the internet through the forwarded ports, without any protection from the VPN service. A malicious actor could successfully exploit a vulnerability in the service listening on the forwarded port and compromise your device. In addition to typical consequences, such as being part of a botnet and data theft, an adversary could violate your privacy and anonymity.
18. Some VPN services forward all client ports by default. Some do this only on specific servers. In some services, port forwarding varies across different servers without any scheme or documentation. While this can be checked using port scanning, the issue is that different clients using the same exit IP address may have the same ports forwarded.