Get best of the week

Why you should not use WireGuard

Recently WireGuard attracts a lot of attention, in fact - this is a new "star" among VPNs. But is he as good as he seems? I would like to discuss some observations and consider the implementation of 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 will take a long time to read, so if you have not made a cup of tea or coffee, then it's time to do it. I would also like to thank Peter for proofreading my chaotic thoughts.

I do not set myself the goal of discrediting WireGuard developers, of devaluing their efforts or ideas. Their product is a working one, but I personally think that it is presented completely different from what it really is - it is presented as a replacement for IPsec and OpenVPN, which in reality just doesn't exist now.

As a note, I want to add that the responsibility for such a positioning of WireGuard lies with the media that spoke about it, and not the project itself or its creators.

There hasn't been too much good news on the Linux kernel topic lately. So, we were told about the monstrous vulnerabilities of the processor, which were leveled by software, and Linus Torvalds talked about it too rude and boring, utilitarian language of the developer. Scheduler or network stack zero level - also not too clear topics for glossy magazines. And then WireGuard appears.

Everything sounds great on paper: an exciting new technology.

But let's look at her a little more carefully.

WireGuard Technical Documentation


This article is based on the official WireGuard documentation written by Jason Donenfeld. There he explains the concept, purpose, and technical implementation of [WireGuard] in the Linux kernel.

The first sentence reads:

WireGuard [...] IPsec , / TLS, OpenVPN, , [].

Of course, the main advantage of all new technologies is their simplicity [in comparison with their predecessors]. But a VPN must also be efficient and secure .

So, what is next?

If you say that you [from the VPN] do not need this, then you can end the reading. However, I will notice that such tasks are posed before any other tunneling technology.

The most interesting of the above quotations lies in the words “in most cases”, which, of course, were ignored by the press. And here we are, where we ended up because of the chaos created by this negligence - in this article.



Will WireGuard replace my [IPsec] VPN connection between sites?


No. There is simply no chance that large vendors such as Cisco, Juniper and others will purchase WireGuard for their products. They do not “hop past trains” on the go, unless there is some great need for it. Later I will talk about some of the reasons why they probably would not be able to install WireGuard products on board, even if they wanted to.

Will WireGuard transfer my RoadWarrior from a laptop to a data center?


No. WireGuard hasn’t implemented a huge number of important functions right now so that it can do something like this. For example, it cannot use the dynamic IP address on the server side of the tunnel, and this alone breaks the whole scenario of a similar use of the product.

IPFire is often used for low-cost Internet channels, such as DSL or cable connection. This makes sense for a small or medium business that does not need fast fiber.[Note from the translator: do not forget that in terms of communications, Russia and some CIS countries are far ahead of Europe and the USA, 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 EU countries or the USA, xDSL broadband access at a speed of 3-5 Mbps is still the universal norm, and fiber-optic connection costs some unrealistic money by our standards. Therefore, the author of the article speaks of DSL or cable connection as normal, rather than the ancient past.] However, DSL, cable, LTE (and other wireless access methods) have dynamic IP addresses. Of course, at times they do not change often, but still change.

There is a subproject called "wg-dynamic"The user space daemon adds to overcome this shortcoming. A huge problem with the user scenario described above is the aggravation of the situation by dynamic IPv6 addressing.

From the point of view of the distributor, all this also does not look very good. One of the design goals was to keep the protocol simple and clean.

Unfortunately, all this actually became too simple and primitive, so we have to use additional software to make this whole design viable in real-life conditions.

Is WireGuard so easy to use?


Not yet. I'm not saying that WireGuard will never be a good alternative for forwarding a tunnel between two points, but so far it is just an alpha version of the product that it should become.

But then what does he really do? Is IPsec really that much harder to operate?

Obviously not. The IPsec provider has considered this point and is delivering its product along with an interface such as IPFire.

To configure a VPN tunnel through 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 side, subnets that you want to make public through this VPN connection and pre-shared key. Thus, the VPN is configured in a few minutes and it is compatible with any vendor.

Unfortunately, there are a few exceptions to this story. Everyone who tried to forward a VPN tunnel through IPsec to a machine on OpenBSD understands what I'm talking about. There are a couple more painful examples, but in fact, the good practice of using IPsec is much, much more.

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 the real concern of the user, then we would have long ago 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 complicated than WireGuard: it does a lot more. For example, user authentication using a login / password or SIM card with EAP. It has the expanded ability to add new cryptographic primitives .

But WireGuard doesn’t.

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 is worth noting that WireGuard is cryptographically self-confident. He intentionally lacks the flexibility of ciphers and protocols. If serious holes are found in the underlying primitives, all endpoints will need to be updated. As you can see from the ongoing stream of SLL / TLS vulnerabilities, encryption flexibility has now increased tremendously.

The last sentence is absolutely true.

Building consensus on which 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.

About ignoring real issues


Imagine you have a VPN server with 200 combat clients, somewhere around the world. This is a very 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. Deliver at the same time . It is literally impossible. Administrators who try to do this will take months to deploy the necessary configurations, and medium-sized companies will literally take years to host such an event.

IPsec and OpenVPN offer cipher negotiation. Therefore, some time after which you enable the new encryption, the old one will work. Thanks to this, current customers will be able to upgrade to the new version. After the update is rolled out, you simply turn off vulnerable encryption. And that’s all! Done! you are gorgeous! And customers will not even notice it.

This is actually a very common case for large deployments, and even OpenVPN has some difficulties. Backward compatibility is important, and although you use weaker encryption, for many this does not cause the closure of the business. Because it will lead to paralysis of hundreds of customers due to inability to do their job.

The WireGuard team has made their protocol simpler, but 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 works with SipHash for hash keys and BLAKE2 for hashing.

ChaCha20-Poly1305 is standardized for IPsec and OpenVPN (via TLS).

Obviously, the development of Daniel Bernstein is used very often. BLAKE2 is the successor to BLAKE, the SHA-3 finalist who did not win due to his resemblance to SHA-2. If SHA-2 were hacked, there was a high probability that BLAKE would be compromised.

IPsec and OpenVPN do not need SipHash because of their design. Thus, the only thing that cannot be used with them at the moment is BLAKE2, and only until it is 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 all VPNs use almost the same set of cryptographic tools. Therefore, WireGuard is no more and no less secure than any other relevant products when it comes to encryption or data integrity.

But even this is not the most important thing that you should pay 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, such as AES, encrypt a block 128 bits at a time. To implement hardware support, much more transistors will be required, therefore larger processors come with AES-NI, an extension to the instruction set that performs some tasks of the encryption process to speed it up.

It was expected that AES-NI will never hit smartphones [and it hit, - approx. trans.]. For this, the ChaCha20 was developed - as an easy and economical alternative that saves battery power. Therefore, it may be news for you that every smartphone that you can purchase today has one or another acceleration for AES and works with this encryption faster and with less power consumption than with ChaCha20.

Obviously, almost every desktop / server processor purchased in the last couple of years has AES-NI.

Therefore, I expect AES to surpass ChaCha20 in every single scenario. The official WireGuard documentation mentions that thanks to the AVX512, the ChaCha20-Poly1305 will outperform AES-NI, but this command set extension will only be available on large processors, which again will not help with smaller and more mobile equipment 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 nailed to one encryption is already a drawback that may not affect its work very well.

IPsec allows you to freely choose which encryption is best for your application. And of course, this is necessary if, for example, you want to transfer 10 or more gigabytes of data through a VPN connection.

Linux integration issues


Although WireGuard has chosen a modern encryption protocol, this is already causing a lot of problems. And so, instead of using what is supported by the kernel out of the box, WireGuard integration has been delayed for years due to the lack of these primitives in Linux.

I am not fully aware of the situation in other operating systems, but probably it is not much different from the situation with Linux.

What does reality look like?


Unfortunately, every time a client asks me to set up a VPN connection for him, I come across the topic that they use outdated credentials and encryption. 3DES in conjunction with MD5 is still a 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 , RSA is always used - a slow but fairly safe tool.

My clients are connected with customs authorities and other state 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 this somehow clearly affects technological progress, but obviously it slows down the corporate process.

It pains me to see this, because IPsec has supported elliptical curves off the curve since the year 2005. Curve25519 is also newer and more accessible. There are still alternatives to AES, such as Camellia and ChaCha20, but, obviously, not all of them are supported by large suppliers, such as Cisco and others.

And people use 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 innovations.

Yes, the situation [in the corporate segment] is terrible, but we will not see any changes due to WireGuard. Manufacturers are likely to never identify any performance issues with the tools and encryption already in use, they will not see problems when using 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 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 so they are useless when obtained in the laboratory.

In the WireGuard build for Linux, he takes advantage of the GSO - Generic Segmentation Offloading. Thanks to him, the client creates a huge packet of 64 kilobytes in size and encrypts / decrypts it in one approach. Thus, the cost of calling and implementing cryptographic operations is reduced. If you want to maximize the bandwidth of your VPN connection, this is a good idea.

But, as usual, in reality it is not so simple. Sending such a large packet to a network adapter requires that it be sliced ​​into many smaller packets. The typical send size is 1,500 bytes. That is, our giant 64 kilobytes will be divided into 45 packets (1240 bytes of information and 20 bytes of IP-header). Then, for a while, they completely block the operation of the network adapter, because they must be sent together and immediately. As a result, this will lead to a jump in priority, and packets such as, for example, VoIP, will be queued.

Thus, the high throughput, which WireGuard so boldly claims, is achieved by slowing down the network operation of other applications. And the WireGuard team has already confirmed this conclusion of mine.

But let's move on.

According to the benchmarks in the technical documentation, the connection shows a bandwidth of 1011 Mbit / s.

Impressive.

This is especially impressive because the maximum theoretical bandwidth of one gigabit Ethernet connection is 966 Mbit / s with a packet size of 1,500 bytes minus 20 bytes per IP header, 8 bytes per UDP header and 16 bytes per wire header itself. . There is another IP header in the encapsulated packet and another in 20 byte TCP. So where did this extra bandwidth come from?

With the huge frames and advantages of GSO, which we talked about above, the theoretical maximum with a frame size of 9000 bytes will be 1014 Mbit / s. Usually, such a throughput is unattainable in reality, because it is associated with great difficulties. Thus, I can only assume that the test was performed using even more bold frames exceeding the size of 64 kilobytes with a theoretical maximum of 1023 Mbit / s, which is supported only by some network adapters. But this is absolutely not applicable in real conditions, or it can be used only between two stations directly connected to each other, exclusively within the test stand.

But since the VPN tunnel is forwarded between two hosts using an Internet connection that does not support large frames at all, the result achieved at the stand cannot be taken as a standard. This is simply an unrealistic laboratory achievement, which is impossible and not applicable in real combat conditions.

Even sitting in the data center, I would not be able to transfer frames larger than 9000 bytes.

The criterion of applicability in real life is completely violated and, as I think, the author of the "measurement" 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 does not require configuration and can be deployed and configured with massive orchestration tools, such as Amazon’s in their cloud. Specifically, Amazon uses the latest hardware features that I mentioned earlier, for example - AVX512. This is done in order to speed up the work and not be tied to x86 or any other architecture.

They optimize bandwidth and packets whose size exceeds 9000 bytes - this will result in huge encapsulated frames for communicating containers with each other, or for backup operations, creating snapshots or deploying these containers. Even dynamic IP addresses will not affect the operation of WireGuard in the case of the scenario I described.

Not bad played. Brilliant implementation and a very thin, almost reference protocol.

But it just is not suitable for the world outside the data center you completely control. If you take the risk and start using WireGuard, you will have to make constant compromises in the development and implementation of the encryption protocol.

Conclusion


It’s easy for me to conclude that WireGuard is not 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 the IP address configuration and the routing and DNS configuration. Obviously, this is what encrypted channels are needed 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 tested for decades of operation. If something newer does not mean that it is something, it is better.

Interoperability is crucial when you contact third parties whose stations you do not control. IPsec is the de facto standard and is supported almost universally. And it 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 hacked sooner or later and, accordingly, 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 workshop on sticking your head in the sand.

More articles:


All Articles