Why is WireGuard undetectable?
I wrote on several occasions about WireGuard, an open source VPN solution that took the world by storm for its security, reliability and speed. WireGuard was immediately integrated in the Linux kernel and is now available in any recent Linux distribution. But there are many open source VPN solutions already, some of them acting as VPN standards for the industry, so what makes WireGuard better?
The key aspect for a VPN is the security it provides. After all, this is why we bother with a private network in the first place: we want better security guarantees than the ones offered by the existing network, the Internet. And to be fair, any VPN solution does provide better security. All of them use strong encryption and have password or key based access. But WireGuard has something extra right down at the core communication protocol. It is so far the only VPN solution that uses UDP for all messaging between the client and the server. What is UDP and why it’s so important? Let’s find out.
Network protocols: TCP and UDP
Since the invention of the computer network, only two fundamental message transfer protocols exist: a connection based protocol called TCP and a send-and-forget UDP protocol. Both have pros and cons but TCP always had the better features: connection monitoring, message counting, it would keep track of lost messages and resend them, it enabled stateful, two way communication between the server and the client: in short it was all you needed to create client-server applications without thinking too much about it. It’s a sort of all-inclusive protocol.
Not so with UDP. UDP can hardly be considered a protocol at all. All it does is it sends a message from one computer to another, or to many at once. That’s it. You don’t know if the message arrived, if it was broken into parts, if all parts arrived uncorrupted: you know nothing at all about the communication that happened. You just send a message and lose all control over it after that. There is no established connection between the messaging parties. UDP is useful if you want to send control messages for example from time to time, messages that you don’t really care about like some sort of beacons. This was UDP’s intended purpose and that’s how it was mainly used, until WireGuard happened.
Why would anyone want to use UDP for actual communication?
So why would you implement a client-server application over a protocol designed to send control messages that are not sure to arrive at the destination? When we talk about normal applications, you have a designated pattern, protocol, architecture and approach. You use these tools to build your application faster and be sure it works as intended with minimal bugs. But when we talk about security critical applications things are different.
You see, when you send a message over TCP a lot of stuff happens in the background. The application makes a lot of noise. A lot of messages are sent back and forth as the protocol needs to be sure that everything happens as expected. All this chatter provides important information for a bystander watching everything. But among all messages, one is of utmost importance: the one that establishes the TCP connection between the client and the server.
How does it happen? Each TCP network application has a port it listens on for connection requests. For example a VPN server like OpenVPN will run in the background and keep listening on its designated port for connection requests. This means that port is “open”, an application listens on that port for clients. When a client wants to connect to OpenVPN, it has to know its IP address and its port number. It has to make a TCP request to that IP and port number, a string combination usually looking like this: 192.168.68.100:5000. When a client sends a connection request to this address, the server will respond with a connection established message. This happens before any authentication is made and before any other messages are exchanged. And this is exactly the offending behavior for a security critical application.
UDP has no concept of connection
When we send a message over UDP, no connection attempt is made. You simply send the message and forget about it. Of course, you have no control over the message and no way to know if it arrived, but the lack of connection is key for a secure critical application.
When a server is listening for connection requests on a port, you can scan the server to see what ports are open. This is called port scanning and can be done easily enough, there are even free online applications that allow anyone to scan any target on the Internet. The result? A set of open ports that reveal the applications that listen for connection requests. And again, making a connection is a legit TCP operation, it predates authentication. If a port is open, you can connect to it. If the server then asks for passwords and more, that’s another business but at least the connection request is always granted. This means the attacker now knows two things about their target: an open port and maybe the associated application that listens on that port. If they know the application, they can look for exploits. Game over.
UDP however has no knowledge of connections. It receives the message and nothing is sent back. No acknowledgement, no connection keeping, no counting, nothing. The message is received and forever lost for the sender. This makes UDP port scanning a very unreliable business. If there is a UDP application listening on port 5000 and it answers a message from a client, then yes, the scanner knows UDP port 5000 is open. If the application listens on UDP port 5000 but only answers if specific requirements ar met, nobody will ever know UDP port 5000 is open because nobody will ever get an answer back. Unless they stumble upon the requirements of course.
How does WireGuard evade detection?
Slowly we arrived at WireGuard’s brilliant security feature: how does it evade detection? Well first of all it works over UDP: there is no connection and no connection housekeeping chatter. But what if an attacker doesn’t know that port 5000 is open for WireGuard but keeps trying random messages over that port and in the end somehow triggers a WireGuard response? What if it stumbles upon WireGuard?
Well this is the genius in WireGuard’s brilliance: all communication has to be encrypted with a private/public pair. The server has a public and a private encryption key and the client has the same. The client needs to know the server’s public key to talk to it, and the server needs to know the client’s public key to decrypt the messages it tries to send. If the server doesn’t have the client’s key, no matter what messages it sends, it won’t know how to interpret them and it won’t answer them. In the same way, if the client doesn’t have the server’s key, no matter what messages it receives, it won’t know how to decrypt them and won’t answer back. Essentially both the server and the clients act as black holes for any attacker. Any port scan will yield nothing. No attacker will ever know I have WireGuard installed.
I always love brilliant solutions but this time the brilliant solution is outdone by its meme-like simplicity. There is no application listening if it never answers.
I hope you learned something new today. I enjoyed writing this article and I hope you will enjoy reading it. I wrote once a working example of a UDP communication that was emulating TCP. If I find it I will clean it up, write an article about it and post it on github. Till then, see you next time!
