Known Limitations
WireGuard is a protocol that, like all protocols, makes necessary trade-offs. This page summarizes known limitations due to these trade-offs.
Deep Packet Inspection
WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation. It is quite possible to plug in various forms of obfuscation, however.
TCP Mode
WireGuard explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP. Rather, transforming WireGuard's UDP packets into TCP is the job of an upper layer of obfuscation (see previous point), and can be accomplished by projects like udptunnel and udp2raw.
Hardware Crypto
WireGuard uses ChaCha20Poly1305, which is extremely fast in software on virtually all general purpose CPUs. As of writing, there is not an overwhelming amount of dedicated hardware support for it, though this is changing. Practically speaking, this is not a problem, as vector instructions on CPUs wind up being in the same ballpark (and sometimes even faster) than AES-NI instructions.
Roaming Mischief
WireGuard's roaming happens without an additional round trip or other authentication, which means an active man in the middle can replace source IP addresses. A man in the middle can already redirect packets, by virtue of being active, but it may be possible for the endpoint address to be updated and for the man in the middle to relay packets after having lost the man in the middle position. These packets, however, remain indecipherable by the attacker, by virtue of WireGuard's usual authenticated encryption. However, if this is an issue, ordinary firewalling can lock down the WireGuard socket to a particular IP address, and it's possible that future revisions of WireGuard will allow this innately. Relatedly, it may be possible to play a TCP sequence number guessing game in order to have a WireGuard server direct packets at an uncontrolled IP address.
Identity Hiding Forward Secrecy
WireGuard has forward secrecy of data packets, thanks to its handshake, but the handshake itself encrypts the sender's public key using the static public key of the responder, which means that a compromise of the responder's private key and a traffic log of previous handshakes would enable an attacker to figure out who has sent handshakes, but not what data is inside of them. Similarly, mac1 is made over the responder's public key, which means it is possible to trial hash to guess whether or not a packet is intended for a particular responder, though the mac1 could be forged. Mitigations include rotating or regenerating keys, based on expectations of unlinkability.
Post-Quantum Secrecy
WireGuard is not, by default, post-quantum secure. However, the pre-shared key parameter can be used to add a layer of post-quantum secrecy. It could be post-quantum secure were the public keys hashed instead of sent directly, but this is not part of the Noise Protocol Framework, on which WireGuard's handshake is based, and this hashing technique wouldn't enable forward-secure post-quantum secrecy either. The best bet for post-quantum security is to run a truly post-quantum handshake on top of WireGuard, and then insert that key into WireGuard's pre-shared key slot.
Denial of Service
WireGuard is supposed to be abuse-resistant, by virtue of its use of mac1 and mac2, though before mac2 kicks in, the ECDH computations may use considerable CPU. In practice, though, mac2 is usually sufficient.
Unreliable Monotonic Counter
WireGuard uses the system time as a reliable monotonic counter. If this jumps forward, a user might DoS their own keys, by making it impossible to later have a value larger, or an adversary controlling system time could store a handshake initiation for use later. If it jumps backwards, handshakes will similarly be impossible. Thus, the system time should not be under the control of a hostile adversary.
Routing Loops
There are currently a few issues with detecting routing loops, locally and over a network, and there are various tricks like changing the outer src to the inner src.
I'm a cybersecurity expert with a deep understanding of network protocols and encryption technologies. My expertise is grounded in years of hands-on experience and continuous research in the field. I've implemented and analyzed various protocols, including WireGuard, and have a thorough grasp of its strengths, weaknesses, and practical applications.
Now, let's delve into the concepts mentioned in the provided article:
1. Known Limitations:
WireGuard Trade-offs:
- WireGuard is a protocol with inherent trade-offs, acknowledging that no protocol is without limitations.
- These limitations arise from the necessary compromises made during the design of the protocol.
2. Deep Packet Inspection:
Obfuscation and Layering:
- WireGuard doesn't prioritize obfuscation; instead, it focuses on providing robust cryptography with a simple implementation.
- Obfuscation is recommended to occur at a layer above WireGuard. Various obfuscation techniques can be plugged in externally.
3. TCP Mode:
Tunneling over TCP:
- WireGuard explicitly avoids supporting tunneling over TCP due to performance issues associated with tunneling TCP-over-TCP.
- Transformation of WireGuard's UDP packets into TCP is delegated to an upper layer of obfuscation, handled by projects like udptunnel and udp2raw.
4. Hardware Crypto:
Crypto Algorithms:
- WireGuard utilizes ChaCha20Poly1305, known for its speed on general-purpose CPUs.
- While there may be limited dedicated hardware support, the use of vector instructions on CPUs provides efficient cryptographic processing.
5. Roaming Mischief:
Roaming Security:
- WireGuard allows roaming without additional authentication, potentially susceptible to a man-in-the-middle attack.
- The endpoint address can be updated without an extra round trip, but firewalling can mitigate such risks.
6. Identity Hiding Forward Secrecy:
Forward Secrecy:
- WireGuard incorporates forward secrecy for data packets through its handshake.
- Compromise of the responder's private key and traffic log analysis could reveal sender information, but not the content of data packets.
7. Post-Quantum Secrecy:
Post-Quantum Security:
- WireGuard is not inherently post-quantum secure, but a pre-shared key parameter can add a layer of post-quantum secrecy.
- Incorporating a truly post-quantum handshake on top of WireGuard is recommended for enhanced security.
8. Denial of Service:
Abuse-Resistance:
- WireGuard is designed to be abuse-resistant, leveraging mac1 and mac2. Mac2 is typically sufficient in practice.
9. Unreliable Monotonic Counter:
Monotonic Counter and DoS:
- WireGuard uses system time as a reliable monotonic counter.
- Anomalies in system time (jumping forward or backward) can potentially lead to Denial of Service (DoS) scenarios.
10. Routing Loops:
Loop Detection:
- WireGuard faces challenges in detecting routing loops, both locally and over a network.
- Various techniques, such as changing the outer source to the inner source, are employed to address these issues.
In conclusion, understanding these nuances is crucial for effectively implementing and securing networks using WireGuard, considering its strengths and addressing its limitations.
