What you need to know before switching to VPN

VPN’s features and pitfalls from legal and technical standpoint

What you need to know before switching to VPN

In what will be our final chapter of our ‘Introduction to VPN‘ course, I will tell you something beyond the usual tech jabber on VPN. I’ll cover some technical and legal issues which are directly related to the use of VPN and provide some practical advice in the end.

What you need to know before switching to VPN

Technical aspects

An observant reader might recall that I put a considerable emphasis on correct implementation, setup and use of all kinds of VPN in the previous editions of our series. Even the most reliable version of the protocol is worthless if used improperly.

All VPN solutions we have previously covered had one thing in common: they include open-source implementations, which should be easier to check for vulnerabilities. However, in reality, there are other issues and peculiarities, besides those contained in the code.

The most obvious problem is the occasional disconnect of VPN which, consequently, all of a sudden, routes the traffic through a public network. For instance, it may well happen when a user is connected to a public Wi-Fi network or any other available mobile network. The worst case is when the user is not notified of that and the VPN connection is not re-established automatically.

In Windows 7 and higher, Microsoft introduced the VPN Reconnect feature. If you use an alternative platform, you would need to take advantage of customized routing settings or a so-called ‘kill switch’ feature. The latter monitors the status of the VPN connection. If it is lost, the traffic is blocked, all apps running are stopped, and the stem attempts to re-establish the VPN connection. Some commercial VPN clients offer similar functionality.

The second VPN leak, which is far less obvious and frequent, is related to the IPv6 protocol. Although IPv6 is still rarely used in the wild, all major operating systems have this protocol enabled by default, whereas VPN mostly uses IPv4.

What may happen in this regard is the situation when IPv6 is supported on a public network, and the client may as well connect to a resource which uses the same version of the protocol, thus routing traffic to a public IPv6 network by default. The simplest measure here would be to fully disable IPv6 support on the system level.

Of course one can route all the traffic into the VPN, but it would require both server-side support and particular settings on the client side. Research conducted in 2015, offered VPN providers a gentle nudge and they started to seek appropriate solutions for their clients.

The research also cites the third issue: DNS leaks. In the best-case scenario when a user connects to VPN, all DNS requests should not leave the VPN network and be processed by corresponding DNS servers. Otherwise, known trusted servers like Google Public DNS or OpenDNS should be configured in the network on installation. Alternatively, one can use VPN bundled with services like DNSCrypt. The latter serves to encrypt and verify DNS requests/responses authenticity, which is also quite useful in many other cases.

In real life, those recommendations are rarely followed, and people use DNS servers offered by the public network. Surely, the response acquired from those servers might be incorrect and even fake, which is a great opportunity for adversaries practicing farming. The collateral damage of the DNS leak would be the compromise of privacy: an outsider may find out DNS servers’ addresses, thus figuring out the name of the ISP and more or less accurate location of the user.

Those using Windows are even in a graver situation than could be imagined. Whereas Windows 7 would try all known DNS servers one by one and wait to get a response, Windows 8/8.1 makes things faster by simultaneously sending requests to all known DNS servers on all known connections. If the preferable server does not return the response in one second, another available connection may be used. However, in case of VPN, it might take a network longer to return a DNS response. The good news here is that this capability can be switched off manually; the bad news is that it would involve tedious manipulations with the system register.

In Windows 10, things are even worse. This OS also sends DNS requests everywhere and uses the response which turns up the quickest. There is no good news in that case, though: this uber-useful feature cannot be disabled on the system level.

There is also a severe vulnerability in WebRTC. This technology, enabled in the browser, was initially designed to provide a direct link between two networking nodes and is used primarily for audio and video calls. The leak is very probable, because WebRTC calls all available network connections simultaneously and then uses the first to respond.

The same lack of control can be found in other plugins like Java or Adobe Flash, if not in all software. Besides, they are a really serious threat to one’s privacy, since we review the ways to protect a user on the public network.

Legal peculiarities

The first and the foremost issue with VPN concerns the differences in legislation in various countries: a VPN client might be in one country, and a VPN server might be located is some other country, however friendly that country could be. Alternatively, the traffic might be transited through some third party countries. Even if you don’t violate any laws, your data might be captured and analyzed in transit.

In general, it’s baffling to know that the secure traffic can be decrypted, even several years after. The very fact of using a VPN might provoke unnecessary attention from the law enforcement (what if someone is hiding something via that VPN?).

It may happen that VPN is absolutely ok to use, but technically the use of such technology is limited (see examples from a previous edition or any available information on PRISM).

However, all legal issues more often originate from the use of strong encryption rather than VPN itself. It’s obvious that any country would like to protect its own information and get hold of someone else’s data, which is essentially the reason why cryptography is so heavily regulated.

In the US, arguably the IT leader among other countries, the situation is very curious. New encryption standards are to be first approved by NIST (The National Institute of Standards and Technology). However, these standards vary in strength: the encryption is more resilient for domestic market and is weakened for exported products. What is tricky is that hardware and software companies who strive for government contracts should stick to these regulations.

We don’t need to remind you where the most popular operating systems and encryption components, including VPN modules, are produced. This issue is much worse than probability of backdoors. It turns out that the networking technologies which ought to become industry standards, might be vulnerable from the start.

As a proof, back in 2013 NIST was accused of having allowed NSA to use a vulnerable version of pseudo-random number generator as the basis for the new encryption standard. In theory, it would allow to ease the effort required to decrypt ‘protected’ information.

Suspicions started to arise some months after the new standard was published. However, the regulator used to be blamed for deliberately issuing overly sophisticated description for published standards and recommendations. The draft descriptions were so murky that even encryption professionals were not able to see the catch immediately. I’d like to highlight here that not only the implied resilience and security matter — the practical implementation is equally important.

In conclusion

To wrap up this article, I’d like to share one useful link: it’s a table describing popular VPN providers. It’s very easy to use: the more green cells the line contains, the more reliable the corresponding provider is. If you are tempted to use VPN but don’t want to study a variety of technical and legal aspects, this table is what you need. The most important thing is to accurately follow the instructions offered by a provider and keep in mind a simple mantra: Better safe than sorry.