WireGuard: Next Generation Kernel Network Tunnel [pdf](wireguard.com)
wireguard.com
WireGuard: Next Generation Kernel Network Tunnel [pdf]
https://www.wireguard.com/papers/wireguard.pdf
25 comments
I'm a little off-put by the creator's attitude towards clients he didn't have a hand in making[0]. And the fact that 5 months ago he said we'd have a windows client around the corner, and yet after taking a cursory look at the two projects, development on one appears to be stalled, and the other still can't support windows, doesn't bode well.
I'm insanely impressed that he's come up with something so good, and I have no knowledge of cryptography and writing truly secure code, so I don't like to complain like this... but it would be nice to have a real timeline so that we can make our own decision about whether we want to use the closed source alternatives.
[0]https://news.ycombinator.com/item?id=16515637
I'm insanely impressed that he's come up with something so good, and I have no knowledge of cryptography and writing truly secure code, so I don't like to complain like this... but it would be nice to have a real timeline so that we can make our own decision about whether we want to use the closed source alternatives.
[0]https://news.ycombinator.com/item?id=16515637
Your comment is very misleading. Reading what you linked to, creator has the (extremely legitimate) concern of users relying on closed source implementations of WireGuard. Which is not at all the same as "clients he didn't have a hand in making"
I read that based on his ignoring tunsafe's author's comments, and the fact that he apparently unilaterally blanned the author from the wireguard subreddit.
I don't know either person at all, I only found out about tunsafe and the "controversy" a few hours ago after seeing this post and googling for the windows alternatives that "are not recommended" but are mentioned on the wireguard site.
I admit I did editorialize a bit more than I should have.
I don't know either person at all, I only found out about tunsafe and the "controversy" a few hours ago after seeing this post and googling for the windows alternatives that "are not recommended" but are mentioned on the wireguard site.
I admit I did editorialize a bit more than I should have.
I'm a bit unsure about the fact that Wireguard has no negotiation capabilities whatsoever. On the one hand this feature makes the configuration of tunnels dead simple as opposed to e.g. IPSec but on the other hand it also means that all participating systems are extremely tightly coupled. If one system updates to a kernel that contains a Wireguard version with crypto changes then all peers have to update their Wireguard versions at the exact same time or the tunnels break.
This is easy if you have point-to-point tunnels where you control both ends of the connection but could potentially be a nightmare for tunnels to other companies or road-warrior setups.
I fear that in these cases many will be forced to stick with IPSec due to these constraints.
No. If a new version of WireGuard comes out with new capabilities it would be done by having that new version understand the old system and you can make a choice if you support it or not.
However that will not really be an issue for a many years and there are many ways how that can be handled in the future.
However that will not really be an issue for a many years and there are many ways how that can be handled in the future.
You cannot really predict this because you don't know when a weakness in a cypher is discovered. Yes it might never happen but it might also happen three days from now. Any piece of software that involves cryptography must be able to change the used primitives quickly in case they are compromised.
Where do you have the information about how Wireguard would handle such a transition from? Looking at https://www.wireguard.com/protocol/ I can see no protocol version or other means to distinguish between an old and new version of the protocol. Also this would introduce additional configuration and a negotiation step which seems to run counter to the motivation of the project.
Not preparing for for this inevitability seems foolish which leads me to believe that this was not an oversight but a deliberate design decision by the creators of Wireguard.
Where do you have the information about how Wireguard would handle such a transition from? Looking at https://www.wireguard.com/protocol/ I can see no protocol version or other means to distinguish between an old and new version of the protocol. Also this would introduce additional configuration and a negotiation step which seems to run counter to the motivation of the project.
Not preparing for for this inevitability seems foolish which leads me to believe that this was not an oversight but a deliberate design decision by the creators of Wireguard.
There are 3 reserved bytes in each of the handshake messages [0] which I imagine would be used for this purpose. There's also a full byte for message type, of which I think only 0x1 through 0x4 are currently defined.
[0] Page 10 onwards of https://www.wireguard.com/papers/wireguard.pdf
[0] Page 10 onwards of https://www.wireguard.com/papers/wireguard.pdf
While this is a possibility it is still strange to not specify something like the protocol version intentionally. Even if in an updated implementation these fields would be used for something like that they still couldn't communicate properly with an older implementation which doesn't understand the new semantics of these fields.
Also looking at the struct it seem the three bytes are only reserved in order to align the following fields on 4-byte boundaries.
If the authors had the intent to allow for some kind of asynchronous update path then surely this would be built explicitly into the protocol right from the start.
Also looking at the struct it seem the three bytes are only reserved in order to align the following fields on 4-byte boundaries.
If the authors had the intent to allow for some kind of asynchronous update path then surely this would be built explicitly into the protocol right from the start.
> If the authors had the intent
Fortunately I know exactly what I was thinking. Each message has an explicit type. The set of types exists in the first byte with the remaining three reserved for future additional use, perhaps for naming types. The cryptography is tied to the version by way the identifier and construction constants.
Fortunately I know exactly what I was thinking. Each message has an explicit type. The set of types exists in the first byte with the remaining three reserved for future additional use, perhaps for naming types. The cryptography is tied to the version by way the identifier and construction constants.
The discussion in https://news.ycombinator.com/item?id=17690815 is meaningful. There is, apparently, some disagreement about how the protocol versioning should be interpreted: zx2c4 (J.Donenfeld, wg creator) refers to the "v1" string used in the construction as the version identifier; tptacek refers to the primitives and the separator strings; I consider the whole thing.
Regardless, it is clear that there are numerous ways that can be backward compatible to extend wireguard into v2. IIUC, the deliberate design decision is that "we are not baking any specific one-true-way". It's not "not preparing for the inevitability", it's "the way protocol agility has been done so far has failed, we defer this decision closer to the time we need it".
Regardless, it is clear that there are numerous ways that can be backward compatible to extend wireguard into v2. IIUC, the deliberate design decision is that "we are not baking any specific one-true-way". It's not "not preparing for the inevitability", it's "the way protocol agility has been done so far has failed, we defer this decision closer to the time we need it".
Thanks for the pointer. I couldn't find any (semi-)official information about this and seeing that the developers indeed care about this puts my concerns at ease to some extent.
I don't think there's any disagreement. Tom and I are both referring to the same things using slightly different words.
Yes. But in the real world negotiation has consistently been a huge problem leading to lots and lots of problems.
I rather put my stack into the best currently known crypto rather then a highly complex cipher negotiation process.
I rather put my stack into the best currently known crypto rather then a highly complex cipher negotiation process.
In terms of negotiation there is a lot of room between the two extremes of "none" and "highly complex" but I agree that one of the big appeals of Wireguard is that you no longer have to fill out weird spec sheets to coordinate the used cipher suites with the admin on the other side of the connection.
Having said that I still would have preferred for something like a single increasing integer as the "cipher suite version". This would have allowed for the option of updating Wireguard asynchronously on both ends without any additional configuration or cipher suite coordination with the peer.
Having said that I still would have preferred for something like a single increasing integer as the "cipher suite version". This would have allowed for the option of updating Wireguard asynchronously on both ends without any additional configuration or cipher suite coordination with the peer.
> Having said that I still would have preferred for something like a single increasing integer as the "cipher suite version".
This already essentially exists. If the first byte of an initiation message is 0x1, then it means you're using "Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s" "WireGuard v1 zx2c4 [email protected]". It seems like this thread is going in circles based on incorrect information about how the thing actually works.
This already essentially exists. If the first byte of an initiation message is 0x1, then it means you're using "Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s" "WireGuard v1 zx2c4 [email protected]". It seems like this thread is going in circles based on incorrect information about how the thing actually works.
As you have stated elsewhere negotiation has been a huge problem in other protocols and makes things much more complicated and I agree with that. My concern was merely with how absolute this stance is i.e. if the sentiment runs along the line "Wireguard will only ever support a single version and potential upgrade paths are the problem of the users" or more like "Wireguard will avoid negotiation wherever possible but when the cipher primitives are deprecated (not broken) by the community we might support introducing a replacement but keeping support for the old primitives for a while for upgrade purposes".
Have you considered mentioning the way you intend to deal with cipher breakage/deprecation more explicitly on the Wireguard page?
Have you considered mentioning the way you intend to deal with cipher breakage/deprecation more explicitly on the Wireguard page?
... but, that's exactly the root cause of previous failures. wireguard is basically saying "we don't know how to do that well enough, so we're not baking it in for now".
Why does the "increasing integer" matter to you? In what way is it better than "I am willing to protocol 1, 4 and 7" (implicitly "but not 2, 3, 5, 6, 8, 9, 10,"...)? And the "I am willing to .." is just a successful handshake. You try in order of preference; If you succeed, other side supports it. If you don't, you go to the next one. Wireguard does not produce a response unless to a non-confirming attempt.
Why does the "increasing integer" matter to you? In what way is it better than "I am willing to protocol 1, 4 and 7" (implicitly "but not 2, 3, 5, 6, 8, 9, 10,"...)? And the "I am willing to .." is just a successful handshake. You try in order of preference; If you succeed, other side supports it. If you don't, you go to the next one. Wireguard does not produce a response unless to a non-confirming attempt.
Previously on HN:
https://news.ycombinator.com/item?id=16326438
https://news.ycombinator.com/item?id=15596963
https://news.ycombinator.com/item?id=17659983
The last one highlighting the last blocker for any serious adoption.
https://news.ycombinator.com/item?id=16326438
https://news.ycombinator.com/item?id=15596963
https://news.ycombinator.com/item?id=17659983
The last one highlighting the last blocker for any serious adoption.
Still awaiting for the official Windows client.........
Looking at the design of WireGuard it seems relatively obvious. Is there a reason it took this long to get such a basic solution?
Simple is harder than complex, as always.
I really wish more people understood this. Over-engineering is the plague of modern software.
It took that long for someone with the skill and interest to get annoyed by the status quo, and sit down and develop a bare-bones protocol that does just what is needed.
Cryptographic knowledge is much more available today than it was 17 years ago when OpenVPN started, so that has probably helped. Some of the constructs used in Wireguard (such as ChaCha20Poly1305) are also quite recent, and didn't exist when OpenVPN started.
Cryptographic knowledge is much more available today than it was 17 years ago when OpenVPN started, so that has probably helped. Some of the constructs used in Wireguard (such as ChaCha20Poly1305) are also quite recent, and didn't exist when OpenVPN started.
The protocol is quite easy to get into, it is well documented to the extent that it is easy to believe that it is in WireGuard's interest that more people develop software that supports the protocol.
Maybe the WireGuard homepage should make an official statement that anyone who implement the protocol and release a client is no longer welcome in the community to discuss the protocol or listen when other people discuss the protocol.
The WG author mentioned in the mailing list that he has reverse engineered Tunsafe and found security flaws. I would like to see that he presents these security shortcomings in order to legitimize his claim instead of keeping it secret. As he is a representative of a security company, it might be a good tactic to not hurt his reputation as it is practice in the security industry to share such information.