Lately WireGuard attracts a lot of attention, in fact, it is a new “star” among VPNBut is it as good as it seems? I'd like to discuss some observations and review the implementation. WireGuard, to explain why it is not a solution that will replace IPsec or OpenVPN.
In this article I would like to debunk some myths [around WireGuard]. Yes, it's a long read, so if you haven't brewed yourself a cup of tea or coffee yet, now's the time. I'd also like to thank Peter for proofreading my chaotic thoughts.
It is not my goal to discredit the developers. WireGuard, devalue their efforts or ideas. Their product is working, but I personally believe it is presented as something completely different from what it really 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 WireGuard are carried by the media that reported on it, and not the project itself or its creators.
Recently on the topic of the core Linux There wasn't much good news. We were told about monstrous processor vulnerabilities that were mitigated by software, and Linus Torvalds's account of it was too crude and boring, in the utilitarian language of a developer. The scheduler or the level-0 network stack are also not exactly clear topics for glossy magazines. And then along comes WireGuard.
On paper, it all sounds great: an exciting new technology.
But let's look at it a little more closely.
Technical documentation WireGuard
This article is based on official documentation WireGuard, written by Jason Donenfeld, where he explains the concept, purpose, and technical implementation [WireGuard] in the core Linux.
The first sentence reads:
WireGuard […] aims to replace both IPsec in most use cases, as well as other popular user-space and/or TLS-based solutions such as OpenVPN, while being safer, more productive 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 it become WireGuard replacing my [IPsec] site-to-site VPN?
No. There is simply no chance that large vendors like Cisco, Juniper, and others will acquire it for their products. WireGuardThey don't "jump on passing trains" unless there's a pressing need. Later, I'll discuss some of the reasons why they probably won't be able to install their products on board. WireGuard, even if they wanted to.
Will it survive? WireGuard my RoadWarrior from a laptop to a data center?
No. Right now in WireGuard A huge number of important features are missing to enable something like this. For example, it can't use dynamic IP addresses on the tunnel server side, and this alone breaks the entire use case for this 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 "wg-dynamic", 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.
WireGuard Is it that easy to use?
Not yet. I'm not saying that. WireGuard It will never be a good alternative for tunneling between two points, but for now it is just an alpha version of the product that it is supposed to become.
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. For example, it authenticates users using login/password or a SIM card with EAP. It has an extended capability to add new ones. cryptographic primitives.
And WireGuard it is not.
And this means that WireGuard At some point, it will fail because one of the cryptographic primitives will become weakened or completely compromised. The author of the technical documentation puts it this way:
It is worth noting that WireGuard Cryptographically overconfident. It intentionally lacks flexibility in its ciphers and protocols. If serious holes are discovered in the underlying primitives, all endpoints will need to be updated. As the ongoing flood of SSL/TLS vulnerabilities demonstrates, encryption flexibility has now increased dramatically.
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 you have a VPN server with 200 production clients, somewhere around the world. This is a fairly standard use case. If you need to change the encryption, you need to push the update to all copies. 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. So, for a short period of time, after you enable the new encryption, the old one will also work. This allows current clients to upgrade to the new version. Once the update is rolled out, simply disable the vulnerable encryption. And that's it! Done! You're amazing! And your clients won't even notice.
This is actually a very common case for large deployments, and even OpenVPN It's experiencing some difficulties with this. Backward compatibility is important, and even though you use weaker encryption, for many, this isn't a reason to shut down their business. Because it would paralyze hundreds of clients due to their inability to do their jobs.
Our team WireGuard made its protocol simpler, but completely unsuitable for people who don't 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 is being used? WireGuard?
WireGuard It uses Curve25519 for key exchange, ChaCha20 for encryption, and Poly1305 for data authentication. It also supports SipHash for key hashes and BLAKE2 for hashing.
ChaCha20-Poly1305 is standardized for IPsec and OpenVPN (via 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 SipHash isn't required due to its design. Therefore, the only thing that currently can't be used with them is BLAKE2, and only until it's standardized. This isn't a major drawback, as VPNs use HMAC for integrity, which is considered a strong solution even when paired with MD5.
So I came to the conclusion that all VPNs use almost the same set of cryptographic tools. Therefore WireGuard no more or less secure than any other current product when it comes to encryption or 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.
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. In the official documentation WireGuard It is mentioned that thanks to AVX512, ChaCha20-Poly1305 will outperform AES-NI, but this instruction set extension will only be available on larger processors, which again won't help with smaller and mobile hardware, which will always be faster with AES-NI.
I'm not sure if this could have been foreseen during development. WireGuard, but today the fact that it is nailed to one encryption is already a disadvantage that may not have a very good effect on its operation.
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.
Problems of integration in Linux
Although Dr. Fulmes’s WireGuard I chose a modern encryption protocol, which is already causing a lot of problems. And so, instead of using what the kernel supports out of the box, the integration WireGuard was postponed 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 from 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 due to WireGuardManufacturers will likely never discover any performance issues with the tools and encryption they already use, nor will they see any problems with IKEv2—and therefore they are not looking for alternatives.
In general, have you ever thought about abandoning Cisco?
Benchmarks
Now let's move on to the benchmarks from the documentation. WireGuardWhile this [documentation] isn't a scientific paper, I still expected the developers to take a more scientific approach, or to use a scientific approach as a benchmark. Benchmarks are useless if they can't be reproduced, and they're even more useless when they're obtained in a lab setting.
In assembly WireGuard for Linux It gains an advantage by using GSO (Generic Segmentation Offloading). It allows the client to create a huge 64-kilobyte packet and encrypt/decrypt it in a single pass. This reduces the cost of performing the cryptographic operations and calls. If you want to maximize your VPN connection's throughput, 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 is so boldly claimed WireGuard, is achieved by slowing down the network performance of other applications. And the team WireGuard already confirmed 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 because 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 itself. WireGuardThere's another IP header in the encapsulated packet and another one in TCP, 20 bytes long. So where does 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 site WireGuard There is a lot of talk about containers and it becomes clear what they are actually 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 packet sizes exceeding 9000 bytes—these result in huge encapsulated frames for container communication, backup operations, snapshot creation, or container deployment. Even dynamic IP addresses won't impact performance. WireGuard in the case of the scenario I described.
Well played. Brilliant implementation and very thin, almost reference protocol.
But it's simply not suitable for the 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 when designing and implementing an encryption protocol.
Final World
It is not difficult for me to conclude that WireGuard not ready yet.
It was intended as a lightweight and fast solution to a number of problems with existing solutions. Unfortunately, in order to achieve these solutions, it sacrificed many features that would be relevant to most users. That's why it can't replace IPsec or OpenVPN.
In order to WireGuard For it to become competitive, it needs to at least add IP address configuration, routing, and DNS configuration. Clearly, encrypted channels are needed for this.
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 crucial when communicating with third parties whose stations you don't control. IPsec is the de facto standard and is supported almost everywhere. And it works. And whatever it looks like, in theory, WireGuard in the future it may be incompatible even with different versions of itself.
Any cryptographic protection is broken sooner or later and, accordingly, must be replaced or updated.
Denial of all these facts and a blind desire to use WireGuard to connect your iPhone to a home workstation is a master class in sticking your head in the sand.
Source: habr.com
