WireGuard has been gaining a lot of attention lately, in fact it is the new star among VPNs. But is he as good as he seems? I would like to discuss some observations and review the implementation of WireGuard to explain why it is not a solution to replace IPsec or OpenVPN.
In this article, I would like to debunk some of the myths [around WireGuard]. Yes, it will take a long time to read, so if you have not made yourself a cup of tea or coffee, then it's time to do it. I would also like to say thanks to Peter for correcting my chaotic thoughts.
I do not set myself the goal of discrediting the developers of WireGuard, devaluing their efforts or ideas. Their product is working, but personally I think that it is presented completely different from what it really is - it is presented as a replacement for IPsec and OpenVPN, which in fact simply does not exist now.
As a note, I would like to add that the responsibility for such positioning of WireGuard lies with the media that talked about it, and not the project itself or its creators.
There hasn't been much good news about the Linux kernel lately. So, we were told about the monstrous vulnerabilities of the processor, which were leveled by software, and Linus Torvalds talked about it too rudely and boringly, in the utilitarian language of the developer. A scheduler or a zero-level networking stack are also not very clear topics for glossy magazines. And here comes WireGuard.
On paper, it all sounds great: an exciting new technology.
But let's look at it a little more closely.
WireGuard white paper
This article is based on written by Jason Donenfeld. There he explains the concept, purpose and technical implementation of [WireGuard] in the Linux kernel.
The first sentence reads:
WireGuard [β¦] aims to replace both IPsec in most use cases and other popular user space and/or TLS based solutions such as OpenVPN while being more secure, performant and easier to use [tool].
Of course, the main advantage of all new technologies is their simplicity [compared to predecessors]. But a VPN should also be effective and safe.
So, what is next?
If you say that this is not what you need [from a VPN], then you can end the reading here. However, I will note that such tasks are set for any other tunneling technology.
The most interesting of the above quote lies in the words "in most cases", which, of course, were ignored by the press. And so, we are where we ended up due to the chaos created by this negligence - in this article.
Will WireGuard replace my [IPsec] site-to-site VPN?
No. There is simply no chance that large vendors such as Cisco, Juniper and others will purchase WireGuard for their products. They don't "jump on passing trains" on the move unless there's some great need to do so. Later, I'll go over some of the reasons why they probably won't be able to get their WireGuard products on board even if they wanted to.
Will WireGuard take my RoadWarrior from my laptop to the data center?
No. Right now, WireGuard doesn't have a huge number of important features implemented for it to be able to do something like this. For example, it cannot use dynamic IP addresses on the tunnel server side, and this alone breaks the whole scenario of such use of the product.
IPFire is often used for cheap Internet links, such as DSL or cable connections. This makes sense for small or medium businesses that don't need fast fiber. [Note from the translator: do not forget that in terms of communication, Russia and some CIS countries are far ahead of Europe and the United States, because we started building our networks much later and with the advent of Ethernet and fiber optic networks as a standard, it was easier for us to rebuild. In the same countries of the EU or the USA, xDSL broadband access at a speed of 3-5 Mbps is still the general norm, and a fiber optic connection costs some unrealistic money by our standards. Therefore, the author of the article speaks of DSL or cable connection as the norm, and not ancient times.] However, DSL, cable, LTE (and other wireless access methods) have dynamic IP addresses. Of course, sometimes they do not change often, but they do change.
There is a subproject called , which adds a userspace daemon to overcome this shortcoming. A huge problem with the user scenario described above is the aggravation of dynamic IPv6 addressing.
From the point of view of the distributor, all this does not look very good either. One of the design goals was to keep the protocol simple and clean.
Unfortunately, all this has actually become too simple and primitive, so that we have to use additional software in order for this whole design to be viable in real use.
Is WireGuard so easy to use?
Not yet. I'm not saying that 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's supposed to be.
But then what does he actually do? Is IPsec really that much harder to maintain?
Obviously not. The IPsec vendor has thought of this and ships their product along with an interface, such as with IPFire.
To set up a VPN tunnel over IPsec, you will need five sets of data that you will need to enter into the configuration: your own public IP address, the public IP address of the receiving party, the subnets that you want to make public through this VPN connection and pre-shared key. Thus, the VPN is set up within minutes and is compatible with any vendor.
Unfortunately, there are a few exceptions to this story. Anyone who has tried to tunnel over IPsec to an OpenBSD machine knows what I'm talking about. There are a couple more painful examples, but in fact, there are many, many more good practices for using IPsec.
About protocol complexity
The end user does not have to worry about the complexity of the protocol.
If we lived in a world where this was a real concern of the user, then we would have got rid of SIP, H.323, FTP and other protocols created more than ten years ago that do not work well with NAT.
There are reasons why IPsec is more complex than WireGuard: it does a lot more things. For example, user authentication using a login / password or a SIM card with EAP. It has an extended ability to add new .
And WireGuard doesn't have that.
And this means that WireGuard will break at some point, because one of the cryptographic primitives will weaken or be completely compromised. The author of the technical documentation says this:
It's worth noting that WireGuard is cryptographically opinionated. It deliberately lacks the flexibility of ciphers and protocols. If serious holes are found in underlying primitives, all endpoints will need to be updated. As you can see from the ongoing stream of SLL/TLS vulnerabilities, the flexibility of encryption has now increased tremendously.
The last sentence is absolutely correct.
Reaching consensus on what encryption to use makes protocols like IKE and TLS more complex. Too complicated? Yes, vulnerabilities are quite common in TLS/SSL, and there is no alternative to them.
On ignoring real problems
Imagine that you have a VPN server with 200 combat clients somewhere around the world. This is a pretty standard use case. If you have to change the encryption, you need to deliver the update to all copies of WireGuard on these laptops, smartphones, and so on. Simultaneously deliver. It's literally impossible. Administrators trying to do this will take months to deploy the required configurations, and it will literally take a medium-sized company years to pull off such an event.
IPsec and OpenVPN offer a cipher negotiation feature. Therefore, for some time after which you turn on the new encryption, the old one will also work. This will allow current customers to upgrade to the new version. After the update is rolled out, you simply turn off the vulnerable encryption. And that's it! Ready! you are gorgeous! Clients won't even notice it.
This is actually a very common case for large deployments, and even OpenVPN has some difficulty with this. Backward compatibility is important, and even though you use weaker encryption, for many, this is not a reason to close a business. Because it will paralyze the work of hundreds of customers due to the inability to do their job.
The WireGuard team has made their protocol simpler, but completely unusable for people who don't have constant control over both peers in 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 works with SipHash for hash keys and BLAKE2 for hashing.
ChaCha20-Poly1305 is standardized for IPsec and OpenVPN (over TLS).
It is obvious that the development of Daniel Bernstein is used very often. BLAKE2 is the successor to BLAKE, a SHA-3 finalist that did not win due to its similarity to SHA-2. If SHA-2 were to be broken, there was a good chance that BLAKE would be compromised as well.
IPsec and OpenVPN don't need SipHash due to their design. So the only thing that can't currently be used with them is BLAKE2, and that's only until it's standardized. This is not a big drawback, because VPNs use HMAC to create integrity, which is considered a strong solution even in conjunction with MD5.
So I came to the conclusion that almost the same set of cryptographic tools is used in all VPNs. Therefore, WireGuard is no more or less secure than any other current product when it comes to encryption or the integrity of transmitted data.
But even this is not the most important thing, which is worth paying attention to according to the official documentation of the project. After all, the main thing is speed.
Is WireGuard faster than other VPN solutions?
In short: no, 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 128 bits at a time. Much more transistors are required to implement hardware support, so larger processors come with AES-NI, an instruction set extension that performs some of the tasks of the encryption process to speed it up.
It was expected that AES-NI would never get into smartphones [but it did β approx. per.]. For this, the ChaCha20 was developed as a lightweight, battery-saving alternative. Therefore, it may come as news to you that every smartphone you can buy today has some kind of AES acceleration and runs faster and with lower power consumption with this encryption than with ChaCha20.
Obviously, just about every desktop/server processor bought in the last couple of years has AES-NI.
Therefore, I expect AES to outperform ChaCha20 in every single scenario. WireGuard's official documentation mentions that with AVX512, ChaCha20-Poly1305 will outperform AES-NI, but this instruction set extension will only be available on larger CPUs, which again won't help with smaller and more mobile hardware, which will always be faster with AES- N.I.
I'm not sure if this could have been foreseen during the development of WireGuard, but today the fact that it is nailed to encryption alone is already a drawback that may not affect its operation very well.
IPsec allows you to freely choose which encryption is best for your case. And of course, this is necessary if, for example, you want to transfer 10 or more gigabytes of data through a VPN connection.
Integration issues in Linux
Although WireGuard has chosen a modern encryption protocol, this already causes a lot of problems. And so, instead of using what is supported by the kernel out of the box, the integration of WireGuard has been delayed for years due to the lack of these primitives in Linux.
I'm not entirely sure what the situation is on other operating systems, but it's probably not much different than on Linux.
What does reality look like?
Unfortunately, every time a client asks me to set up a VPN connection for them, I run into the issue that they are using outdated credentials and encryption. 3DES in conjunction with MD5 is still common practice, as are AES-256 and SHA1. And although the latter is slightly better, this is not something that should be used in 2020.
For key exchange always RSA is used - a slow but fairly safe tool.
My clients are associated with customs authorities and other government organizations and institutions, as well as with large corporations whose names are known all over the world. They all use a request form that was created decades ago, and the ability to use SHA-512 was simply never added. I can't say that it somehow clearly affects technological progress, but obviously it slows down the corporate process.
It pains me to see this because IPsec has been supporting elliptic curves offhand since 2005. Curve25519 is also newer and available for use. There are also alternatives to AES like Camellia and ChaCha20, but obviously not all of them are supported by major vendors like Cisco and others.
And people take advantage of it. There are many Cisco kits, there are many kits designed to work with Cisco. They are market leaders in this segment and are not very interested in any kind of innovation.
Yes, the situation [in the corporate segment] is terrible, but we will not see any changes because of WireGuard. Vendors will probably never see any performance issues with the tooling and encryption they're already using, won't see any problems with IKEv2, and so they're not looking for alternatives.
In general, have you ever thought about abandoning Cisco?
Benchmarks
And now let's move on to the benchmarks from the WireGuard documentation. Although this [documentation] is not a scientific article, I still expected the developers to take a more scientific approach, or use a scientific approach as a reference. Any benchmarks are useless if they cannot be reproduced, and even more useless when they are obtained in the laboratory.
In the Linux build of WireGuard, it takes advantage of using GSO - Generic Segmentation Offloading. Thanks to him, the client creates a huge packet of 64 kilobytes and encrypts / decrypts it in one go. Thus, the cost of invoking and implementing cryptographic operations is reduced. If you want to maximize the throughput of your VPN connection, this is a good idea.
But, as usual, the reality is not so simple. Sending such a large packet to a network adapter requires it to be cut into many smaller packets. The normal send size is 1500 bytes. That is, our giant of 64 kilobytes will be divided into 45 packets (1240 bytes of information and 20 bytes of the IP header). Then, for a while, they will completely block the work of the network adapter, because they must be sent together and at once. As a result, this will lead to a priority jump, and packets such as VoIP, for example, will be queued.
Thus, the high throughput that WireGuard so boldly claims is achieved at the cost of slowing down the networking of other applications. And the WireGuard team is already this is my conclusion.
But let's move on.
According to the benchmarks in the technical documentation, the connection shows a throughput of 1011 Mbps.
Impressive.
This is especially impressive due to the fact that the maximum theoretical throughput of a single 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 header of the WireGuard itself . There is one more IP header in the encapsulated packet and another one in TCP for 20 bytes. So where did this extra bandwidth come from?
With huge frames and the benefits of GSO we talked about above, the theoretical maximum for a frame size of 9000 bytes would be 1014 Mbps. Usually such throughput is unattainable in reality, because it is associated with great difficulties. Thus, I can only assume that the test was performed using even fatter oversized frames of 64 kilobytes with a theoretical maximum of 1023 Mbps, which is supported only by some network adapters. But this is absolutely inapplicable in real conditions, or can only be used between two directly connected stations, exclusively within the test bench.
But since the VPN tunnel is forwarded between two hosts using an Internet connection that does not support jumbo frames at all, the result achieved on the bench cannot be taken as a benchmark. This is simply an unrealistic laboratory achievement that is impossible and inapplicable in real combat conditions.
Even sitting in the data center, I could not transfer frames larger than 9000 bytes.
The criterion of applicability in real life is absolutely violated and, as I think, the author of the "measurement" carried out seriously discredited himself for obvious reasons.
Last glimmer of hope
The WireGuard website talks a lot about containers and it becomes clear what it is really intended for.
A simple and fast VPN that requires no configuration and can be deployed and configured with massive orchestration tools like Amazon has in their cloud. Specifically, Amazon uses the latest hardware features that I mentioned earlier, such as the AVX512. This is done in order to speed up the work and not be tied to x86 or any other architecture.
They optimize throughput and packets larger than 9000 bytes - these will be huge encapsulated frames for containers to communicate with each other, or for backup operations, creating snapshots or deploying these same containers. Even dynamic IP addresses will not affect the operation of WireGuard in any way in the case of the scenario I described.
Well played. Brilliant implementation and very thin, almost reference protocol.
But it just doesn't fit in a world outside of a data center that you completely control. If you take the risk and start using WireGuard, you will have to make constant compromises in the design and implementation of the encryption protocol.
Hack and predictor Aviator
It's easy for me to conclude that WireGuard isn't ready yet.
It was conceived as a lightweight and quick solution to a number of problems with existing solutions. Unfortunately, for the sake of these solutions, he sacrificed many features that will be relevant for most users. That is why it cannot replace IPsec or OpenVPN.
In order for WireGuard to become competitive, it needs to add at least an IP address setting and a routing and DNS configuration. Obviously, this is what encrypted channels are for.
Security is my top priority, and right now I have no reason to believe that IKE or TLS is somehow compromised or broken. Modern encryption is supported in both of them, and they have been proven by decades of operation. Just because something is newer doesn't mean it's better.
Interoperability is extremely important when you communicate with third parties whose stations you do not control. IPsec is the de facto standard and is supported almost everywhere. And he works. And no matter how it looks, in theory, WireGuard in the future may not be compatible even with different versions of itself.
Any cryptographic protection is broken sooner or later and, accordingly, must be replaced or updated.
Denying all of these facts and blindly wanting to use WireGuard to connect your iPhone to your home workstation is just a master class in sticking your head in the sand.
Source: habr.com