- Joined
- Feb 17, 2007
- Messages
- 678
- Reaction score
- 1,026
- Points
- 93
Selecting a VPN Service
Introduction
Choosing a VPN service can be a nerve–wracking ordeal. You’ve probably read about the Snowden leaks and NSA related revelations. You probably don’t trust your ISP to protect your privacy (and as the FTC recently concluded, you really shouldn’t). Perhaps you don’t trust your government. You may even distrust all governments and corporations.
Indeed, you may not trust this guide, and think that it’s just an advertorial. While that’s an understandable concern, I invite you to read on, and judge for yourself. I also invite you to read this in the context of my other writings about VPNs, Tor and such, primarily on Wilders Security Forums and Tor.StackExchange.
If you’re especially concerned about privacy, you may want to obscure your research about VPN providers. Although many people use VPN services, extensive research might flag you as someone with something important to hide. You can mitigate that risk by using a free VPN service at this step (such as Calyx VPN) and free webmail (such as VFEmail). For even better privacy, you can add the Tor Browser Bundle to tunnel Tor through CalyxVPN, and use VFEmail’s hidden service.
Relatively little reliable and trustworthy information about VPN services is available online. It’s generally best to ignore ‘best VPN’ and ‘VPN review’ sites. Most feature paid reviews, and some are protection rackets, featuring bad reviews for VPN services that refuse to buy favorable reviews. Even the honest ones are typically just popularity contests, dominated by clueless torrent users and wannabe ‘hackers’. If you ever need to get information from a dedicated VPN review source look for those that don’t use affiliate parameters on outgoing links (or even better, remove referer information).
TorrentFreak’s Surveys
TorrentFreak’s VPN surveys are notable exceptions to the norm. In late 2011, it became clear that Luzlsec member ‘Recursion’ had been identified and arrested based on connection logs that the VPN service HideMyAss provided to the FBI. TorrentFreak responded by publishing ‘Which VPN Service Providers Really Take Anonymity Seriously?' (now rephrased as “Which VPN Providers Really Take Privacy Seriously?"). This Q&A has been updated yearly since the original version, now supplying unedited answers to 12 privacy-related questions.
These are the following (as of 2021):
- Do you keep (or share with third parties) ANY data that would allow you to match an IP-address and a timestamp to a current or former user of your service? If so, exactly what information do you hold/share and for how long?
- What is the name under which your company is incorporated (+ parent companies, if applicable) and under which jurisdiction does your company operate?
- What tools are used to monitor and mitigate abuse of your service, including limits on concurrent connections if these are enforced?
- Do you use any external email providers (e.g. Google Apps), analytics, or support tools ( e.g Live support, Zendesk) that hold information provided by users?
- In the event you receive a DMCA takedown notice or a non-US equivalent, how are these handled?
- What steps would be taken in the event a court orders your company to identify an active or former user of your service? How would your company respond to a court order that requires you to log activity for a user going forward? Have these scenarios ever played out in the past?
- Is BitTorrent and other file-sharing traffic allowed on all servers? If not, why? Do you provide port forwarding services? Are any ports blocked?
- Which payment systems/providers do you use? Do you take any measures to ensure that payment details can’t be linked to account usage or IP-assignments?
- What is the most secure VPN connection and encryption algorithm you would recommend to your users?
- Do you provide tools such as “kill switches” if a connection drops and DNS/IPv6 leak protection? Do you support Dual Stack IPv4/IPv6 functionality?
- Are any of your VPN servers hosted by third parties? If so, what measures do you take to prevent those partners from snooping on any inbound and/or outbound traffic? Do you use your own DNS servers?
- In which countries are your servers physically located? Do you offer virtual locations?
Introducing their results, they note:
Choosing the right VPN can be a tricky endeavor. There are hundreds of VPN services out there, all promising to keep you private but some are more private than others. To help you pick the best one for your needs, we asked dozens of VPNs to detail their logging practices, how they handle torrent users, and what else they do to keep you as anonymous as possible.
This is arguably a fairly comprehensive starting list. TorrentFreak staff seem dedicated and knowledgeable, and their earlier surveys attracted the attention of many providers that had been omitted. But there are two key limitations. First, more obscure and low-key privacy-friendly VPN services don’t appear on the TorrentFreak lists (e.g. cryptostorm). Some providers don’t cater to BitTorrent users and have no motivation to appear on this list. Second, TorrentFreak is, for the most part, merely summarizing VPN providers’ responses, and has not verified any of their claims. Comments in both reviews are also worth reading, by the way, but can’t always be taken seriously.
Even so, revelations about three providers – EarthVPN.com, Proxy.sh and PureVPN – demonstrate the risk of relying on providers' privacy claims. In early 2013, an EarthVPN customer was reportedly arrested based on logs kept by its hosting provider in the Netherlands. EarthVPN denied responsibility, maintaining that they ‘do not keep logs’, and said that they no longer use that provider. Although the actual dialog between EarthVPN and its customer (here and here) is no longer openly accessible, there are quotes and discussion in the AirVPN forums. Also, keep in mind that ISPs can log as easily as hosting providers can.
In TorrentFreak’s 2011 and 2013 surveys, Proxy.sh responded: ‘No information whatsoever is being recorded or held in our facilities. Our services are run from RAM and all our system services come with state-of-the-art configuration that ensures nothing is left after usage.’ However, in late September 2013, they installed Wireshark on one of their US servers, and retained packet captures for several hours. This was reportedly a voluntary response to complaints about hacking and harassment by one of their customers. For more specifics, see these TorrentFreak articles (here and here). In TorrentFreak’s 2014 survey, Proxy.sh answered as follows to the first question:
We do not keep any logs and we do not record any IP-address, headers or anything. In terms of time stamp, we only record those associated with support tickets creation and update (invoices and renewals are only recorded by date) for management purposes. The only personal information we do record is an email address and a payment type, that corresponds to either the word “Money” or “Bitcoin”. This is made clear in our privacy policy. Our system will also hold services credentials, namely the account password and network login/password pair. All this data can be permanently removed at any time on customer’s request. All other data and information involved in our operations (connections, traffic, etc.) is neither monitored nor recorded.
A more recent example of VPN provider caught lying about keeping no logs came in 2017. As reported in BleepingComputer the FBI have arrested a cyberstalking suspect with the help of IP address logs obtained from PureVPN. PureVPN claimed (and still claims) they keep no logs about customer activities.
Conversely, these incidents also demonstrate that news spreads very quickly on the Internet. With all of that in mind, I recommend starting with VPN services that meet the following criteria:
- It appears in TorrentFreak’s survey (adding others to your shortlist that you think were improperly omitted).
- It’s not listed as logging in TorrentFreak’s surveys.
- It has been in business for at least three years.
- An hour or so of Web searching reveals no evidence of privacy violations.
Further positive signals you can look for:
- Open source VPN applications.
- Publicly available audit results from independent, third-party auditors that investigate no-logs claims. Audits however, are constrained by their scope and provide only a temporary view, they are not persistent proofs about claims.
All of the VPN services in TorrentFreak’s recent survey deny keeping persistent logs. Assessing the plausibility of such claims in the context of pursuant data-retention requirements is a can of worms. Claims that there are no data-retention requirements in the US seem laughable in light of NSA documents released by Edward Snowden. The situation in Europe is complicated since the passing of GDPR and tensions between the 1995 Data Protection Directive and national legislations. The exact extent of NSA spying and EU collaboration with US operations is unknown and adds more uncertainty. For more about this issue generally, see EFF’s summary page.
Presales Questions
In focusing your search, it’s important to select VPN providers that support your specific privacy goals. I recommend carefully browsing providers' websites, and carefully reading their terms of service and privacy policy. Look for clear and unambiguous language, and be suspicious of legalese boilerplate.
For example, if you plan to share copyrighted media via BitTorrent, it’s obviously best to avoid providers that explicitly discourage such use. If the availability of numerous exit IP addresses is important, choose accordingly, but consider the tension between variety and security. It’s arguably more likely that providers with numerous exits are using virtual private servers.
In contacting providers with presales questions, start with basic questions, such as #1, #3, #5 and #7 from the TorrentFreak list. It’s generally best to ask questions for which you have reliable and independent answers. However, at least initially, it’s also best to ask without revealing what you’ve already learned.
How prospective VPN providers answer your questions can be as informative as the answers they give. You want answers that are prompt, complete, clear and accurate. Vague or incorrect answers to technical questions imply dishonesty and/or incompetence. Delayed answers don’t bode well for future customer support.
Here are some additional questions that you might ask, followed by expected answers and explanations. For technical questions, the OpenVPN manual and How-to, and WireGuard’s official page are useful resources.
- Is there a monthly bandwidth-usage limit?
- Do you throttle connections that use excessive bandwidth?
- How many concurrent connections are allowed per account?
- How many hops are there in your VPN connections?
- What type(s) of VPN encryption do you use? Why?
- Do you support perfect forward secrecy? If so, how?
- Do you provide users with Diffie Hellman key files?
- How do you authenticate clients – certificates/keys, or usernames/passwords?
- Do you employ HMAC-Based TLS Authentication? If so, why?
- Do you ever email usernames and passwords to customers?
- Does each customer have a unique client certificate and key?
- Are your VPN gateway servers hosted, co-located or in-house?
- Are any of your VPN gateway servers running on VPS or cloud servers?
- How are your VPN gateway servers protected?
- Where is user account information stored?
- How is communication between servers secured?
- Do you allow port forwarding by users?
- Are all client ports ever forwarded by default? If so, on which servers?
Answers
- Is there a monthly bandwidth-usage limit? This restriction has become less common in recent years. Some providers use them for free tiers so prospective customers can sample their service before committing to a paid plan. Usage limits for paid subscriptions are more common for VPN resellers, so it’s probably best to avoid providers that impose them.
- 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.
New-kid-on-the-block VPN protocol WireGuard has seen a rapid adoption among VPN providers recently. The protocol was not designed with commercial VPN services and their privacy considerations in mind. Capable providers need to demonstrate they have solutions to the following problems: 1. Public IP address of peers are stored in memory (e.g. adding key management that deleted/reinstates configuration) 2. Tunnel IP address allocation/rotation (e.g. using backend calls generating new IP adresses that are distributed to all servers) 3. No perfect forward secrecy (e.g. use automatic key pair regeneration in regular time intervals). - 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. As noted before, WireGuard implementation requires specific measures to support forward secrecy.
- Do you provide users with Diffie Hellman key files? T his 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 (‘a.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.
Source
Original message
Выбор VPN-сервиса
Возможно, вы не доверяете своему интернет-провайдеру в вопросах защиты конфиденциальности (и, как недавно заключила FTC США, вам действительно не стоит этого делать). Возможно, вы не доверяете своему правительству. Возможно, вы даже не доверяете всем правительствам и корпорациям. Как бы то ни было, если вы по натуре любите исследовать вещи, прежде чем начинать ими пользоваться, это руководство будет полезно.
Если вас особенно беспокоит конфиденциальность, вы, вероятно, захотите не делать свое исследование о VPN-провайдерах достоянием общественности. Хотя многие люди пользуются VPN, глубокие исследования могут выдать вас за человека, которому есть что скрывать. Вы можете уменьшить этот риск, используя на этом этапе бесплатные VPN (например, Calyx VPN) и веб-почту (например, VFEmail). Для еще большей конфиденциальности можете использовать реализацию VFEmail в сети Tor.
В интернете относительно мало надежной и заслуживающей доверия информации о VPN-сервисах. Рекомендуем игнорировать сайты с заголовками "лучшие VPN" и "обзоры VPN". Большинство из них содержат проплаченные обзоры, а некоторые просто размещают плохие отзывы о VPN-сервисах, которые отказываются покупать благоприятные отзывы. Даже честные сайты, как правило, просто составляют списки популярных сервисов, не задумываясь над качеством. Если вам когда-нибудь понадобится получить информацию из специализированного источника обзоров VPN, ищите те, которые не используют партнерские программы в исходящих ссылках (рефералки).
При поиске важно выбрать провайдеров VPN, которые помогут решить ваши конкретные цели по обеспечению конфиденциальности. Рекомендуем тщательно изучить веб-сайты провайдеров и внимательно прочитать их условия предоставления услуг и политику конфиденциальности. Ищите четкие и недвусмысленные формулировки и с подозрением отнеситесь к юридическому шаблону.
Например, если вы планируете обмениваться защищенными авторским правом медиафайлами через BitTorrent, лучше избегать провайдеров, которые прямо запрещают такое использование. Если для вас важна доступность многочисленных локаций, выбирайте соответствующим образом, но учитывайте противоречие между разнообразием и безопасностью. Более вероятно, что провайдеры с многочисленными IP-адресами в разных странах используют виртуальные частные серверы вместо физических выделенных.
То, как потенциальные поставщики VPN отвечают на ваши вопросы, может быть столь же информативным, как сами ответы. Вам нужны быстрые, полные, ясные и точные ответы. Неясные или неправильные ответы на технические вопросы свидетельствуют о нечестности и/или некомпетентности. Несвоевременные ответы не сулят ничего хорошего относительно будущей поддержки клиентов.
Ниже приведены некоторые вопросы, которые вы можете задать VPN-провайдеру перед покупкой , а также ожидаемые ответы и объяснения. Для технических вопросов полезными ресурсами являются руководство по OpenVPN и How-to, а также официальная страница WireGuard.
Вопросы
- Существует ли ежемесячный лимит использования полосы пропускания?
- Ограничиваете ли вы соединения, превышающие лимиты пропускной способности?
- Сколько одновременных подключений разрешено для одной учетной записи?
- Сколько хопов в ваших VPN-соединениях?
- Какой(ие) тип(ы) шифрования VPN вы используете? Почему?
- Поддерживаете ли вы perfect forward secrecy? Если да, то каким образом?
- Предоставляете ли вы пользователям файлы ключей DH?
- Как вы аутентифицируете клиентов – сертификаты и ключи или имена пользователей и пароли?
- Используете ли вы аутентификацию TLS на основе HMAC? Если да, то почему?
- Отправляете ли вы когда-нибудь имена пользователей и пароли клиентам по электронной почте?
- Имеет ли каждый клиент уникальный клиентский сертификат и ключ?
- Где размещены ваши серверы VPN-шлюзов – на хостинге, в одном месте или внутри компании?
- Работают ли какие-либо из ваших серверов VPN-шлюзов на VPS или облачных серверах?
- Как защищены ваши серверы?
- Где хранится информация об учетной записи пользователя?
- Как обеспечивается безопасность связи между серверами?
- Разрешена ли переадресация портов пользователями?
- Все ли клиентские порты переадресованы по умолчанию? Если да, то на каких серверах?
Ответы
- Существует ли ежемесячный лимит использования полосы пропускания? В последние годы это ограничение стало менее распространенным, но некоторые провайдеры используют его на бесплатных уровнях, чтобы потенциальные клиенты могли попробовать свои услуги, прежде чем переходить на платный тарифный план. Ограничения использования для платных подписок более характерны для реселлеров VPN, поэтому лучше избегать провайдеров, которые их вводят.
- Ограничиваете ли вы соединения, превышающие лимиты пропускной способности? Лучший ответ зависит от ваших целей. Вполне естественно хотеть максимально быстрого соединения. Однако, если у вас очень быстрое соединение с провайдером, вы можете передавать гораздо больше трафика, чем любой другой пользователь, пользующийся вашим VPN-выходом. А это снижает вашу анонимность.
- Сколько одновременных подключений разрешено для одной учетной записи? Используя VPN с большим количеством адресов иногда удобно одновременно работать под несколькими псевдонимами. Кроме того, вы можете захотеть одновременно подключаться с нескольких устройств. Однако это также способствует злоупотреблению совместным использованием учетных записей, что может перегрузить серверы VPN и замедлить ваше соединение.
- Сколько хопов в ваших VPN-соединениях? Большинство VPN-сервисов предлагают только однохоповое соединение. То есть вы подключаетесь к серверу VPN-шлюза, и ваш трафик выходит в Интернет с этого же сервера или, возможно, с другого сервера в той же локальной сети. При однохоповом соединении злоумышленникам легко регистрировать входящий и выходящий трафики.
- Какой(ие) тип(ы) шифрования VPN вы используете? Почему? OpenVPN может работать в двух различных режимах. В одном из них аутентификация и шифрование осуществляются с помощью общего статического ключа. Хотя такой режим очень прост в настройке, компрометация ключа позволяет противнику расшифровать весь предыдущий трафик. Ни один уважающий себя провайдер не использует такой способ. Но если вы получили от провайдера всего один файл ключей, откройте его в текстовом редакторе и посмотрите на последнюю строку. Если она включает 'CERTIFICATE', то все в порядке. Но если он содержит 'KEY', потребуйте возврата денег. Другой режим OpenVPN использует SSL/TLS в качестве канала управления и шифрует канал данных периодически меняющимися статическими ключами. Если противнику удастся скомпрометировать один из этих ключей канала данных, он сможет расшифровать только этот трафик, но не любой прошлый или будущий трафик. Другими словами, настроена "совершенная прямая секретность" (Perfect Forward Secrecy). По умолчанию OpenVPN использует 1024-битный RSA для сертификатов, удостоверяющих подлинность SSL/TLS рукопожатий канала управления, и BF-CBC (128-битный) в качестве шифра канала данных. Этого, вероятно, достаточно в большинстве случаев. Однако можно утверждать, что провайдеры, использующие 2048-битный RSA и AES-256-CBC (256-битный), в целом более внимательны к безопасности. И BF-CBC, и AES-256-CBC работают в режиме Cipher Block Chaining (CBC). Если ваш провайдер использует что-то другое (CFB, OFB и т.д.), он либо некомпетентен, либо имеет на то очень веские причины. Выясните их. Недавно появившийся на рынке VPN-протокол WireGuard получил быстрое распространение среди VPN-провайдеров. Этот протокол не был разработан с учетом коммерческих VPN-сервисов и их соображений конфиденциальности. Способные провайдеры должны продемонстрировать, что у них есть решения следующих проблем: 1. Публичные IP-адреса пиров хранятся в памяти (например, добавление управления ключами, которые удаляют/восстанавливают конфигурацию) 2. Распределение/ротация IP-адресов туннеля (например, использование обратных вызовов, генерирующих новые IP-адреса, которые распределяются между всеми серверами) 3. Отсутствие идеальной прямой секретности (например, использование автоматической регенерации пары ключей через регулярные промежутки времени).
- Поддерживаете ли вы perfect forward secrecy? Если да, то каким образом? Любой провайдер, использующий OpenVPN в режиме SSL/TLS, обеспечивает идеальную прямую секретность. Дополнительные размахивания руками, выходящие за эти рамки, должны вызвать у вас подозрения. Как отмечалось ранее, реализация WireGuard требует специальных мер для поддержки прямой секретности.
- Предоставляете ли вы пользователям файлы ключей Diffie Hellman? Это вопрос с подвохом. Это правда, что OpenVPN использует статические файлы ключей Diffie Hellman для обеспечения идеальной прямой секретности. Но этот статический файл ключей Diffie Hellman ('dh1024.pem' или 'dh2048.pem') нужен только на сервере. Любой провайдер, предоставляющий их пользователям, некомпетентен.
- Как вы аутентифицируете клиентов – сертификаты/ключи или имена пользователей/пароли? В режиме SSL/TLS клиенты OpenVPN аутентифицируют серверы, проверяя, есть ли у сервера сертификат, подписанный центром сертификации ('a.crt'), который предоставил им провайдер. OpenVPN поддерживает два метода аутентификации клиентов серверами. Один из них основывается на сертификатах и ключах (таких как 'client.crt' и 'client.key'). Другой полагается на имена пользователей и пароли (через auth-user-pass). Серверы могут использовать и то, и другое, но это уже граничит с чрезмерностью. Для p2p-соединений, где на карту может быть поставлен полный доступ к сети, очень важно, чтобы серверы аутентифицировали клиентов с помощью сертификатов и ключей. Для служб VPN это не является проблемой, поскольку клиенты просто видят интернет. Кроме того, для служб VPN предоставление каждому клиенту уникального сертификата является риском для конфиденциальности.
- Используете ли вы аутентификацию TLS на основе HMAC? Если да, то почему? При включенной аутентификации TLS (через tls-auth) серверы игнорируют пакеты рукопожатия SSL/TLS от клиентов, у которых отсутствует правильная подпись HMAC. Эта функция защищает VPN-серверы от DoS-атак, сканирования портов и других атак. Если эта функция реализована, провайдеры могут предоставлять ключ (обычно 'ta.key') или он может быть согласован на лету. Отчасти это вопрос с подвохом. Любой провайдер, утверждающий, что это необходимо для идеальной прямой секретности, либо нечестен, либо некомпетентен.
- Отправляете ли вы когда-нибудь имена пользователей и пароли клиентам по электронной почте? Это опасная практика, и в первую очередь для провайдера. Недоброжелатели, скомпрометировавшие имена пользователей и пароли во время доставки, могут получить свободный доступ или даже заблокировать платящих пользователей, изменив пароли. Существует также риск того, что злоумышленники могут вовлечь пользователей в преступную деятельность. Даже в этом случае, если вы успешно смените пароль сразу после получения, вы в безопасности. Если вы не можете войти в систему, чтобы сменить пароль, жалуйтесь и требуйте новую учетную запись. Для провайдеров, которые в остальном привлекательны, это не фатальная ошибка.
- Имеет ли каждый клиент уникальный клиентский сертификат и ключ? Это еще один вопрос с подвохом. В качестве ответа на этот вопрос можно предоставить один и тот же сертификат клиента для всех клиентов или не предоставлять его вообще и полагаться на имя пользователя и пароль для аутентификации. Может показаться хорошей идеей, что у каждого пользователя должен быть свой сертификат и ключ. И это верно в контексте предприятия. Но для служб VPN это очень опасно, поскольку потенциально может связать учетные записи пользователей с регистрируемым трафиком. Некоторые провайдеры объясняют, что они выдают уникальные клиентские сертификаты, чтобы облегчить нейтрализацию злостных клиентов. Однако это так же легко сделать и с именами пользователей, а имена пользователей более легко теряют валидность, чем сертификаты. Если для вас это ключевой вопрос, его легко проверить, купив две краткосрочные подписки, заплатив биткоинами через Tor и используя временные адреса электронной почты с anonbox и т.д.
- Где размещены ваши серверы VPN-шлюзов – на хостинге, в одном месте или внутри компании? Отчасти это также вопрос с подвохом. Мы бы с большим подозрением отнеслись к любому VPN-провайдеру, утверждающему, что его серверы управляются собственными силами. Вы можете спросить, как они покрывают расходы на содержание мощностей с высокоскоростными линиями связи в нескольких странах. Наиболее правдоподобным ответом будет то, что они строят свои собственные серверные и отправляют их в места совместного размещения. Начисляйте дополнительные баллы за защиту серверов. Типичные меры физической защиты включают в себя встраивание оперативной памяти в термоклей, а также отключение USB-портов. Наиболее вероятный приемлемый ответ – использование выделенных серверов. Начислите дополнительные баллы за такие меры укрепления сервера, как использование полнодискового шифрования и хранение краткосрочных журналов в оперативной памяти (tempfs).
- Работают ли какие-либо из ваших серверов VPN-шлюзов на VPS или облачных серверах? Провайдеры никогда не должны размещать серверы VPN-шлюзов на виртуальных частных серверах (VPS) или облачных серверах. Будучи виртуальными машинами, они полностью контролируются операционной системой хоста, и все действия и данные легко доступны через хост. Провайдеры всегда должны использовать выделенные физические серверы, которые должным образом защищены от несанкционированного доступа.
- Как защищены ваши серверы? В VPN-сервисах обычно используются серверы, играющие три роли. Существуют серверы-шлюзы, которые устанавливают VPN-соединения с клиентами, а также маршрутизируют клиентский трафик в Интернет. При однохоповом соединении все эти функции может выполнять один сервер. Есть серверы, на которых размещается веб-сайт службы. Есть также серверы, которые управляют информацией об учетной записи пользователя и предоставляют услуги аутентификации серверам-шлюзам и веб-серверам. Весь клиентский трафик направляется через серверы-шлюзы. Если эти серверы не защищены должным образом, противники могут скомпрометировать их и тем самым нарушить конфиденциальность пользователей, регистрируя их трафик. Шлюзы VPN должны быть укреплены в соответствии с отраслевыми стандартами, пример: бенчмарки CIS или базовые рекомендации АНБ. Самое главное, серверы шлюзов VPN не должны работать с другими сетевыми сервисами, такими как хостинг веб-сайтов или учет и аутентификация пользователей. Это существенно повышает риски. Проверить, какие порты и службы доступны на VPN-шлюзе, можно с помощью сканера портов, например, nmap. Однако имейте в виду, что многие провайдеры открывают VPN-серверы на нестандартных портах, таких как 80 (HTTP) и 443 (HTTPS), чтобы обойти блокировку брандмауэра.
- Где хранится информация об учетной записи пользователя? В идеале поставщики должны хранить эту информацию на собственных серверах, которые соответствующим образом зашифрованы и защищены от недоброжелателей. Кроме того, они должны отделять данные аутентификации, которые должны быть доступны серверам шлюза, от учетных данных, которые могут включать частную информацию пользователей, такую как логи, адреса электронной почты и записи о платежах.
- Как обеспечивается безопасность связи между серверами? Хорошо продуманные VPN включают в себя сети специализированных серверов с различными функциями, которые безопасно взаимодействуют друг с другом. Например, серверы шлюза должны связываться с серверами аутентификации для проверки того, что пользователи авторизованы для подключения. Существуют также внутренние системы обеспечения, которые используют данные о продажах с веб-сайтов для создания и обновления учетных записей пользователей, а затем обновляют серверы аутентификации. Учитывая чувствительность этих данных и их ценность для злоумышленников, все коммуникации между этими серверами должны быть надежно зашифрованы. Чаще всего для этого используются постоянные туннели OpenVPN или IPSec между серверами.
- Разрешена ли переадресация портов пользователями? Когда вы подключены VPN, сервер шлюза защищает ваше устройство от потенциально враждебных входящих соединений так же, как это делает маршрутизатор или брандмауэр в локальной сети. Однако разрешение входящих соединений на определенные порты необходимо для работы серверов или для участия в сетях p2p, где ваш узел должен быть виден другим узлам. Этот процесс называется пробросом портов. Когда проброс портов включен, ваше устройство напрямую выходит в Интернет через проброшенные порты, без какой-либо защиты со стороны службы VPN. Недоброжелатель может успешно использовать уязвимость в службе, которая прослушивает проброшенный порт, и скомпрометировать ваше устройство. Помимо типичных последствий, таких как участие в ботнете и кража данных, противник может нарушить ваши конфиденциальность и анонимность.
- Все ли клиентские порты переадресованы по умолчанию? Если да, то на каких серверах? Некоторые VPN-сервисы по умолчанию пробрасывают все клиентские порты. Некоторые делают это только на определенных серверах. В некоторых сервисах проброс портов на разных серверах варьируется без какой-либо схемы или документации. Хотя это можно проверить с помощью сканирования портов, проблема в том, что у разных клиентов, использующих один и тот же IP-адрес выхода, могут быть проброшены одни и те же порты.
Оригинал
Русская адаптация
Last edited: