hckrnws

AFAIK any app can opt out of VPN by binding to the wifi/cellphone interface directly, bypassing the OS's routing tables. You need to enable "block connections without VPN" to prevent any leaks.

Because the public key is the identity in the Wireguard protocol. If Alice and Bob want to communicate with each other over Wireguard, then Alice has to know Bob's public key, and Bob has to know Alice's public key. If they don't already know each other's public keys, then that information has to be exchanged in a secure manner at least once, in order to prevent nosy Mallory from impersonating one of them. How can Alice and Bob exchange their public keys securely? Not with Wireguard, because they'd need to already know each other's public keys for that! So they need to use some other secure mechanism as a bootstrap. Hence, out of band distribution.

In practice, Alice and Bob will often be two machines that are under control of the same entity, and that entity will transfer the key material from a third machine to the Alice and Bob machines over SSH or HTTPS. In those cases, the out of band mechanism is "SSH/HTTPS via trusted relay machine".

> Tailscale supports connecting arbitrary wireguard peers into the network

Now screaming internally because every router I've had that's supported Wireguard I wish I could have just joined into a tailnet directly for subnet routing... and I can't find anything else that just plays nice either.

By that logic, we should avoid TCP as the Linux kernel implementation has had plenty of CVEs. Thankfully our expert critical thinking helps us acknowledge that as silly.

Yes, except peer relays require the peer not to be behind NAT instead of being behind traversable NAT.

What I'm thinking of is something far more opportunistic; the way to piggyback on an existing peer (or a set of such) as a pseudo-relay, if and only if network conditions allow, and this is actually something that is worth doing in the given situation.

No idea if this is what they meant, but it’s plausible that client battery usage goes up when connected to Tailscale using an exit node. Suddenly, a lot more traffic has to be processed in userland, on the CPU. Ordinary internet transit might be offloaded to the kernel or hardware such that it’s more battery-efficient.

Then again, that begs the question of what you’re heavily using exit-node-routed internet links for that Tailscale’s battery draw is noticeable. Most network-intensive internet tasks draw way more power to drive whatever the application is, such that VPN overhead is a rounding error.

The battery powered device is a client to a remote exit node. Normal VPN basically

(Tailscale cofounder) Yes, that’s most of it. Most packet-level optimizations are necessarily platform specific and this post was mostly about the linux dataplane.

That said, the architectural multiqueue improvements and memory optimizations are useful starting points to build on for every platform.

Right, a lot of that trust is implicit and we don't think about it every day. But for threat modeling, it helps to spell out the chain of trust explicitly:

  * You trust the browser/OS

  * Browser trusts the root cert store (either embedded in the browser installation or managed by the OS)

  * Root cert authenticates the twitter.com connection

  * Twitter validates the legitimacy of the account (anti-spam/anti-impersonation/verified user etc.)

  * You trust that the person who made the post on the Twitter account is the person you want to communicate with

If any of these can be violated, it's an opportunity for attack, be it via a technical exploit, social engineering, political favors, whatever. Ultimately it's up to the user to determine what to trust and what level of risk to accept.

No. I specifically said, "lose the formally-verified cryptography guarantees underpinning WireGuard & its implementation" and I pointed out the implementation quirks.

Anywho, given your strong conviction about this, consider suggesting to Jason on the WireGuard mailing list to swap ChaPoly for AES-GCM, or perhaps consider a fork yourself. Good luck.

If you believe that, you don't understand TCP, I recommend reading the actual RFC (RFC 793) and the IP RFC if necessary.

A port identifies a process, an IP address identifies a machine. The machine receives the packet, and then passes it to the process, since it's the machine that needs to receive the packet before routing it to the process, it's the kernel with ring 0 privileges that needs to process the packet and map the port to the process.

Io_uring doesn’t have context switching and may not have memcpy. The trickier thing I suspect to get with wireguard is the encryption and GSO offload

I do not understand why people continue parroting this performance nonsense.

Memory copying is on the order of 100 gigabytes per second. You can do 80 full payload copys and still out-pace a dog-slow 10 gigabit per second connection. If your bottleneck is memory copying you are either doing something very wrong and doing way too many copys or congratulations you have implemented one of the fastest network stacks.

Supervisor calls are also very fast, on the order of 100 ns up to maybe 1 us with all the Spectre mitigations. Even if you did something as stupid as one supervisor call per packet, you would still be getting on the order of 10 Gbps at the long end there and 100 Gbps at the short end. Which, again, means congratulations are in order because you have implemented one of the fastest network stacks. If you do batching and add just 10 us (us, not ms) of latency then that entire cost is so small as to be irrelevant. You are going to bottleneck on your memory copying first.

Network stacks are so slow almost entirely due to poor protocol design and poor protocol implementation. Usually both.