We have already told you about VPNs. Today, we look at its implementations by analyzing the pros and cons. By definition, VPN is a versatile concept, and it isn’t easy to immediately understand whether implementations are VPNs or not. The Internet’s predecessor, ARPANET, could also be considered a VPN. Strangely, almost all networking concepts and, more clearly, protocols began as technologies for businesses and only later became an asset for the average user.
Well, today, we are interested in something other than history or corporate infrastructure. In this post, we will analyze standard VPN implementations—the ones that a user without technical skills might encounter. First, we’ll look at those implementations that help protect users when connected to a public Wi-Fi network or bypass certain IP protocol-based restrictions imposed by a provider.
Typically, consumer-facing VPN services leverage the capabilities of standard operating systems and provide step-by-step instructions for establishing a secure connection. Recently, VPN has made a giant leap forward in terms of simplifying the process: the average user doesn’t need all that technological nonsense; they need to follow basic instructions like “pay here, download apps here, press here, and enjoy”. But in some cases, it makes sense to know how VPN implementations differ from each other.
Common VPN Implementations
PPTP (Point-to-Point Tunneling Protocol) was developed about 20 years ago, which is both its advantage and its main disadvantage. The most important benefit is its compatibility with almost all operating systems, even legacy ones, which makes the protocol highly universal and available. Furthermore, it is reasonable in terms of computing power when compared to more recent solutions.
But its advanced age also justifies its main disadvantage: compared to today’s security realities, it offers a considerably lower level of protection. Its cryptographic methods were significant in the mid-1990s. Still, today, they need to be more secure, a problem that is amplified by a flawed architecture and a number of weaknesses in Microsoft’s more common implementation.
Furthermore, in reference to PPTP, encryption is not offered by default, and it would take an attacker, with the production hardware available today, less than 24 hours to crack the password. However, in situations that don’t require a super-secure connection or when other VPN connections are unavailable, it’s better to use PPTP with weak encryption than to have no protection at all.
I once found myself in a tricky situation: I was headed to a country known for certain Internet restrictions (you know what I’m talking about). I used our corporate PPTP server located in my country to send emails, which were delivered with a delay of approximately two days to two weeks. One can only imagine where those emails were for all that time. Meanwhile, the use of an alternative and, therefore, a more secure VPN connection could have been improved.
This story shows that the PPTP needs to be more robust to protect you from powerful bodies like governments or corporations. L2TP (Layer 2 Tunneling Protocol) is quite similar to PPTP. These two standards were developed and enabled practically at the same time. Although L2TP is considered more efficient for virtual networks, it is also more demanding in terms of computing power. Providers and entrepreneurs generally prefer it. By the way, L2TP does not provide encryption by default and goes together with other protocols (usually IPSec).
IPSec (Internet Protocol Security) is a standard protocol package that includes various security measures. This bundle is suitable for multiple types of secure connections. The first developments of IPSec date back to the early 1990s, but its basic concept is constant improvement and updating in accordance with technological developments, so it is not a static distinction. It is obvious what type of entity it was developed for. IPSec includes a dozen standards (each with more than one implementation), which could be used to facilitate secure connections at all levels.
It is certainly good in terms of architecture, reliability of its cryptographic algorithms, and potential. IPSec also has its flaws. First, it is not easy to set up for the average PC user, and if it is misconfigured, its security can be compromised. Furthermore, as already mentioned, it is used in a bundle with many other protocols. Second, it is demanding in terms of computing power. This drawback is partly offset by the use of hardware acceleration of AES cryptographic algorithms (which are usually offered in current IPSec implementations, among other algorithms).
This feature of AES hardware acceleration is used in today’s mobile and desktop processors, as well as Wi-Fi routers, etc. To our dismay, technologies created by theorists (especially groups of mathematical experts) are concretized by practical minds who sometimes lack the knowledge and understanding of science. The issue here is the incorrect use of the protocols that initiated a secure connection. This problem can apply not only to IPSec but also to TLS (which we’ll cover next) and SSH, as well as TOR and OTR.
In other words, it is possible to compromise both your VPN connection and different types of secure links for specific sites, mail servers, instant messaging, and the like. Obviously, to carry out such an attack, long startup times and significant computing resources are required. However, in this specific case, the researchers used standard Amazon cloud technologies and, evidently, spent a realistic amount of money, technically available for a private individual. With such resources at hand, the preparation time for an attack can be a minute at best and up to a month at worst.
At the same time, some experts were skeptical about this proof of concept; according to them, in real life, the number of vulnerable systems is much lower. However, certain aspects of the research should be taken seriously; meanwhile, developers of potentially vulnerable software are already preparing or have already developed patches and have alerted their users. SSL (Secure Sockets Layer) and TLS (Transport Layer Security), as their names suggest, belong to the class of solutions based on the corresponding SSL and TLS protocols, which are sometimes complemented by other means of protection.
You all must have come across SSL/TLS while browsing the Internet; for example, this site also uses it. The “https” prefix and the green padlock confirm that the site uses these protocols for a secure connection. The first implementations of the protocol date back to the last century, although the technology only gained confirmation in the 2000s. The proliferation of protocols has made it possible to study them in depth and to find a series of vulnerabilities, both in the same architecture and in different implementations.
SSL 3.0 was retired in June 2015; the most updated version is TLS 1.2, although it is by no means completely secure; a lot depends on the configuration (see IPSec). Additionally, both protocols are burdened by the need to offer backwards compatibility. What is undoubtedly an advantage of this type of VPN is the prevalence of SSL/TLS on the Internet, meaning that the majority of public networks let it pass freely.
On the downside, these VPNs have poor performance, are challenging to set up, and require additional software. Among the most common SSL/TLS VPN implementations are OpenVPN (SSL 3.0/TLS 1.2) and Microsoft’s SSTP (SSL 3.0). In fact, SSTP is integrated with Windows. OpenVPN, due to its open nature, has plenty of implementations for most platforms and is considered the most reliable VPN implementation to date.
Conclusions
We have examined the most common VPN implementations known to date. However, as this technology has evolved over the years, it has seen a vast number of iterations. Think of all the solutions developed for the business and telecommunications sectors! As for the average user, I recommend relying on OpenVPN due to its open nature, reliability, and security. However, this and other VPN implementations have a number of complex technical and legal peculiarities that I will cover in the next installment of this series.
Also Read: How To Define A Digital Selling Strategy