Introduction
The landscape of the Internet is an ever-changing ecosystem, and one of the current collective focal points of it are Virtual Private Networks or VPNs. One can’t help but notice the uptick in the number of advertisem*nts of VPN vendors. A relevant metric of this is the worldwide increase in the search of the term “VPN” in Google via Google Trends.
In Fig. 1, we can observe an upward trend in the graph for the search term “VPN” with respect to time since 2014. People worldwide have become increasingly aware about privacy and handling of their personal data on the Internet. There are many individual reasons that a users would choose to employ a VPN such as to bypass censorship firewalls in some countries.
VPN is a framework to use a private network connection on a public network. It makes it tough for any third-party to track the user’s device and private data. Even after Network Address Translation (NAT), an Internet layman’s IP Address has enough information to reveal their general location. You could try it yourself by going to this website. This is based on the public IP that your ISP provides, and not everyone is comfortable with sharing it out in the open while surfing the Internet.
The methodology employed by the VPN providers is to redirect the client’s traffic to a remote server that could be situated anywhere in the world. The VPN essentially hides the client’s IP behind a brand-new public IP and encrypt the traffic. Furthermore, each time the client connects to the VPN their public IP changes, anonymizing the browser activity.
There have been many tunneling protocols that help establish a VPN connection. Notable among them are IPsec and OpenVPN.
Enter WireGuard
WireGuard is both a communications protocol and an open-source software project that establishes a VPN connection. It is designed in a compact and secure way and has already been integrated to the Linux Kernel.
The inception of this protocol was borne out of a covert traffic tunneling solution that its creator was trying to implement. During his efforts, he realized that protocols like IPsec and OpenVPN operated on large and bulky codebases, which were harder to debug, manage, and set up properly.
That is why at the core of WireGuard’s philosophy are concepts of minimalism, security, and ease-of-use. An example of which can be seen in the size of its codebase itself, which stands at around 4000+ lines compared to 100,000+ lines of code that OpenVPN uses.
IMplementation
WireGuard is a layer 3 network tunnel protocol for IPv4 and IPv6. It runs over UDP in a connection-less way and uses modern cryptographic principles with an authentication style like SSH’s “authentication keys”. It emphasizes simplicity and a compact codebase that could be easily auditable by security researchers.
WireGuard uses modern cryptography paradigms such as Curve25519 for key exchange, BLAKE2s for hashing, and ChaCha20 and Poly1305 for authentication. Breaking through its security is not exactly a walk in the park.
In the WireGuard framework, a brand-new network interface (usually named wg0 by users) gets assigned to each device or peer in the network. The communication among peers is restricted to this interface only.
Features
We will now look at some of the interesting features of the WireGuard Protocol in depth.
CryptoKey Routing
For authentication among peers, WireGuard uses a concept it refers to as “CryptoKey Routing”. In this process a public and private keypair is generated and associated to each peer’s IP address. This IP address is allocated to the peer via the WireGuard interface. This interface also holds the information of the peers which are allowed to communicate with it in the form of the peer’s public key and tunnel IP.
The static public key and tunnel IP information can be distributed among the peers through any secure out-of-band methodology. Like how distribution of SSH keys work.
If any network packet arrives at the wg0 interface that does not have a source IP which is already allowed, it is rejected.
Stateless, While Stateful
WireGuard appears stateless to the user. The end user only needs to the configure it once, and that is enough for it to start and keep working. It is inherently stateful though, and the state management is taken care of by a set of internal timers.
For example,
- If a user needs to send a packet and no handshake has been established with a peer in the last 120 seconds, a new handshake gets initiated.
- If there is no response of that handshake for 5 seconds, another handshake is initiated.
- If after an established connection, no authenticated packets have arrived for 15 seconds, a handshake is initiated.
This is all done automatically, and the user does not have to keep track of it. Each transition of the state machine has been taken care of.
Key Exchange
WireGuard uses the Noise_IK handshake provided by the Noise Protocol. This handshake is based around Diffie-Hellman Key Exchange.
In this process, a set of ephemeral Diffie-Hellman keypair are generated for each peer in each handshake. These peers would also have the static keypair, which has been shared previously.
The Diffie-Hellman calculations are done using the combination of these keypairs, to generate shared session keys which are used to encrypt and decrypt the communication on a particular session.
This key exchange is 1-RTT in nature, requires no certificate exchanges and is carried out by just exchanging a 32-bytes base64 encoded public key.
Message Types
WireGuard has the following packet message types:
- Handshake Initiation
- Handshake Response
- Transport Data Packet
- Cookie Reply Packet
Let us take a look individually:
A. Handshake Initiation
This is the first packet that the peer, referred to as the initiator sends. It holds a unique index associated with the initiator, an unencrypted Diffie-Hellman ephemeral public key and the encrypted static public key among other fields.
It also contains the MAC (Message Authentication Code) fields, which are used with cookies to mitigate CPU-exhaustion attacks. It is important to take care of such attacks because the Diffie-Hellman calculations can be CPU intensive and bad-faith actors can take advantage of it. The ReDoS attack is a notable example of it.
B. Handshake Response
After the initiation, a response is sent from the responder to the initiator which again holds an unencrypted ephemeral public key generated by the responder. It also contains an empty buffer, which has been encrypted using a key that is calculated based on the ephemeral private key and the static key of the initiator.
C. Transport Data Packet
After the handshake packets are exchanged, shared session keys are calculated based on the exchanged data. There are two session keys, one for encrypting data that is about to be sent and another for decrypting data that has been received. Both the initiator and the responder have these session keys in their state.
WireGuard works over UDP which is an unreliable protocol where messages can sometimes appear out-of-order. We don't want that because that could lead to scenarios such as the protocol trying to decrypt a message without a key exchange beforehand. Awkward.
To take care of that, WireGuard uses a counter field in the data packets paired with an internal sliding window to keep track of the packets that have been received. This counter field is always incremented by 1.
D. Cookie Reply Packet
As mentioned earlier, WireGuard uses MAC fields in the handshake packets for security reasons. If the responder is ever under load from the CPU intense calculations that are happening in after the Handshake Initiation packet, it may choose to not go ahead with sending a Handshake Response packet, but instead can respond with a Cookie Reply packet.
This packet contains a cookie that is calculated using the BLAKE2 hash function with two inputs: a secret random value maintained by the responder that changes every 120 seconds, and the IP address of the initiator.
Upon receiving this cookie packet, the initiator must store the decrypted cookie value and wait for a certain amount of time before attempting a handshake again with the MAC value obtained from the last cookie.
Further details can be found in the official documentation.
Reception from the Internet
Since its debut in 2017, WireGuard has garnered favorable opinions from security researchers and famous tech personalities. This is largely due to the fact that it is faster than its counterparts, while not compromising with security.
It has been integrated into the Linux 5.6 Kernel in March 2020. In 2021, it had also been added to the Windows Kernel. This adds to the speed of this protocol, as the cryptographic calculations run faster in the kernel-space than the user-space.
Popular VPN vendors such as ProtonVPN, SurfShark, and NordVPN support WireGuard as a VPN protocol. Although, NordVPN does it with a slight twist as they have made their own protocol known as NordLynx on top of the open-source WireGuard codebase.
There have been some privacy concerns as well. Since WireGuard does not support dynamic IP addresses by design, it assigns a single IP address to a user which is logged in the memory. WireGuard does not ensure that no identifiable user data is stored in the VPN server.
However, there are solutions to this problem. In the implementation of NordLynx, they get around this concern by using something referred to as a “Double NAT System” which uses two interfaces instead of one and supports dynamic short-term IP addresses.
WIREGUARD SUPPORT IN BREAKINGPOINT SYSTEMS
As of the 2022-18 release of the ATI Strikepack subscription, WireGuard is supported as an application protocol that you can test your network with. With BreakingPoint Systems, you can mix WireGuard traffic with thousands of other types of application traffic to test the resiliency of your network devices.
For more details about Keysight BreakingPoint Systems and to test your network equipment against the most updated network traffic available on the Internet, visit the BreakingPoint Systems landing page.
