6 ms·

Why not “Why not WireGuard?”

174 points by Foxboron 6y ago

armaxt 6y ago
Here comes the mandatory, weekly, coincidentally very organic Tailscale post on HN frontpage, just like every other post on their blog (with one exception). https://news.ycombinator.com/item?id=22759882 https://news.ycombinator.com/item?id=22759882 https://news.ycombinator.com/item?id=22652797 https://news.ycombinator.com/item?id=22652797 https://news.ycombinator.com/item?id=22644357 https://news.ycombinator.com/item?id=22644357 https://news.ycombinator.com/item?id=22585782 https://news.ycombinator.com/item?id=22585782 https://news.ycombinator.com/item?id=22571597 https://news.ycombinator.com/item?id=22571597 https://news.ycombinator.com/item?id=22408269 https://news.ycombinator.com/item?id=22408269 https://news.ycombinator.com/item?id=22192588 https://news.ycombinator.com/item?id=22192588 https://news.ycombinator.com/item?id=21708483 https://news.ycombinator.com/item?id=21708483 According to dang who admitted that most early upvotes come from the same users, this is totally natural and organic. I understand that Paul Graham posts are mandatory for some obvious reason to be on the frontpage, but what's the deal with this company?
- dang 6y ago
  You've been posting these for months. We investigated and found nothing. The last time you did this, I responded in detail: https://news.ycombinator.com/item?id=22761642 https://news.ycombinator.com/item?id=22761642. Unfortunately, the person who has been abusing HN here is you. You've broken the site rules by posting groundless allegations. You've used multiple accounts to do it. You've barraged us with emails using multiple identities. When we've responded with what we found, you've become aggressive. You've even made up false statements about what I've said on the topic, including here. We have no special interest in Tailscale. Our job is to protect HN. As far as I can tell from the data, HN's interest in Tailscale is organic. Presumably that's because the people involved with the company are known to the community from their previous projects and writings. That's this place functioning normally.
brobinson 6y ago
Glad someone did a rebuttal of that article. I came across it a few days ago and was shocked to discover it was by the guy behind ipfire, which I had previously heard good things about.
- wmf 6y ago
  When somebody absolutely positively cannot give up their hardware VPN box yet gets inundated with "WireGuard or die", that's the kind of bitter defensiveness that results. It's just human nature.
  - willis936 6y ago
    Who is giving “WireGuard or die” to people with hardware VPNs right now? It isn’t in any LTS releases right now and won’t be for another year.
    - tuukkah 6y ago
      This was released today: "WireGuard is included in Ubuntu 20.04 LTS and will be backported to Ubuntu 18.04 LTS to support widespread enterprise adoption."
    - brobinson 6y ago
      Not sure about hardware VPNs, but I've seen people begging for Wireguard support in Private Internet Access for at least a year. I can imagine the ipfire guy getting similar requests a lot.
      - tptacek 6y ago
        "The ipfire guy" is not in the situation described upthread.
        brobinson 6y ago
        Oh, I see. Thanks for clearing that up. I thought the implication above was that he was also selling hardware VPNs. Apologies to the ipfire guy.
thoraway1010 6y ago
I just wish the wireguard folks did IP6v2 :) Kidding (kind of)!
- jabl 6y ago
  I recall skimming some recent(-ish) IPv6 overview RFC which was an update to an older RFC, ("IPv6 architecture", or something like that, maybe?) and IPSec has been demoted from necessary to optional. So it's not entirely impossible IPSec will eventually fade into obscurity.
- MayeulC 6y ago
  I quite like Yggdrasil's [1] approach, and there are other alternatives. Of course, it doesn't fix everything, but with many project working on different aspects of networking, we might get back to an "internet" that's closer to a mesh between non-interoperable networks (GNU net, cjdns, private VPN-backed LANs, zigbee, etc). Because, on your local network, you can run whatever you want (but it better be ipv6-aware software using DNS, it's easier to fool like NAT64 or yggdrasil do). [1]: https://yggdrasil-network.github.io/ https://yggdrasil-network.github.io/
  - thoraway1010 6y ago
    Thanks for this - I'm not an expert at all in the networking space side of things, but even dabbling with ipsec / ipv6 combos made my head spin coming from an ipv4 background. Basically I was left with the idea - how in the world is the gigantic set of interlocking RFCs (at least to me IPv6 seems to involve a lot of complex stuff) the best way to network these days.
brunoqc 6y ago
I can't wait for the tailscale app for Android. If I die from covid before I get it I'll be very upset.
- dfcarney 6y ago
  (Co-founder here). It's coming, I promise. I'm as excited as you are. We wanted to iron out the kinks on mobile (i.e. iOS) before duplicating them on another platform. Thankfully, we're past that point now.
XelNika 6y ago
> This section of the article is confusing at first because it talks about “road warrior” users (who generally have dynamic IP addresses) not being supported by WireGuard. But this is not true; standard WireGuard happily works as long as as least one end (usually the central VPN concentrator) has a static IP address. Maybe I don't understand the issue to be solved (I was unfamiliar with the 'road warrior' term so I looked it up [1]), but I think both Avery Pennarun and Michael Tremer misunderstood what WireGuard is capable of. WireGuard works just fine when the physical network interfaces have dynamic IPs (on both ends even). You can use the basic wg or wg-quick tools to create a VPN server on a server with a dynamic IP and have clients connect from dynamic IPs. However, all the tunnel IPs must be static unlike e.g. OpenVPN where the server gives the client a tunnel IP during authentication. > (for example, so you can get to an office network whose home connection uses dynamic DNS). It’s true that plain WireGuard does not support this configuration out of the box. I have done literally that for over a year now. I cannot think of a way to interpret this that would make Avery's claims true. > Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN. That is not how I interpret what Donenfeld has said [2] about the future of WireGuard. I believe the software will get a v2 without backwards compatibility. However, even that is a non-issue because sysadmins can run both protocols in parallel during the transition. [1] https://en.wikipedia.org/wiki/Road_warrior_%28computing%29 https://en.wikipedia.org/wiki/Road_warrior_%28computing%29 [2] Page 3 of https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf
- CalChris 6y ago
  Yes, it seemed to me that Donenfeld was pretty opinionated about 'updating breaks compatibility'. Donenfeld is the anti-Torvalds: we will break user space. This is the closest quote I could find. If holes are found in the underlying primitives, all endpoints will be required to update. Unlike IP packets, struct message_header doesn't even have a version number. I suppose type could be used for that since it's 32b. An interesting question is how will this play out with Wireguard going into the Linux kernel itself.
nickodell 6y ago
>In contrast, a hypothetical WireGuard protocol v2 can offer just two suites, the old one and the new one, with simple advice: use the new one if you can, and allow the old one for old nodes until they’re upgraded. There’s nothing unusual about this, except you don’t need to be a cryptography expert to configure it. I don't think this is going to be as simple as the author thinks. Look at Git's migration away from SHA1. There was no designed mechanism for switching hash functions, and lots of code assumed 20-byte hashes. Three years after the first SHA1 collision was discovered, Git has not switched to a new hash function. I don't mean to be alarmist - no one has created a practical attack on Git objects, but the time to switch cryptographic primitives is when they start showing weakness, not after they are definitely broken. IPSec has a standard method for supporting multiple cipher suites, and negotiating a common suite. It might be very complicated, but we have no way of comparing it to WireGuard, because WireGuard doesn't implement the same feature.
- apenwarr 6y ago
  Persistent data structures (like git) are way harder to update than non-persistent structures (like ephemeral network packets). Hypothetical WireGuard v2 packets will simply not parse as WireGuard v1 packets; they can't be decrypted as WireGuard v1. And vice versa. It's therefore trivial to have both protocols coexist, even on the same UDP port, without any negotiation whatsoever. You simply need to discard packets that don't decrypt, which is what WireGuard already does. It's dangerous to include a downgrade-capable negotiation in your VPN protocol. I'm glad they left that out of WireGuard.
  - nickodell 6y ago
    >It's therefore trivial to have both protocols coexist, even on the same UDP port, without any negotiation whatsoever. You simply need to discard packets that don't decrypt, which is what WireGuard already does. If both ends will automatically fall back to v1, how do you prevent protocol downgrade attacks? An adversary dropping v2 packets looks exactly like the other end not supporting v2 packets. >It's dangerous to include a downgrade-capable negotiation in your VPN protocol. I agree. It's a hard problem to solve. But it's going to have to be solved eventually.
nikisweeting 6y ago
Finally, I've been waiting for someone to write a proper response debunking that original article. I was surprised when it got as much attention as it did, since it clearly seemed out of date.

174 points by Foxboron 6y ago

Here comes the mandatory, weekly, coincidentally very organic Tailscale post on HN frontpage, just like every other post on their blog (with one exception). https://news.ycombinator.com/item?id=22759882 https://news.ycombinator.com/item?id=22759882 https://news.ycombinator.com/item?id=22652797 https://news.ycombinator.com/item?id=22652797 https://news.ycombinator.com/item?id=22644357 https://news.ycombinator.com/item?id=22644357 https://news.ycombinator.com/item?id=22585782 https://news.ycombinator.com/item?id=22585782 https://news.ycombinator.com/item?id=22571597 https://news.ycombinator.com/item?id=22571597 https://news.ycombinator.com/item?id=22408269 https://news.ycombinator.com/item?id=22408269 https://news.ycombinator.com/item?id=22192588 https://news.ycombinator.com/item?id=22192588 https://news.ycombinator.com/item?id=21708483 https://news.ycombinator.com/item?id=21708483 According to dang who admitted that most early upvotes come from the same users, this is totally natural and organic. I understand that Paul Graham posts are mandatory for some obvious reason to be on the frontpage, but what's the deal with this company?

dang 6y ago
You've been posting these for months. We investigated and found nothing. The last time you did this, I responded in detail: https://news.ycombinator.com/item?id=22761642 https://news.ycombinator.com/item?id=22761642. Unfortunately, the person who has been abusing HN here is you. You've broken the site rules by posting groundless allegations. You've used multiple accounts to do it. You've barraged us with emails using multiple identities. When we've responded with what we found, you've become aggressive. You've even made up false statements about what I've said on the topic, including here. We have no special interest in Tailscale. Our job is to protect HN. As far as I can tell from the data, HN's interest in Tailscale is organic. Presumably that's because the people involved with the company are known to the community from their previous projects and writings. That's this place functioning normally.

brobinson 6y ago

Glad someone did a rebuttal of that article. I came across it a few days ago and was shocked to discover it was by the guy behind ipfire, which I had previously heard good things about.

wmf 6y ago
When somebody absolutely positively cannot give up their hardware VPN box yet gets inundated with "WireGuard or die", that's the kind of bitter defensiveness that results. It's just human nature.
- willis936 6y ago
  Who is giving “WireGuard or die” to people with hardware VPNs right now? It isn’t in any LTS releases right now and won’t be for another year.
  - tuukkah 6y ago
    This was released today: "WireGuard is included in Ubuntu 20.04 LTS and will be backported to Ubuntu 18.04 LTS to support widespread enterprise adoption."
  - brobinson 6y ago
    Not sure about hardware VPNs, but I've seen people begging for Wireguard support in Private Internet Access for at least a year. I can imagine the ipfire guy getting similar requests a lot.
    - tptacek 6y ago
      "The ipfire guy" is not in the situation described upthread.
      - brobinson 6y ago
        Oh, I see. Thanks for clearing that up. I thought the implication above was that he was also selling hardware VPNs. Apologies to the ipfire guy.

thoraway1010 6y ago

I just wish the wireguard folks did IP6v2 :) Kidding (kind of)!

jabl 6y ago
I recall skimming some recent(-ish) IPv6 overview RFC which was an update to an older RFC, ("IPv6 architecture", or something like that, maybe?) and IPSec has been demoted from necessary to optional. So it's not entirely impossible IPSec will eventually fade into obscurity.
MayeulC 6y ago
I quite like Yggdrasil's [1] approach, and there are other alternatives. Of course, it doesn't fix everything, but with many project working on different aspects of networking, we might get back to an "internet" that's closer to a mesh between non-interoperable networks (GNU net, cjdns, private VPN-backed LANs, zigbee, etc). Because, on your local network, you can run whatever you want (but it better be ipv6-aware software using DNS, it's easier to fool like NAT64 or yggdrasil do). [1]: https://yggdrasil-network.github.io/ https://yggdrasil-network.github.io/
- thoraway1010 6y ago
  Thanks for this - I'm not an expert at all in the networking space side of things, but even dabbling with ipsec / ipv6 combos made my head spin coming from an ipv4 background. Basically I was left with the idea - how in the world is the gigantic set of interlocking RFCs (at least to me IPv6 seems to involve a lot of complex stuff) the best way to network these days.

brunoqc 6y ago

I can't wait for the tailscale app for Android. If I die from covid before I get it I'll be very upset.

dfcarney 6y ago
(Co-founder here). It's coming, I promise. I'm as excited as you are. We wanted to iron out the kinks on mobile (i.e. iOS) before duplicating them on another platform. Thankfully, we're past that point now.

XelNika 6y ago

> This section of the article is confusing at first because it talks about “road warrior” users (who generally have dynamic IP addresses) not being supported by WireGuard. But this is not true; standard WireGuard happily works as long as as least one end (usually the central VPN concentrator) has a static IP address. Maybe I don't understand the issue to be solved (I was unfamiliar with the 'road warrior' term so I looked it up [1]), but I think both Avery Pennarun and Michael Tremer misunderstood what WireGuard is capable of. WireGuard works just fine when the physical network interfaces have dynamic IPs (on both ends even). You can use the basic wg or wg-quick tools to create a VPN server on a server with a dynamic IP and have clients connect from dynamic IPs. However, all the tunnel IPs must be static unlike e.g. OpenVPN where the server gives the client a tunnel IP during authentication. > (for example, so you can get to an office network whose home connection uses dynamic DNS). It’s true that plain WireGuard does not support this configuration out of the box. I have done literally that for over a year now. I cannot think of a way to interpret this that would make Avery's claims true. > Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN. That is not how I interpret what Donenfeld has said [2] about the future of WireGuard. I believe the software will get a v2 without backwards compatibility. However, even that is a non-issue because sysadmins can run both protocols in parallel during the transition. [1] https://en.wikipedia.org/wiki/Road_warrior_%28computing%29 https://en.wikipedia.org/wiki/Road_warrior_%28computing%29 [2] Page 3 of https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf

CalChris 6y ago
Yes, it seemed to me that Donenfeld was pretty opinionated about 'updating breaks compatibility'. Donenfeld is the anti-Torvalds: we will break user space. This is the closest quote I could find. If holes are found in the underlying primitives, all endpoints will be required to update. Unlike IP packets, struct message_header doesn't even have a version number. I suppose type could be used for that since it's 32b. An interesting question is how will this play out with Wireguard going into the Linux kernel itself.

nickodell 6y ago

>In contrast, a hypothetical WireGuard protocol v2 can offer just two suites, the old one and the new one, with simple advice: use the new one if you can, and allow the old one for old nodes until they’re upgraded. There’s nothing unusual about this, except you don’t need to be a cryptography expert to configure it. I don't think this is going to be as simple as the author thinks. Look at Git's migration away from SHA1. There was no designed mechanism for switching hash functions, and lots of code assumed 20-byte hashes. Three years after the first SHA1 collision was discovered, Git has not switched to a new hash function. I don't mean to be alarmist - no one has created a practical attack on Git objects, but the time to switch cryptographic primitives is when they start showing weakness, not after they are definitely broken. IPSec has a standard method for supporting multiple cipher suites, and negotiating a common suite. It might be very complicated, but we have no way of comparing it to WireGuard, because WireGuard doesn't implement the same feature.

apenwarr 6y ago
Persistent data structures (like git) are way harder to update than non-persistent structures (like ephemeral network packets). Hypothetical WireGuard v2 packets will simply not parse as WireGuard v1 packets; they can't be decrypted as WireGuard v1. And vice versa. It's therefore trivial to have both protocols coexist, even on the same UDP port, without any negotiation whatsoever. You simply need to discard packets that don't decrypt, which is what WireGuard already does. It's dangerous to include a downgrade-capable negotiation in your VPN protocol. I'm glad they left that out of WireGuard.
- nickodell 6y ago
  >It's therefore trivial to have both protocols coexist, even on the same UDP port, without any negotiation whatsoever. You simply need to discard packets that don't decrypt, which is what WireGuard already does. If both ends will automatically fall back to v1, how do you prevent protocol downgrade attacks? An adversary dropping v2 packets looks exactly like the other end not supporting v2 packets. >It's dangerous to include a downgrade-capable negotiation in your VPN protocol. I agree. It's a hard problem to solve. But it's going to have to be solved eventually.

nikisweeting 6y ago

Finally, I've been waiting for someone to write a proper response debunking that original article. I was surprised when it got as much attention as it did, since it clearly seemed out of date.