|
|
|
|
|
|
by growse
2281 days ago
|
|
|
> .. for no apparent reason by the WireGuard developers... It's a very weird assertion that the Wireguard devs just threw the software together at random, choosing parameters for "no apparent reason". > What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that? Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure? TLS is famously susceptible to downgrade attacks. (https://blog.ivanristic.com/2013/09/is-beast-still-a-threat.... etc.) Ultimately, it's a value judgement. You can either have resistance to downgrade attacks (which have themselves proven to be quite problematic), or you have interoperability across multiple versions and configurations of endpoints. Increase the configurability of the protocol, and you massively increase the complexity. Increased complexity means increased testing burden and ultimately increased risk. If Wireguard needs to be fixed in a backwards-incompatible way, then we'll find ourselves with a new version of Wireguard that doesn't work with the old version. |
|
|
Right, and maybe this is actually in improvement in security overall but it just externalizes the downgrade attack since once there are multiple versions of WG floating around with different vendors/clients only supporting a specific version you end up similarly vulnerable since you need to run multiple WG endpoints of different versions.
And since it’s a kernel module you’ve made the hassle of doing so very annoying compared to one line in a config file.
IPSec feels messy and complex specifically because the world is messy and complex. WG is fantastic and I love it dearly for “the 90% case” where I have total control over all peers.