Have all the bugs in OpenSSL over the years taught us nothing?
The Linux Foundation is still funding OpenSSL development after scathing review of the codebase[1], so I think it's fair to say things haven't changed a bit.
TweetNaCL to the rescue.
Wireguard has a concept of identity as long term key pairs, but since the algorithm is based on Diffie-Hellman, and arriving at a shared secret ephemeral key, it's only useful for establishing active connections. The post-quantum version of Wireguard would use KEMs, which also don't work for general purpose PKI.
What we really need is a signature based handshake and simple VPN solution (like what Wireguard does for the Noise Protocol Framework), that a stream multiplexing protocol can be layered on top of. QUIC gets the layers right, in the right order (first encrypt, then deal with transport features), but annoyingly none of the QUIC implementations make it easy to take one layer without the other.
There's a lot of benefits for sure, mTLS being a huge one (particularly when combined with ACME). For general purpose, spoke and hub VPN's tunneling over QUIC is a no-brainer. Trivial to combine with JWT bearer tokens etc. It's a neat solution that should be used more widely.
However there are downsides, and those downsides are primarily performance related. For a bunch of reasons, some just including poorly optimized library code, others involving relatively high message parsing/framing/coalescing/fragmenting costs, and userspace UDP overheads. On fat pipes today you'll struggle to get more than a few gbits of throughput @ 1500 MTU (which is plenty for internet browsing for sure).
For fat pipes and hardware/FPGA acceleration use cases, google probably has the most mature approach here with their datacenter transport PSP [2]. Basically a stripped down per flow IPsec. In-kernel IPsec has gotten a lot faster and more scalable in recent years with multicore/multiqueue support [3]. Internal benchmarking still shows IPsec on linux absolutely dominating performance benchmarks (throughput and latency).
For the mesh project we ended up pivoting to a custom offload friendly, kernel bypass (AF_XDP) dataplane inspired by IPsec/PSP/Geneve.
I'm available for hire btw, if you've got an interesting networking project and need a remote Go/Rust developer (contract/freelance) feel free to reach out!
1. https://www.rfc-editor.org/rfc/rfc9484.html
2. https://cloud.google.com/blog/products/identity-security/ann...
3. https://netdevconf.info/0x17/docs/netdev-0x17-paper54-talk-s...
I don't believe you could implement RFC 9484 directly in the browser (missing capsule apis would make upgrading the connection not possible). Though WebTransport does support datagrams so you could very well implement something custom.
The question is what does QUIC get you that UDP alone does not? I don't know the answer to that. Is it because firewalls understand it better than native wireguard over UDP packets?
The net result of two reliable transports which are unaware of each other is awful.
What does QUIC get you that TCP over Wireguard over UDP does not?
> 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.
This comment https://news.ycombinator.com/item?id=45562302 goes into a practical example of QUIC being that "layer above WireGuard" which gets plugged in. Once you have that, one may naturally wonder "why not also have an alternative tunnelling protocol with <the additional things built into QUIC originally listed> without the need to also layer Wireguard under it?".
Many design decisions are in direct opposition to Wireguard's design. E.g. Wireguard (intentionally) has no AES and no user selectable ciphers (both intentionally), QUIC does. Wireguard has no obfuscation built in, QUIC does (+ the happy fact when you obfuscate traffic by using it then it looks like standard web traffic). Wireguard doesn't support custom authentication schemes, QUIC does. Both are a reasonable tunneling protocol design, just with different goals.
I.e. the advantage here is any% + QUIC%, where QUIC% is the additional chances of getting through by looking and smelling like actual web traffic, not a promise of 100%.
If the data can't be decrypted (or doesn't look like plain text web traffic) by the adversarial network admin, the QUIC connection can just be blocked.
Work laptops typically have a root cert installed allowing the company to snoop on traffic. It's not unfeasible for a nation state to require one for all devices either.
The next step is to block all connections that can't be decoded by the root cert. That's not really that far off when you think about it. If it's not typical HTTPS/HTML traffic, the adversarial network admin can simply drop packets and connections.
A similar thing is happening today in Spain when a soccer game is on. If anything looks suspicious they pretty much block the subnet, because it's easier to block entire subnets than to figure out how to block the protocols that transmit the pirate stream. This is acceptable in Spain, I guess. I'm not sure why.
I'm arguing if an adversarial network admin decides to nix QUIC on the network because they can't detect a VPN, don't be surprised when it suddenly happens worldwide until QUIC helps them (or Broadcom, e.g.) figure out which streams are VPNs and which aren't.
And the "more valuable targets" argument is self-defeating because if there aren't as many high value targets using something then there aren't as many attackers looking for vulnerabilities in it either. Moreover, if someone finds one in TLS (or anything) then they can launch exploits against multiple targets simultaneously rather than waiting to move on to the second target until after the first investigates the attack and publishes a patch for everyone else to use.
My point isn’t that Wireguard should’ve used TLS/QUIC. Is that if you want a connection oriented transport encryption, you should almost certainly use TLS 1.3 in some fashion even if web compatibility isn’t a concern.
I think I see your argument, in that it's similar to what sshuttle does to eliminate TCP over TCP through ssh. sshuttle doesn't prevent HOL blocking though.
Agreed, but that wasn't what I was saying. Read it carefully next time before downvoting.
If the argument is if wireguard is a state machine, well, TCP over wireguard is just fine. And that's exactly what I said.