What you need to know before you switch to a VPN

The importance of properly implementing, configuring, and using a particular type of VPN. Even the highest quality protocol architecture can easily collapse if not used as intended.

The advantage of all VPN solutions is the availability of open-source implementations, which in theory allows you to identify vulnerabilities. In practice, there are many other problems and subtleties without digging deep into the code.

The most obvious is the periodic disconnection of the VPN connection and, as a consequence, the sudden release of traffic into the public network. For example, in the case of the same open access points or any mobile networks. The worst is when this happens without explicitly notifying the user and without automatically restoring the VPN connection.

Microsoft has introduced VPN Reconnect on Windows 7 and newer systems. For all other platforms, it is necessary to use special routing settings or “fuse” programs vpn kill switch. They monitor the status of the VPN connection and in case of a VPN break, they first block all traffic and/or terminate the selected applications and then try to restore the VPN connection. Similar functionality is available in some commercial VPN clients.

The second, less obvious and so far infrequent VPN “leak” concerns IPv6. Although IPv6 is rare in real-world communication networks, almost all modern operating systems have this protocol enabled by default, while VPN works most often with IPv4.

Therefore, it is quite realistic to have a public network that supports IPv6 and a client can access a resource that also supports it – as a result, traffic will default to an open IPv6 network. The easiest defense is to completely disable IPv6 in the operating system.

Yes, it is possible to drive all traffic inside a VPN, but that requires both server-side support and client-side configuration. After a study published in the summer of 2015, VPN providers got excited and started looking for solutions for their customers.

The same study also talks about the third nuance – “DNS leaks”. Ideally, when connecting to a VPN, all DNS requests should also go inside the virtual network and there handled by their own DNS-servers. Or at least you should register more or less trusted servers like Google Public DNS or OpenDNS when setting up the connection. An alternative option is to use services like DNSCrypt in conjunction with VPN. The latter also encrypts and authenticates DNS requests and responses, which can be useful in normal life.

In practice, this is not always done, and DNS servers issued by a public network are often used. Obviously, the response from them may be incorrect, and instead of the real address of the requested domain user will receive a fake one – a great chance for pharming! A side effect of the “DNS leak” – a blow to anonymity, ie the possibility to find out the addresses of the DNS-servers of the user and thus get information about his Internet service provider and the approximate location.

The situation with Windows is worse than one would assume. Whereas Windows 7 polled known DNS servers one by one and waited patiently for a response, Windows 8/8.1 polls all known DNS servers on all known network connections in parallel to speed things up. If the primary server does not respond within a second, then the response of the other one is used immediately. And the DNS query via VPN may well be late. The good news is that it is possible to disable this unnecessary “care”. The bad news is that you will have to manually work with the registry to do it.

FYI Windows 10 sends queries to all known DNS servers in the system at once, not in order; if you have a VPN, be prepared for a DNS Leak.

In Windows 10, things are even sadder. In this operating system, DNS queries are also sent out to “all parties” at once, and the one from which the first answer comes is used. And there is no good news in this case: it is no longer possible to disable this very useful function by means of the operating system.

Another potentially dangerous breach lies in WebRTC. This technology was originally invented for direct communication between two network nodes directly in the browser and is used mostly for audio and video communications. The “leak” is that the WebRTC module accesses all network connections at once and can use any of them.

Similarly, other modules like the Java Plugin or Adobe Flash, or any software in general, can be out of control. However, this is more detrimental to anonymity, and, remember, we are still considering the case of user protection when connecting to public networks.

The first and most obvious aspect is the differences in the laws of the countries. After all, the VPN-client can be in one country, and the VPN-server in another, albeit conditionally friendly. Or the traffic can simply transit through third countries. And even if you do not violate anything, it does not prevent in theory to keep a “snapshot” of all transmitted and received data on either side for further examination.

In general, it is not very pleasant when protected traffic is decrypted even several years later. Moreover, even the very use of VPN connections is already a signal to the relevant services: “Why did someone suddenly decide to hide something?”

It also happens that the use of VPNs is not technically forbidden, but access to such technologies is still technically restricted. In general, see the example in the previous article or any material on PRISM.

However, more often than not, the legal aspects are not so much related to the use of VPNs, as to the use of encryption, especially strong encryption. Obviously, any state seeks to better protect its information and quickly get hold of someone else’s, and therefore regulates cryptography by law.

For example, there are special rules regarding the import/export of “encryption (cryptographic) equipment” in the Customs Union. In particular, due to such regulatory documents, some manufacturers of network equipment (including for organizing VPN) by default disable a number of encryption algorithms in their products when exporting to other countries and/or forcibly reduce the maximum possible key length.

In the United States, the obvious leader in IT, the situation is even more interesting. New encryption standards are approved by NIST (The National Institute of Standards and Technology), and in several versions: for domestic use, more reliable, and for export, weaker. The trick is that software and hardware manufacturers must comply with these standards in order to win government contracts – and this is always the tidbit of profit for any company.

Do I need to remind you where, for example, all the most common operating systems are produced, as well as their cryptographic components, including VPN modules? The problem is deeper than the presence of potential backdoors. The problem is that the accepted encryption standards themselves, which are in fact becoming worldwide, may be inherently vulnerable.

As a matter of fact, NIST had already been accused in 2013 of allowing the NSA to include a vulnerable version of the pseudorandom number generator, a key component of modern cryptography, into the new standard seven years earlier. In theory, this would have made it much easier to decrypt information “protected” by such a generator.

The first suspicions arose several months after the publication of the standard. However, regulators were repeatedly accused of deliberately complicating the descriptions of published standards and recommendations. Even professionals, when discussing drafts publicly, may not be able to spot the trick right away. Once again I would like to emphasize that it is not only the theoretical reliability and safety of any technology that is important, but also its practical implementation.