The original link: fuckcloudnative. IO/posts/according to – n…

Recently, a new VPN tool has attracted much attention, which I believe many of you have heard of. Yes, WireGuard is rumored to replace IPSec and OpenVPN. Is WireGuard as amazing as it seems? I’m going to explain them all today.

This is a very long article, and I suggest you make a cup of coffee and read it while you drink your coffee.

WireGuard will replace OpenVPN and IPSec with WireGuard. I am not trying to undermine WireGuard. WireGuard is awesome, but I can’t stand it.

WireGuard white paper

All the points in this article are in response to the WireGuard whitepaper written by Jason Donenfeld. Other blogs and documentation are outside my scope. The first sentence of the white paper says:

WireGuard is designed to replace IPsec and other user-space and TLS based VPNS such as OpenVPN in most scenarios, making it simpler, more efficient, and easier to use than other VPNS.

As you can see, WireGuard’s biggest selling point is its simplicity, and this is how most new technologies are marketed. Of course, as a VPN product, it also has two selling points: performance and security.

The funny thing is, as a VPN, if you’re not simple, insecure, and performing poorly, you probably don’t stand a chance. This is not only your WireGuard design goal, but other VPN products do the same.

The most interesting part is the words “in most cases”, which have been deleted from media reports to confuse the public.

Can WireGuard replace IPSec?

No! Big companies like Cisco and Juniper can’t use WireGuard, they don’t get into WireGuard cars unless they have to. I’ll explain in more detail why they couldn’t sell WireGuard even if they wanted to.

WireGuard implements Road Warrior?

Of course not. Road Warrior is a mobile client with dynamically assigned IP addresses, such as a laptop. You can just say roaming. WireGuard cannot currently use dynamic IP to establish connections, and roaming is still a long way off.

WireGuard has a subproject called WG-Dynamic that adds a user-space daemon to enable WireGuard to support dynamic IP. However, the last update of this project was in 2019, I don’t know whether it is still maintained or not…

IPv6 is a dynamic addressing system, so how will WireGuard be used in the future? From a business point of view, this is quite disappointing.

One of the goals of WireGuard’s design was to keep the protocol lean, but it now appears that it is so lean that more auxiliary software is needed to make it powerful.

Does WireGuard really work?

Don’t. I’m not saying that WireGuard won’t eventually replace other VPN products, I’m just saying that WireGuard isn’t available right now, and if its goals are what we think they are, it’s still in Alpha.

What problem is WireGuard trying to solve? Is IPsec really hard to use?

I’m afraid not, but if the vendor does its homework right and provides an easy-to-use interface (e.g., IPFire), it won’t be hard to use.

To establish an IPSec tunnel, you need to enter only five groups of information: your public address, the public address of the peer, the subnet, your pre-shared secret key, and the pre-shared secret key of the peer. In this way, a tunnel can be established in a matter of minutes, and each vendor is compatible.

Of course, there are some exceptions, such as establishing a tunnel with an OpenBSD system, which can be painful.

Does protocol complexity really matter?

As an end user, there is no need to consider the complexity of the protocol.

If complexity really mattered, we would have gotten rid of protocols like SIP, H.323, and FTP that didn’t handle NAT well, but they didn’t. There’s a reason why IPsec is more complex than WireGuard: it can do so much. For example, using a user name/password or SIM card with EAP for user authentication; New encryption methods can also be extended.

The WireGuard? None of these features are available. This means that one day, when its fixed encryption is broken or weakened, it will collapse.

WireGuard author says:

WireGuard is paranoid about encryption methods. It deliberately disables the agility of encryption protocols and does not support extended encryption protocols because doing so would greatly reduce software complexity. If there is a vulnerability in the underlying encryption protocol, all endpoints must be updated to fix the vulnerability.

I quite agree with him in this sentence, because negotiating which encryption method to use makes protocols like IKE and TLS more complicated. So, did we just want to be so complicated? Of course not ah, even so, in the process of shaking hands will often find all kinds of loopholes, not complex can do? There is no other way.

How do I update my password?

Imagine that you have a VPN server serving more than 200 Road Warrior clients scattered around the world. If you changed your password now, you would have to update all of your clients’ passwords at the same time to work, which would be impossible. As an administrator, you would probably need months to complete the configuration change.

IPsec and OpenVPN do not have such worries. They both have the key negotiation function, which can gradually update the new secret key to all clients. During the long update process, the clients that still use the old secret key are still valid. The client is unaware and does not need to be rebooted.

encryption

WireGuard uses the following encryption techniques to secure data:

  • useChaCha20For symmetric encryption, usePoly1305Perform data validation.
  • usingCurve25519Perform key exchange.
  • useBLAKE2As a hash function.
  • useHKDFDecrypt it.

IPSec and OpenVPN use the standard Chacha20-Poly1305 encryption algorithm.

BLAKE2 was an improved version of BLAKE’s algorithm, and BLAKE was a sha-3 finalist who was very similar to SHA-2, so did not win. If SHA-2 is ever cracked, there’s a good chance BLAKE will be too.

IPSec and OpenVPN use encryption similar to WireGuard, such as symmetric encryption using the standard Chacha20-Poly1305 algorithm. The only one not used is BLAKE2, which is currently not included in the standard. Even without BLAKE2, it’s not a big deal because VPNS use HMACs for data integrity, and MD5 is still fine.

My conclusion is that virtually all VPNS can use the same encryption techniques and WireGuard is not more or less secure in terms of encryption or data integrity than other VPNS.

But as the white paper says, encryption isn’t the point, speed is.

Well, let’s see if it’s really that fast.

Is WireGuard really fast?

The answer is no.

ChaCha20 is a stream encryption algorithm that encrypts only one bit at a time and is easier to implement using software. Chunking, like AES, splits the plaintext into modules of equal length and encrypts 128-bit modules at a time. This encryption requires more transistors to implement in hardware, so large processors come with an instruction set extension, AES-NI, that speeds up encryption and decryption.

Any smartphone you can buy today comes with AES hardware acceleration, and using AES on these hardware will be faster and more energy efficient than ChaCha20 encryption and decryption. Almost every PC and server CPU comes with AES-NI, not to mention encryption and decryption speed. As a result, I expect AES to outperform ChaCha20 in almost all scenarios.

However, the WireGuard whitepaper goes on to say that Chacha20-Poly1305 performs better than AES-NI, but the instruction set only works on large processors and does nothing for ordinary PCS and mobile hardware, so it is not useful.

WireGuard is obsessed with one encryption algorithm, which I don’t think is good. IPSec allows you to select different encryption algorithms, so that you can choose the most appropriate encryption algorithm for different usage scenarios, such as transferring 10 GIGABytes of data or more.

Now that WireGuard has chosen a more modern encryption method, there are many problems. For example, the WireGuard does not use the Linux kernel modules that support these encryption methods, and the Linux kernel modules are several years late. I don’t know about other operating systems, but it’s probably no different.

Ideal and reality

Assuming WireGuard is perfect, will big companies use it?

The reality is that every time a client asks me to help them set up a VPN, they are given a certificate using the old encryption method, usually 3DES combined with MD5, or AES-256 combined with SHA1. For secret key exchange, we’ve been using RSA, which is slow but secure enough.

Most of our customers are related to government agencies or major companies, and their order forms are decades old and have no sha-512 option. So it’s not necessarily technology that’s holding innovation back, it’s slow business processes.

It pains me to see that, you know? Don’t I want to use new technology? Of course. IPsec has supported elliptic curve encryption since around 2005, Curve25519 is now supported, and there are alternatives to AES (Camellia and ChaCha20), but it is clear that not all major players are willing to adapt, such as Cisco. Cisco is the market leader in this area, and they’re not really interested in driving innovation.

The benchmark

Benchmarks for WIreGuard are also mentioned in the white paper, and while this is not a scientific paper, I still want to benchmark in a scientific way. If a test cannot be repeated, it is worthless; If the test does not consider the real world, it is worthless.

The Linux version of WireGuard uses GSO (Generic Segmentation Offloading) to create a large 64K byte packet and encrypt or decrypt it at once to gain a speed advantage. This saves the overhead of initializing and invoking encryption operations. This is a good idea if you want to maximize throughput.

However, if you want to send such a large packet to a network adapter, you need to slice it up into many smaller packets, usually 1500 bytes. For very large packets of 64K bytes, which are sliced into 45 packets (each with a 1480 byte payload and a 20 byte IP header), these packets will block the network adapter for quite some time because they want to be sent out at once. Packets that should be processed first, such as VoIP calls, have to wait.

Thus, the high throughput claimed by WireGuard is achieved by slowing down other applications, which has been acknowledged by the official team.

Let’s look at the final data from the benchmark again. Throughput is 1011 MBit/s!

This data is impressive and I am still puzzled by it, the maximum theoretical throughput of a gigabit Ethernet link is 966 MBit/s for a packet size of 1500 bytes, minus 20 bytes of IP header, 8 bytes of UDP header and 16 bytes of WireGuard header, After subtracting another IP header and another 20-byte TCP header in the packet, where does the extra bandwidth come from?

OK, assuming jumbo frames and GSO are enabled, the theoretical maximum for 9000 byte frame sizes will be 1014 MBit/s. If larger jumbo frames are used, the theoretical maximum is 1023 MBit/s. However, this is definitely not practical in reality because it is too expensive and can only be used when the server is directly connected. Typically VPNS are connected over the Internet and do not support jumbo frames at all, so such benchmarks are impractical and will never be used in the real world.

Final fantasy

WireGuard’s official website writes a lot about containers, which is clearly what WireGuard is for.

CNI, which implements container communication through a simple and fast VPN, can be quickly deployed through large container choreography tools such as Kubernetes, optimized for throughput and packets larger than 9000 bytes, can quickly distribute container images, and so on.

It all seems to have been designed for containers, super lean, super elegant, super fast.

But it’s not designed at all for the world outside the data center, where you have to compromise on protocol design and implementation.

conclusion

My final conclusion is that WireGuard is not ready.

It was drafted as a lightweight and fast solution to address some of the problems in existing solutions, but unfortunately it sacrifices many user-specific features and therefore cannot replace IPsec and OpenVPN.

Do you at least have dynamic address assignment and routing push configurations? These functions require key negotiation.

In addition, security is a top priority, and SO far I have found no obvious flaws in IKE or TLS, both of which support modern encryption and have been audited for decades. Just because something is new doesn’t mean it’s good.

Encryption is always out of date, so what do you do when you bet on a encryption that is no longer secure?