Recently, WireGuard has been gaining significant attention; it is essentially the new "star" among VPN. But is it really as good as it seems? I would like to discuss some observations and examine the implementation of WireGuard to explain why it is not a solution that can replace IPsec or OpenVPN.
In this article, I would like to debunk some myths [around WireGuard]. Yes, it's going to be a long read, so if you haven't brewed yourself a cup of tea or coffee yet, now is the time to do so. I would also like to thank Peter for proofreading my chaotic thoughts.
My goal is not to discredit the developers of WireGuard or devalue their efforts or ideas. Their product is functional, but personally, I believe it is presented as something entirely different than what it actually is — marketed as a replacement for IPsec and OpenVPN, which simply does not currently exist.
As a side note, it’s worth mentioning that the responsibility for this positioning of WireGuard lies with the media that reported on it, not with the project or its creators.
Recently, there haven't been too many good news regarding the Linux kernel. We were told about monstrous processor vulnerabilities that were mitigated through software, and Linus Torvalds spoke about it in a rather blunt and dull, utilitarian developer's language. The scheduler or zero-level network stack are also not very comprehensible topics for glossy magazines. And then WireGuard appears.
On paper, everything sounds great: an exciting new technology.
But let's take a closer look at it.
WireGuard Technical Documentation
This article is based on the official WireGuard documentation, written by Jason Donenfeld. In it, he explains the concept, purpose, and technical implementation of [WireGuard] in the Linux kernel.
The first sentence states:
WireGuard […] aims to replace both IPsec in most of its use cases and other popular user-space and/or TLS-based solutions, such as OpenVPN, while being a more secure, performant, and easy-to-use [tool].
Of course, the main advantage of all new technologies is their simplicity [compared to their predecessors]. But a VPN also needs to be effective and secure.
And what's next?
If you say that you need something other than [from the VPN], then we can end the reading here. However, I will note that such tasks are set for any other tunneling technology.
The most interesting part of the above quote lies in the words "in most cases," which, of course, were ignored by the press. And here we are, where we ended up due to the chaos created by this carelessness — in this article.
Will WireGuard replace my [IPsec] VPN connection between sites?
No. There is simply no chance that major vendors like Cisco, Juniper, and others will adopt WireGuard for their products. They do not "jump on passing trains" on the fly unless there is some significant necessity. Later, I will discuss some reasons why they may not be able to incorporate WireGuard into their products even if they wanted to.
Will WireGuard move my RoadWarrior from my laptop to the data center?
No. Right now, WireGuard lacks a huge number of important features to be able to do something like that. For example, it cannot use dynamic IP addresses on the tunnel server side, and just this breaks the entire scenario for such product use.
IPFire is often used for inexpensive internet connections, such as DSL or cable. This makes sense for small or medium businesses that don’t need fast fiber optics. [Translator's note: it's worth remembering that in terms of connectivity, Russia and some CIS countries are far ahead of Europe and the US because we started building our networks much later and, with the advent of Ethernet and fiber optic networks as the standard, it was easier for us to adapt. In the EU or the US, xDSL broadband access at speeds of 3-5 Mbps is still common, while fiber optic connections cost some unreal amounts by our standards. Thus, the author of the article refers to DSL or cable connections as the norm, not an ancient relic.] However, DSL, cable, LTE (and other wireless access methods) have dynamic IP addresses. Of course, they don't change often at times, but they still do change.
There is a subproject called "wg-dynamic", which adds a user-space daemon to overcome this shortcoming. A major issue with the user scenario described above is the exacerbation caused by dynamic IPv6 addressing.
From the distributor's perspective, this also doesn't look great. One of the goals of the development was to maintain the simplicity and clarity of the protocol.
Unfortunately, everything has become too simple and primitive, so we have to use additional software to make this entire structure viable in real-world operation.
Is WireGuard really that easy to use?
Not yet. I'm not saying WireGuard will never be a good alternative for tunneling between two points, but for now, it's just an alpha version of the product it should become.
But what does it actually do? Is IPsec really that much more difficult to operate?
Clearly not. The IPsec provider has thought this through and delivers its product with an interface, for example, with IPFire.
To set up a VPN tunnel via IPsec, you will need five sets of data to enter into the configuration: your own public IP address, the public IP address of the receiving side, the subnets you want to make public via this VPN connection, and the pre-shared key. Thus, the VPN is configured in a matter of minutes and is compatible with any vendor.
Unfortunately, in this story, there are a few exceptions. Anyone who has tried to tunnel a VPN through IPsec to a machine on OpenBSD knows what I'm talking about. There are a couple more painful examples, but in reality, there is much more positive practice using IPsec.
On the complexity of the protocol
The end user should not worry about the complexity of the protocol.
If we lived in a world where this was a real concern for users, we would have long ago eliminated SIP, H.323, FTP, and other protocols created more than ten years ago that don't work well with NAT.
There are reasons why IPsec is more complex than WireGuard: it does many more things. For example, user authentication using a login/password or a SIM card with EAP. It has advanced capabilities for adding new cryptographic primitives.
And WireGuard does not have that.
And this means that WireGuard will eventually fail because one of the cryptographic primitives will weaken or be fully compromised. The author of the technical documentation describes it this way:
It is worth noting that WireGuard is cryptographically overconfident. It deliberately lacks flexibility in ciphers and protocols. If serious flaws are discovered in the underlying primitives, all endpoints will need to be updated. As seen from the ongoing stream of SSL/TLS vulnerabilities, the flexibility of encryption has significantly increased.
The last statement is absolutely correct.
Reaching a consensus on which encryption to use makes protocols such as IKE and TLS more than complex. Too complex? Yes, vulnerabilities in TLS/SSL occur quite frequently, and there are no alternatives.
On ignoring real issues
Imagine you have a VPN server with 200 active clients scattered around the world. This is quite a standard use case. If you need to change encryption, you'll have to deliver the update to all copies of WireGuard on those laptops, smartphones, and so on. Simultaneously deliver. This is literally impossible. Administrators trying to do this will take months to deploy the necessary configurations, and medium-sized companies will literally need years to carry out such an initiative.
IPsec and OpenVPN offer cipher negotiation functionality. Therefore, for some time after you enable new encryption, the old one will still work. This allows current clients to upgrade to the new version. Once the update is rolled out, you simply turn off the vulnerable encryption. And that's it! Done! You're fantastic! And the clients won't even notice it.
In fact, this is a very common case for large deployments, and even OpenVPN encounters some difficulties with this. Backward compatibility is important, and while you may be using weaker encryption, for many, this doesn't lead to business closure. Because it would paralyze the operations of hundreds of clients due to their inability to function.
The WireGuard team has simplified its protocol, but it is completely unsuitable for people who do not have constant control over both peers of their tunnel. In my experience, this is the most common scenario.
Cryptography!
But what is this interesting new encryption that WireGuard uses?
WireGuard uses Curve25519 for key exchange, ChaCha20 for encryption, and Poly1305 for data authentication. It also utilizes SipHash for hash keys and BLAKE2 for hashing.
ChaCha20-Poly1305 is standardized for IPsec and OpenVPN (via TLS).
It's clear that Daniel Bernstein's development is widely used. BLAKE2 is the successor to BLAKE, a finalist for SHA-3, which did not win due to its similarity to SHA-2. If SHA-2 were to be compromised, there would be a high likelihood that BLAKE would also be affected.
IPsec and OpenVPN do not require SipHash due to their design. Thus, the only thing that currently cannot be used with them is BLAKE2, and only until it is standardized. This is not a major drawback since VPNs use HMAC for integrity, which is considered a strong solution even when paired with MD5.
So I concluded that nearly the same set of cryptographic tools is used in all VPNs. Therefore, WireGuard is neither more nor less secure than any other current products when it comes to encryption or the integrity of transmitted data.
But even this is not the most important point to note according to the project's official documentation. The main focus is speed.
Is WireGuard faster than other VPN solutions?
In short: no, it is not faster.
ChaCha20 is a stream cipher that is easier to implement in software. It encrypts one bit at a time. Block protocols like AES encrypt a block of 128 bits at a time. Implementing hardware support requires many more transistors, which is why larger processors come with AES-NI — an instruction set extension that performs certain encryption process tasks to accelerate it.
It was expected that AES-NI would never make its way into smartphones [but it did, — ed. note]. For this reason, ChaCha20 was developed as a lightweight and efficient alternative that conserves battery life. Therefore, it may come as a surprise that every smartphone you can purchase today has some form of acceleration for AES and operates with this encryption faster and with lower energy consumption than with ChaCha20.
It is evident that practically every desktop CPU/server purchased in the last couple of years features AES-NI.
Consequently, I expect AES to outperform ChaCha20 in every single scenario. The official documentation from WireGuard mentions that thanks to AVX512, ChaCha20-Poly1305 will surpass AES-NI, but this instruction set extension will only be available on larger processors, which again won't benefit smaller and mobile hardware that will always work faster with AES-NI.
I'm not sure if this could have been foreseen during the development of WireGuard, but today the fact that it is tied to a single encryption method is already a drawback that may negatively affect its performance.
IPsec allows you to freely choose which encryption is best suited for your case. Naturally, this is necessary if, for example, you want to transfer 10 or more gigabytes of data over a VPN connection.
Integration Issues in Linux
Although WireGuard chose a modern encryption protocol, it has already caused a host of problems. Instead of utilizing what is natively supported by the kernel, the integration of WireGuard has been delayed for years due to the lack of these primitives in Linux.
I'm not entirely aware of the situation in other operating systems, but it is likely not much different from that of Linux.
What does reality look like?
Unfortunately, every time a client asks me to set up a VPN connection for them, I encounter the issue that they are using outdated credentials and encryption. 3DES coupled with MD5 is still a common practice, as is AES-256 and SHA1. And while the latter is slightly better, it is not something to rely on in 2020.
For key exchange recommendations only RSA is used — a slow but sufficiently secure tool.
My clients are connected with customs authorities and other governmental organizations and institutions, as well as large corporations whose names are recognized worldwide. They all use a request form that was created decades ago, and the ability to use SHA-512 has simply never been added. I can't say that this explicitly affects technological progress, but it clearly slows down corporate processes.
It pains me to see this because IPsec has supported elliptic curves since around 2005. Curve25519 is also newer and available for use. There are also alternatives to AES like Camellia and ChaCha20, but clearly, not all of them are supported by major vendors like Cisco and others.
And people are using them. There are many Cisco kits, and there are numerous kits designed to work with Cisco. They are market leaders in this segment and are not very interested in any innovations.
Yes, the situation [in the corporate segment] is dire, but we will not see any changes due to WireGuard. Manufacturers probably will never uncover any performance problems with the already utilized tools and encryption, nor will they see issues when using IKEv2 — and hence they are not looking for alternatives.
Have you ever considered moving away from Cisco?
Benchmarks
Now let's move on to the benchmarks from the WireGuard documentation. Although this [documentation] is not a scientific article, I still expected a more scientific approach from the developers, either by applying a scientific method as a benchmark. Any benchmarks are useless if they cannot be reproduced, and even more so, they are useless when obtained under laboratory conditions.
In the WireGuard build for Linux, it gains an advantage by using GSO — Generic Segmentation Offloading. This allows the client to create a huge packet size of 64 kilobytes and encrypt/decrypt it in one go. This reduces the costs associated with invoking and implementing cryptographic operations. If you want to maximize the throughput of your VPN connection, this is a good idea.
However, as is often the case, reality is not so simple. Sending such a large packet to the network adapter requires it to be split into many smaller packets. The normal packet size is 1500 bytes. This means our giant of 64 kilobytes will be divided into 45 packets (1240 bytes of information and 20 bytes for the IP header). Then, for a time, they will completely block the network adapter's operation because they must be sent together and at once. Ultimately, this will lead to a priority jump, and packets such as VoIP will be put in a waiting queue.
Thus, the high bandwidth that WireGuard so boldly claims is achieved at the expense of slowing down the network performance of other applications. And the WireGuard team has already confirmed this conclusion of mine.
But let's move on.
According to benchmarks in the technical documentation, the connection shows a bandwidth of 1011 Mbps.
Impressive.
This is especially impressive because the maximum theoretical bandwidth of a gigabit Ethernet connection is 966 Mbps with a packet size of 1500 bytes, minus 20 bytes for the IP header, 8 bytes for the UDP header, and 16 bytes for the WireGuard header itself. There is another IP header in the encapsulated packet and another 20-byte header in TCP. So where did this extra bandwidth come from?
With large frames and the benefits of GSO discussed above, the theoretical maximum at a frame size of 9000 bytes would be 1014 Mbps. Typically, this bandwidth is not achievable in reality due to significant difficulties. Thus, I can only assume that the test was performed using even larger frames exceeding the 64-kilobyte size with a theoretical maximum of 1023 Mbps, which is supported only by some network adapters. However, this is entirely impractical in real conditions, or may only be used between two directly connected stations, exclusively within a test setup.
However, since the VPN tunnel is established between two hosts using an internet connection that does not support large frames at all, the result achieved in the stand cannot be considered a benchmark. It is simply an unrealistic laboratory achievement that is impossible and inapplicable under real-world conditions.
Even sitting in the data center, I would not be able to pass frames larger than 9000 bytes.
The criterion for applicability in real life is completely violated, and as I think, the author of the conducted "measurement" has seriously discredited himself for obvious reasons.
The last glimmer of hope
The WireGuard website talks a lot about containers, and it becomes clear what it is actually intended for.
A simple and fast VPN that requires no configuration and can be deployed and set up with massive orchestration tools, like those used by Amazon in their cloud. Specifically, Amazon employs the latest hardware features I mentioned earlier, such as AVX512. This is done to speed up processing and not tie to x86 or any other architecture.
They optimize throughput and packets larger than 9000 bytes—resulting in huge encapsulated frames for communication between containers, or for backup operations, snapshot creation, or deploying those same containers. Even dynamic IP addresses will not affect WireGuard's operation in the scenario I described.
Nicely played. Brilliant implementation and a very refined, almost benchmark protocol.
But it simply doesn't fit into a world outside of a data center that you fully control. If you dare to start using WireGuard, you will have to make constant compromises in the design and implementation of the encryption protocol.
Output
It is not difficult for me to conclude that WireGuard is not ready yet.
It was designed as a lightweight and fast solution for a number of problems with existing solutions. Unfortunately, in pursuit of these solutions, it sacrificed many features that would be relevant for most users. That is why it cannot replace IPsec or OpenVPN.
For WireGuard to be competitive, it needs to add at least IP address configuration and routing and DNS setup. It's clear that encrypted channels are needed for this purpose.
Security is my top priority, and at the moment I have no reason to believe that IKE or TLS have been compromised or broken. Modern encryption is supported in both, and they have been tested over decades of use. Just because something is newer doesn’t mean it is better.
Functional compatibility is extremely important when you're connecting to third parties whose stations you don't control. IPsec is the de facto standard and is supported almost everywhere. And it works. As much as it might theoretically seem, WireGuard could be incompatible with even different versions of itself in the future.
Any cryptographic protection will eventually be broken and, as a result, must be replaced or updated.
Denying all these facts and blindly wanting to use WireGuard to connect your iPhone to your home workstation is just a masterclass in burying your head in the sand.
Source: habr.com
