Because wireguard is NOT safe and you should NOT use it.
The first time people use a VPN, the first thing they see is "how fast we are". And if “we are very fast,“ we are inclined ”to think that“ we are dealing with a good product, which produces few overheads.
This has some drawbacks. For example, you could create a VPN that only obfuscates traffic with a rot (13) and that would be very fast indeed. The trouble is, using it, system administrators all over the world and all security personnel would realize that the VPN is fast because it does little.
But another way to hide the performance loss would be to run it in supervisor mode, as part of the kernel. Again, VPN appears to produce little latency. But this would be a trick, which senior sysadmins would respond to with a shrug.
That said, I don't give a damn about how fast it is or how little latency it has. It works in kernel mode, other VPNs don't, so I can't compare. Incorporating the VPN into the kernel was a clever trick, but it lasts as long as.
So now I need a KPI to decide how secure this VPN is, a KPI that isn't the usual "how robust is your algorithm". The world is full of very robust encryption algorithms, but accidents still happen. Why?
Because in a more or less indirect way, computers are systems managed by humans. And while much of the administration task is automated, when it comes to configuring and setting up equipment that provides security, IT staff is the cornerstone of the infrastructure.
But what does it mean that "the human being is the cornerstone of the infrastructure"?
It means that IT security experts spend time reading the logs, entering them into special databases where automated systems create alerts when they see wrong things, perhaps attracting the attention of human operators when something is wrong.
Human operators, in turn, have to understand what is going wrong, why it is going wrong, and from there find a solution.
When we talk about safety we always talk about OBSERVABILITY.
System managers need observability to understand what is going wrong, to know WHY it is going wrong, to know if it is an attack or a malfunction, to know if it matches a threat model and so on.
Of course, now we will have to ask what exactly Wireguard's observability is. And the answer is that, even when we put it in "debug" mode, observability is absent, incompetent and completely useless.
Watch this:
How did I get this? I have no idea. I have no idea because these are two identical virtual machines that I have configured following the same procedure, which produces a correct wg0.conf file.
And I say correct because the only tool I can use, “wg”, reads it and configures it correctly for me. (Obviously the IPs and keys are different for each machine, etc etc).
For my part, that is, on the part of the customer, there is nothing that can improve. The two files are identical, only the client's public keys and IPs change. (obviously). One virtual machine works, one doesn't.
Ditto on the server side. Where the only thing I know is that WG understands the peer, but then “Invalid handshake initiation”.
But above all, reading those registers, WHAT exactly is invalid in "starting the handshake"? What's wrong?
If I were to give the alarm to a specialist, what would I raise? Aren't there the right keys? Is the checksum of the UDP packet invalid? We know? No. The log message says nothing. Finally, the IT department is asked to call someone and say "something unspecified is going wrong". The worst thing you can say to a person on night duty. Worst EVER.
So you wonder what could be wrong with a UDP packet and first decide to check the checksum.
So you will do a nice tcpdump and you will see that (because there are others that use the VPN) some packets have the right checksum and others the wrong one – you should figure out which packet is complaining about the log. But the log doesn't say. You need to log out of the entire user base and try again with only one user. But of course you can't.
The first temptation you should NOT give in is to disable checksum checking of UDP packets. You don't know if that's the problem, and it's not good practice anyway. So how do you prevent something you don't understand?
Here we are. Anyone who has worked in IT for many years knows that, for the most part, security issues aren't level 1-7 issues. humans have not understood, or have misconfigured.
Either it is a reaction to a problem that turns out to be worse than expected, or it is a wrong assumption.
The systems that deal with perimeter security, therefore, must mitigate as much as possible the risk of administrators doing the wrong thing. They need to clarify what's going on. They need to clarify why something is happening. They have to give control. They must be observable.
But wireguard can't. Obviously, working at the kernel level, they cannot afford to have very extensive logging, enough to allow for intrusive observability. As a result, administrators are driven to ignorant decisions: what setting improves the validity of the "handshake initiation"? Who knows?
No system that is not observable is safe, because it does not allow the people who supervise it to know exactly what is going on.
I don't care how robust the algorithm is. Don't bother me with that. I don't even care how strong the handshake is. I do not care.
I don't care, because being undetectable and recording very little, wireguard:
- weakens system administrators
- weakens the alarming system
- undermines the response of the security team.
Even if the cryptographic algorithms were the deadliest in the world, they would have an unacceptable cost: to blind the company's security team, or at least the system administrator.
And this, in a VPN system, or perimeter security, is simply UNACCEPTABLE.
Wiregard is insecure, because anything it gains in simplicity of implementation and performance loses in observability.
It's like putting in a security door, which is super strong but requires you to turn the rest of the house into a camping tent. You have a super strong door and the rest are now weak. Likewise, using wireguard, you will have a robust encryption algorithm, but the rest of your corporate or personal security will be gone, because you have no idea what's going on and why.
I still don't understand why Torvalds agreed to insert this scam into the kernel