Slavius

I went through some reviewers LinkedIn profiles. Most of them are 22-30y old claiming to be senior SW developers, architects or team leads. Maybe your problem isn't the resume but an imposter syndrome...

Are you saying that fixed parameters chosen for no apparent reason by the WireGuard developers are better than modularity and interoperability of IPsec? 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?

Yet still it spreads lies. There's not only 4 pieces of information needed to establish IPsec (they even cannot count as they mention 5 pieces). In addition to named remote and local IP addresses, subnets and a pre-shared key you also need: * mode of operation (transport or tunnel) * exchange mode (base, main, aggressive or ikev2) * policy mode of operation (encrypt and/or protect - yes encryption is optional with IPsec) * Phase 1 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether you/remote uses a PFS (if so, then also DH Group) * Phase 2 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether or not to use NAT traversal (changes the protocols and ports needed to be opened on the firewall(s))

If you don't know some of these parameters chances are you won't be able to establish the tunnel no matter how hard you try.

Plus you need to know all the vendor quirks as establishing IPsec from Cisco to Fortigate or Sophos is not straightforward.

Then you may end up playing with NAT-exclusions, SNAT/DNAT if both sides of the tunnel have the same or overlapping IP ranges.

Setting up IPsec is definitely not an exchange of 4 parameters...

He does the math to prove that when you subtract all the mandatory protocol and frame headers you end up with practical maximum of 949.28 Mbps on 1 Gbps line. Providing charts with 1011 Mbps in favor of WireGuard makes all the comparison at least dubious. Another thing he mentioned is the test compares ChaCha20 cipher with AES256-GCM which is totally unfair. Why would you invest so much in perfect code then to fake the benchmarks?

Well, it seems FreeBSD/pfSense people are not very happy with it. At least the benchmark results seems questionable. Read jwt's comment at the bottom: https://forum.netgate.com/topic/132375/installing-wireguard-...

You clearly have limited view on application bugs. Let me elaborate a bit on bugs causing application dissatisfaction and UX frustration without crashing much, much worse than a simple error message along the lines: "OS has terminated application X because it has performed an illegal operation."

Data corruption - reading or writing corrupted data - files cannot be read, saved files get corrupted, API calls from/to external applications/systems fail or pass incorrect data Rendering problems - corrupted images, incorrect colors, improper content encoding, visual stuttering, audio deformation, audio skipping Input/output lags - unregistered kaystrokes, missed actions and responses to external events, mouse stuttering and misbehavior Improper operation - inconsistent results - repeated rendering yields different results (html), formulas/calculation results in data is inconsistent (excel, DWH) Access violation - access gained to invalid or protected areas - unprivileged access, license violations, access to areas protected by AAA, data theft (SQL injection, database dumps)

and others. If I figure out the application I'm using (web-browser) allowed a hacker to steal my data he would not have otherwise access to I would be more pissed off than if it crashed and I found an error about it in system log.

Apps are supposed to keep their state either by saving your work regularly to persistent media or keeping your data off-client. We're living in 21st century in a cloud era FFS.

Keep running your app although integrity corruption within the application happened is putting user data at risk. IMHO an application that corrupts 3 days long presentation file save is to every user more frustrating than the one that crashes due to error leaving you with 5 minutes of unsaved changes lost.

Microsoft have invented "Application Recovery and Restart" exactly for this purpose.

Corrupting SP is part of almost every exploit and I can guarantee you that it is very likely (going to cause harm on your system). Try to pull Metasploit GIT repo to get some idea about thousands of payloads that do corrupt SP without crashing the host...

...or is being remotely exploited and it silently succeeds. Who wants that?

Kernel is modular. Literally everything can be enabled/disabled.

Aviation has strict regulations and that's why most critical systems have redundant parts. Putting a sigle critical component into plane is stupid in and of itself. Think of simple freezing in high altitude or overheating otherwise. On the other hand I would rather fly in a plane whos altitude meter shuts down and switches to redundant circuit other than letting it report incorrect values...

So what happens when your browser crashes? I experience that on a regular basis. Id' rather have my browser crash/killed instead of slowly overwriting my filesystem buffers or corrupting my stack pointer... Other than that browser are multi-thread/process applications. Usually only a single tab or a plugin crashes unless core browser process is affected. Most users would accept the trade off between crashed browser and infected/corrupted system.

Linux is a modular kernel. I'm not aware of a single thing you can't disable or make modular during config/compile. I woudn't like to be the guy who's medical equipment killed him by slowly decreasing his oxygen levels due to buffer overflow either. If you're in this kind of business you take responsibility by discovering and fixing bugs which would go unnoticed otherwise. And if the life of your patients really depend on your equipment then having a redundant component within your device is a must.

I can't think of single useful piece of software nowdays that is exposed to public and can't run in active-active load balanced or clustered scenario. If your kernel/system/userland-app misbehaves it simply needs to be shut down, reported and examined. It might have been some random memory block the last time your app made an buffer overflow, but it could as well be the stack pointer next time...