WireGuard VPN review: A new type of VPN offers serious advantages | Hacker News Reader

WireGuard VPN review: A new type of VPN offers serious advantages

arstechnica.com

If you aren't using WireGuard yet, do. Setting it up is super easy, I wrote a guide for common setups:

https://www.stavros.io/posts/how-to-configure-wireguard/

This is a great guide. Thanks. I was reading it just yesterday.

If Algo had supported WireGuard at the time you looked into this, would you still have done it yourself?

I'm not sure how Algo does it, but the configuration is easy enough. I wouldn't do it without the post to help me, because it took a long time to figure it out, but copying two files isn't much hassle.

Cool. I'll try it out this week. My current VPN uses shadowsocks tunneled over KCPTUN, but I don't think I've optimised the KCPTUN parameters well enough, as the throughput is similar with and without it. I'm curious to see what throughput I get with WireGuard.

Unfortunately WireGuard is UDP only, so I can't even use it to get out through the university wifi firewall. 80 / 443 on TCP only.

At least OpenVPN, for all the criticism the article throws at it, has the configurability to pass through the various strange firewall rules that exist in the real World. Waiting eight seconds for negotiation isn't a big deal when the new and shiny 'replacement' doesn't have a hope of working.

Oh man! If only there was a way to take UDP packets and tunnel them over TCP! Wait a second!

http://manpages.ubuntu.com/manpages/xenial/man1/udptunnel.1....

Setup Wireguard on your server as though everything were normal. However, on the server, run this command (as a service):

udptunnel -s 443 127.0.0.1/51820

Then on your client run:

udptunnel -c [SERVER-ADDR]/443 127.0.0.1 51818

In the Client's Wireguard Config, where you would normally specify the server's address / port. Instead specify 127.0.0.1 51818. Finished!

Don't forget to open the firewall on the server's port 443!

Setting up udptunnel as a systemd service to auto start / restart only involves writing two short files! Wireguard uses a standard service file as well so you can simply require the udptunnel service as a prerequisite!

Personally, I find this style of combining simple components much more satisfying (and secure!) than the gargantuan complexity of OpenVPN/IPSec! Wireguard's simplicity means it is easy to have a mental model around how it functions and how it can be composed!

Huh. Think I'll package udptunnel for Arch and fix up the ArchWiki entry with this. Super neat.

You doing gods work.

I've not seen/used udptunnel before. Nice. Thanks for the pointer. It looks much simpler than other tricks I've tried to accomplish the same goal.

Obligatory link about tunneling TCP over TCP:

http://sites.inka.de/bigred/devel/tcp-tcp.html

(not that it matters when you're trying to tunnel out of university network, but something to keep in mind, especially on lossy connections)

I wonder whether you could successfully mitigate this a bit by having udptunnel open multiple TCP connections to the destination and sending each tunnelled datagram on the connection with the shortest send queue.

You would get all kinds of interesting packet reordering issues, which can cause performance problems all their own.

I've sometimes contemplated just faking the TCP protocol entirely. Do the TCP handshake, then send "TCP packets" but interpret each payload as a datagram, acknowledge everything up to the latest sequence number regardless of whether any of them were lost and don't bother with any flow control or retransmissions.

It's a terrible hack but it would probably work at least some of the time.

vdm further down thread pointed at a repo which does something like this:

https://github.com/wangyu-/udp2raw-tunnel/blob/master/README...

In theory the re-ordering should only happen in the presence of packetloss, which is exactly what you want. Could be worth an experiment, anyway.

Your suggestion is how some "WAN optimisation" network middleboxes work (transparently terminating the TCP in the middlebox itself). To do that with Wireguard you'd have to implement that in the Linux kernel.

Out of order receives happen. Your method could make things worse.

Since you mentioned security note the security implications towards the end of the page as this is actually pretty insecure without additional components. Also note this results in:

application data in IP+<L4 protocol> in IP+UDP Tunnel (Wireguard) in IP+TCP

So securing the component mess and header bloat is becoming as bad as OpenVPN/IPSec which you abhorred. Still probably faster than OpenVPN though as that implementation is amazingly bad.

I think you've misunderstood. This setup is not insecure.

Wireguard authenticates (or drops) any packets forwarded by udptunnel. Once a packet leaves the Wireguard interface the attacker (or anyone else) can transform it however they like without impacting security properties.

This config does allow the attacker to make a TCP handshake to the server, but the data they send over the TCP wrapped connection could have equally been sent to the UDP port Wireguard is listening on.

Disclaimer: This of course assumes both Wireguard and udptunnel have no remote code exploits or other implementation errors. However, as we discussed, this is a much safer assumption than OpenVPN...

It does have one security implication: Wireguard never responds to an attacker. Your tunnel is responding to attackers, so now they know your box exists and can probe it for problems. Each TCP connection takes up memory. If you limit the TCP connections, they can run a slowloris attack and tie them all up.

So it's not a security hole, but it is slightly less secure.

I was more referring to the DoS attacks on the TCP stack than the spoofing attacks. https://nvd.nist.gov/vuln/detail/CVE-2018-5390 as an example. The attack surface is vastly expanded compared to Wireguard's default attack surface.

Someone benchmark this compared to raw udp, and then to OpenVPN TCP.

How about you do it?

Nice I am going to try this with a spare AWS instance

That’s crappy. You should lobby them to join eduroam which is not completely useless - see p.32 of the service definition for the minimum allowed ports https://www.eduroam.org/wp-content/uploads/2016/05/GN3-12-19...

And as a side benefit you get secure WiFi at many (most in Europe) universities, teaching hospitals, city centers close to a university, etc.

https://github.com/wangyu-/udp2raw-tunnel

This seems more like a problem with your uni's firewall than with any VPN solution. If they're locking things down so hard, why do they allow you to set up an arbitrary VPN just by using TCP and :443?

If OTOH they want to allow you to use a VPN, they should allow at least some UDP traffic. The way God intended BTW because running VPN traffic over TCP usually means running error detection and flow control twice on top of each other.

Sure, some of the value of a VPN is running through misconfigured and outright hostile networks, hence various encapsulation schemes (over SSL, in DNS requests, etc), but only some of the value.

How do you make DNS queries?

Those ancient setups need to die.

As suggested below, internal resolver.

To be honest I'm a bit surprised vy the reactions here. This isn't an unusual configuration, I've worked in two other companies that had the same rules; nothing except web traffic even on the 'public' wifi. The latter permitted any device to connect but had absolutely no exceptions to the firewall rules. The corp nets did have an exception process but only for servers in the DMZ.

Some networks force you to use their resolvers and/or have a whitelist of common public ones.

But running wireguard on port 53 might just work!

UDP is a reasonable default. TCP-inside-TCP, which is what you're going to get with a TCP VPN, is generally terrible.

Generally, TCP-over-TCP is fine. It some edge cases though it is indeed terrible.

That sucks. Have you tried UDP over port 53? Also, I find ocserv/opeconnect much better for passing firewalls as it much more closely resembles HTTPS, I find OpenVPN is too easy to fingerprint. It opportunistically uses UDP if it can, otherwise it uses TCP.

You could tunnel with stunnel, which I think would make it quite difficult to fingerprint and distinguish from an ordinary TLS connection.

Wrap it in stunnel if you can. Basically an https wrapper. Stunnel is increasingly useful for all kinds of VPN especially when you are traveling since more and more places are blocking vpn. Https is almost never blocked. Works pretty much every except China.

What works in China lately?

Buy a China Mobile Hong Kong 4G China data roaming SIM in Hong Kong airport (arrival concourse). $15USD, rechargable - and 4G unfiltered internet in mainland China.

Probably obfs4, as long as it has not been flagged or detected yet.

Tor with bridge (Azure) works, at least for me 2 weeks ago.

Shadowsocks

Have you tried sslh + sshuttle?

Yeah, and this is a pretty common situation on a lot of public networks. The whole reason I set up an OpenVPN (configured over tcp on port 80) was to be able to use irc!

Since net neutrality laws came into place a few years ago, I've been seeing it less and less. A few big ones (like the biggest rail company, NS, which offers free on-board wifi) got into trouble for blocking things like video streaming and it seems others took heed. Now most networks even allow TCP/25, and without any abuse that I've heard of.

The problem isn't that your university blocks everything but 80/443, the problem is that you and everyone else there apparently tolerate it.

Don't do that.

I was going to say that that's illegal but you're probably from the USA, right? I'm not sure what the status there on net neutrality is right now.

Edit: going by downvotes, it still seems to be a sore spot. That answers my question about its current status in the USA I suppose...

You clearly don't know what net neutrality is.

I'm not sure that I don't, I've followed new IT-related laws in the Netherlands closely so I'm pretty sure I know what's included without looking it up. I'm more sceptical of someone who says "you have no idea" without anything to back that statement up. But for other readers, I'll elaborate.

Blocking UDP is not treating all traffic the same. Even if the law would be about treating services equally and not any IP packet equally, then it still has a different impact on services like VoIP (which are often UDP) than it does on other services. Blocking certain types of packets is not compliant with net neutrality -- at least, not in the Netherlands. If there is a different definition whereever you come from, please tell me about it.

Net neutrality is and has always been in any discussion in Switzerland, Germany, Austria, the US and everywhere I have seen else about ISP and ISP abusing their position in the market.

I have never once heard anybody claim that private institutions are not allowed to shape their own network traffic.

Unless you show me Dutch law that clearly spells this out, I will not for a second believe that it is illegal for a university to block certain protocols.

If what you say were true then pretty much every single private organization would be operating illegally, anybody that runs VoIP, blocks UDP or any other way to shape the network.

I have a feeling it's a bit more nuanced than that otherwise you're telling me a University in the Netherlands can't run a firewall on their internet link and they need to have all public addresses to get around the fact that no device dynamically NATs all L4 protocols.

I'd be willing to bet my lunch that there are exceptions for private, government, and educational institutions or that there is an exception related to security services.

> you're telling me a University in the Netherlands can't run a firewall on their internet link

Any blocks should be necessary/essential for network stability or security. If I have evidence that a trojan is using tcp port 1337, and I am not aware of any other application that uses it, then there is no problem blocking it. In practice, of course, malware would be crazy not to use tcp/443 or tcp/80, so blocking ports is rather pointless these days anyway.

As for network stability: reasons like "by blocking VoIP we can sell our services and use that money to make our network more stable" are not good enough, of course. There has to be a concrete reason why {whatever you want to block} will benefit the network.

> and they need to have all public addresses to get around the fact that no device dynamically NATs all L4 protocols.

I guess since there is scarity in v4-addresses, it's not reasonable to use public addresses for each individual, so "blocking" incoming traffic (or rather, it being unrouteable) shouldn't be an issue. It's essential for the network's operation.

Firewalls have stateful inspection and handshake inspection capabilities for known protocols on known ports. They also have URL filtering, IPS, DDoS protection, and threat monitoring. This is the big difference between an organization like a business/university vs an ISP. I wasn't talking simple ACLs, that only requires a basic switch.

Net neutrality is whatever Advance Publications, Facebook, Google and Netflix want it to be.

Where I live, net neutrality is whatever article 7.4a of the Telecommunications Act says...

Having been running WireGuard in my router for a couple of months now I have to say it's just the first ever VPN to offer no bandwidth penalty and a very easy setup. Now I have IPv6 through the VPN, all traffic from the house is routed through anonymous servers and I've had no problems with the connection dropping. Very nice work here.

> I have to say it's just the first ever VPN to offer no bandwidth penalty

By protocol design it incurs a 4%-~50% (1500 byte and 64 byte packets respectively) bandwidth penalty over the internet due to headers. The encryption of the payload is extremely fast though.

Of course I was exaggerating a bit. But...

I've been trying to setup OpenVPN for ages, and it always eats about 60-80% of the bandwidth. No matter what I try with it, I just cannot get the full speed of my internet connection through the protocol. With Wireguard I haven't noticed any difference. fast.com is as fast with or without WireGuard. I have to say it's the first time in my life I see it working this easily.

What router do you have that lets you run wire guard?

OpenWRT has WireGuard support, so also, every router you can put an OpenWRT image on.

EDIT: I'm using it on my Netgear WNDR3800, and my grandmother's Sitecom WLR-4000 (which is a rebranded Sitecom WL-351, which is a rebranded EnGenius ESR9850).

You can run it on Ubiquiti's EdgeRouters: https://community.ubnt.com/t5/EdgeRouter/Release-WireGuard-f...

And if you're feeling like a fun weekend hacking project it's also available on OpenBSD which runs on the EdgeRouter including support for the onboard packet accelerator.

https://marc.info/?l=openbsd-ports&m=152712417729497&w=2

Nothing against vyatta/edgeos but since getting into edge cases requires command line anyway, you can just start there without too much trouble.

You just get to port Go to octeons during that weekend then. But if you do, I will be happy! \o/

To be fair, then your bandwidth penalty just comes from something else.

(I run a large number of ERs, mostly because you can easily run so much other software on the hardware -- but they're not great devices if you need performance or reliability. "You get what you pay for" absolutely applies.)

Omnia Turris runs it fine.

Are there commercial providers?

Yep.

https://mullvad.net/en/

Many servers. Can pay with bitcoin. You only get a randomized account number. /128 subnet for IPv6.

https://www.azirevpn.com/

A bit less servers. No need to give email. /64 subnet for IPv6.

Mullvad also doesn't require an email, and you can mail them cash anonymously.

Yep. And the service with both of these is top notch.

Talked to some of the guys at a conference. They are really nice and they are doing a lot with Wireguard, helping if financially as well.

Yes, see https://mullvad.net/en/guides/category/wireguard/

Is Wireguard stable and ready for general use? The Wireguard devs seem to think it's not:

https://www.wireguard.com/#about-the-project

Work in Progress

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities (which would not be eligible for CVEs, since this is pre-release snapshot software). If you are packaging WireGuard, you must keep up to date with the snapshots.

When it has been reviewed merged into the mainline linux kernel, then it can be considered stable.

AFAIK Jason does use wireguard for himself now, but is cautious to recommend that to everyone.

The last submission to the linux kernel is here: http://lkml.iu.edu/hypermail/linux/kernel/1808.3/00619.html

While merging wireguard should not be a problem, its own crypto library called 'zinc' has bigger open points of discussion.

>AFAIK Jason does use wireguard for himself now, but is cautious to recommend that to everyone.

For me this means he's appropriately cautious for working in security-minded applications like this. A lot of VPN providers would probably release something like an alpha release.

Merging into mainline doesn't mean things are stable. There's a few experimental options available when compiling the kernel.

Btrfs has been in the kernel for years.

I'm not sure if this was meant as a jab or accurate, but btrfs is a good example. The core of it is stable, but there are a few features which are unstable/experimental, yet still included.

> Security Analysis of WireGuard. MIT 6.857 Final Project. Andrew He. Baula Xu. Jerry Wu. Spring 2018

https://courses.csail.mit.edu/6.857/2018/project/He-Xu-Xu-Wi...

> A Cryptographic Analysis of the WireGuard Protocol. Benjamin Dowling, Kenneth G. Paterson

https://eprint.iacr.org/2018/080.pdf

This question comes up in every discussion of WireGuard. Jason's answer is that updating the web page is a low priority for him. You should use WireGuard if you can.

> Jason's answer is that updating the web page is a low priority for him

I really don't understand this. Why not just update the webpage and eliminate having to give the same response every time, since it seems to be asked a lot?

Well, if it's ready, but it hasn't been a long enough time then maybe we avoid rushing everyone to wireguard until it's been tested in the wild more by those who read the mailing lists and etc.

It's easily stable enough for general use. Here's a comment from the developer about the scary web page blurb:

https://news.ycombinator.com/item?id=17092853

I feel like it’s natural for anyone even close to the security industry to be very hesitant to say a product they created is secure or complete. Even Socrates ended with “All I know is that I don’t know”. Which interpreted means: use it.

I'm not sure why you couldn't say those same things about any of the common VPN solutions.

Why can't we have IPSec + IKEv2 everywhere as originally intended as part of IPv6. No "VPN" necessary.

We're not in IPv6 world yet, but even if we were, Amazon AWS EC2 would doubtless continue to make IPSec awkward.

They only route UDP and TCP to your VM, so if you want IPSec, you have to mess about with 'Amazon Virtual Private Cloud'.

That makes snooping much more difficult.

Linus is also a huge fan of wireguard overall: http://lkml.iu.edu/hypermail/linux/kernel/1808.0/02472.html

Praise like this from him is rare.

Linus never was a big fan of serious security matters. He is interested primarily in simple, small code that is simple to maintain, code that doesn't require any serious changes in other parts of the kernel, that's it.

His comment appears in the third paragraph of the article

Does anyone know if any commercial VPN providers implement WireGuard yet on iOS? > "An iOS app is available in the WireGuard repository, but as it isn't in the App Store yet. It's probably not going to do you any good unless you're an iOS developer yourself."

The article references code for iOS apps but also states that "it needs to be baked right into the kernel for that to happen.". Would iOS apps also need the iOS Kernel (say iOS 12.x or iOS 13.x) to include WireGuard to take advantage of some of the speed advantages over OpenVPN?

I don’t think so, although I am hardly an expert. The iOS SDK has the ability for apps to provide custom VPN implementations for use system wide (see: https://developer.apple.com/documentation/networkextension/n... )

I don’t know if WireGuard being UDP causes issues, but I would assume it is possible.

WireGuard even in userspace is generally pretty fast anyway, since it's multi-threaded.

Is there any "easy" algo-like setup? I've checked but all of them still seem to involve a lot of steps. I could do it but I'd prefer if there's some quick start to test it out.

Algo supports it, without being super-obvious about it. When it's done doing its thing, fish out the generated wireguard client config from

algo/configs/your.server.ip/wireguard/uname.conf

Add

    PersistentKeepalive = 25

as the last line (should be in the [Peer] section).

Feed the conf file to your client. That's it.

I've been using WireGuard via algo for a few months and love it. What does PersistentKeepalive do?

Sends a tiny bit of dummy traffic every N seconds, keeps a NAT router from just forgetting about your client's state. I imagine Algo doesn't include that line because the generated config is for Android phones but for a laptop or desktop behind NAT, you pretty much always want it. This is especially true for things like public WiFi where the routers can be particularly keen to forget you.

Edit: There's a blurb about it on the website as well that is a little less handwavey than what I typed:

https://www.wireguard.com/quickstart/#nat-and-firewall-trave...

Please submit an issue and I'll fix it! -AlgoVPN developer

What Algo does now seems technically correct (the best kind of correct!) since it essentially says WG is for Android. I've added the issue though, for when more desktop-y clients are officially supported.

https://github.com/trailofbits/algo/issues/1068

Thanks!

I wrote a guide, you can just copy my configs: https://www.stavros.io/posts/how-to-configure-wireguard/

It's a nice enough guide but its default set up is something 97.30133% (recurring, of course) users aren't trying to do with a VPN - reach a home computer from their server. What most people want is to shovel all their client's traffic through the server. This is also described as a sort of afterthought, but I think for most people, it's the thing they're trying to accomplish when they want to set up a VPN.

Algo already supports it

I wonder how it works in ChromeOS, anyone tried it? I had OpenVPN working for a while, but the debugibility of it was pretty low, it was a pain to set up. I was always turning it on and off, unlike my Linux laptop where it would just always be on and working. That's using the built in OpenVPN, not an android app. I wonder if setting it up in the "ChromeOS centrally managed" mode would help any?

I'm really using my chromebook a lot these days at home, but wish I had a better VPN option for it.

> Waiting for Windows support is going to put WireGuard out of reach for many users for another few months.

Haven't tried it yet but Mullvad.net just released a VPN app for Windows:

https://mullvad.net/en/blog/2018/8/14/official-release-new-m...

That's interesting, it's refreshing to see open source VPN apps (desktop or mobile).

are you sure that uses Wireguard?

Not yet, but it's in the works. There currently isn't a stable userspace implementation of Wireguard that would work on all the major platforms anyway :(

Recently we had to decide what to use and went with IPSec instead of WireGuard. Any reasons to reconsider and switch to WG? Thanks.

Less complex and easier on firewall traversals.

Easier from performance point of view? Thanks.

I think IPSec needs special treatment when it comes to NAT port forwarding. WireGuard claims this is not necessary with wireguard.

If you'd like to run a memory-safe-ish implementation of WireGuard, apparently there is a working Go version: https://www.wireguard.com/xplatform/

Tried it but couldn't make it work.

When someone provides instructions to set up a WireGuard server on my Linux server and a client on my Android, I might just buy into that "easy setup" story.

There's plenty of tutorials, including a couple posted in this thread. It's unfortunate that you had a bad experience setting it up, since it is usually pretty simple. But I think the "easy setup" is relative to the setup for OpenVPN, etc.

I love the Android client. OpenVPN used to consume some 25% of the battery life. With wireguard it's next to nothing and it's very very quick to connect. Great stuff!

Regarding the whole-protocol versions instead of mix and match negotiation: is there a reason that wouldn't have worked for TLS? At least technologically; I'm sure it was a non-starter politically.

I'm just wondering if there are any actual downsides to this scheme. It seems like such an obviously good idea that I'm second-guessing myself.

It would have worked fine for SSL (now TLS). Wireguard has the advantage of being able to learn from decades of experience with real world SSL/TLS vulnerabilities — the advantage of hindsight.

SSL and especially TLS are used in lots of different applications. So either most of them don't get the features they want in this scenario, or they all use mutually incompatible protocols.

The no-negotiation approach also means if things change you can't find out why you can't connect. Maybe you need to upgrade your software? Or downgrade it? Did you change any settings? It's a mystery!

I wonder if protocol agility was pushed through the IETF as part of the NSA’s intentional weakening of crypto protocols.

It was required to comply with US laws against exporting strong cryptography. In order to have a global standard the protocol had to be decoupled from the crypto implementation and clients had to be able to negotiate down to the (broken) crypto approved for export.

https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...

What bothers me in the Article, the official documentation and almost all guides for wireguard is that they ignore ipv6 completely. They either result in a leaking vpn or bad working one where all ipv6 connections fail.

Doesn't it just tunnel everything on one interface? In my tests, using a minimal config, ipv6 is tunneled just fine without extra consideration.

The only thing I have added is a kill switch that blocks internet access if the WG interface goes down.

"SipHash24 for hashtable keys"

Someone can correct me, but I would prefer Tabulation Hashing to SipHash, even though SipHash is by DJB. Tabulation Hashing offers optimal guarantees and performance, and it's much simpler.

Automatic roaming seems to be the killer feature that nobody has noticed - I know IPsec has this to a degree but Wireguard looks like it works much faster.

I don't like that it is running in the kernel. Running in userspace makes everything more secure and I'm fine with little less bandwith.

There's a userspace implementation you can use if you want.

Not doubting you, but ignorant and curious. What’s the security benefit of userspace?

Easier to introspect/update/verify?

If the kernel code is vulnerable then the attacker gets full control over your system. They can also easily hide their presence. If the code is in userspace, the attacker won't even be able to read your files if you run the daemon under a separate user account. They only will be able to mine Bitcoins or use your computer as a proxy for a short time.

You won't get access to kernel memory space (I think).

From a security perspective, what happens if the wireguard key is passed to another user?

How would you implement MFA in a wireguard system?

This is what Jason said the last time it came up on the mailing list[1]:

"I think that given the WireGuard building block, it's certainly possible to build a 2FA framework around it. And I do generally like 2FA and short-lived credentials and such. Probably after getting the implementations buttoned up -- kernel mainline, windows, etc -- I'll turn a bit of attention to expanding tooling and full packages around the simple wg0 interface."

[1]:https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg02...

Is supporting EAP planned? Like EAP-IKEv2, which can use passwords for authentication and session keys, RFC3748 ?

No.

I don't know much about the fundamentals of networking and security, just asking - can a Linux server with WireGuard installed to be able be detected by GFW (the Great FireWall) and thus get the IP address blocked?

On the other hand, I couldn't wait for the Windows client.

In principle, yes.

So the control program is just "wg". We only have one namespace for commands so using a two-letter combination for something as obscure as controlling VPNs is not very clever. Two-letter combinations should be left to user aliases and core things like cp, ls, df.

I sure use "wg" more often than I use "ul", "as", "bc", "eg", "ex", "gc", "id", "ld", "nl", "od", "pr", "sg", "tc" and "ul".

All these courtesy of `ls {,/usr}/{,s}bin/??`. In fact, there are only 44 two-lettered commands on my (Arch Linux) system right now, so this particular realm appears to be very sparsely populated. (Not counting shell builtins though.)

I feel I gotta mention Tinc https://www.tinc-vpn.org The article mentions it's existence but then ignores it...

It is as easy to use as WireGuard and has two advantages over wireguard. 1. It will automatically mess, and find the best path. 2. It has a far wider range of platforms supported than wireguard.

tinc is not a secure choice! Have you seen their documentation?

https://www.tinc-vpn.org/documentation/Security.html#Securit...

The default cipher is from 1993 and its creator recommends everyone updates.

32 bit MACs are hilariously tiny.

Home rolled authentication based around RSA.

Their own documentation even states: ”tinc’s security is not as strong as TLS or IPsec."

DO NOT USE tinc!

New deployments should be with 1.1 using its new protocol.

https://www.tinc-vpn.org/documentation-1.1/Simple-Peer_002dt...

That does look a lot better, however:

a) its not supported by the stable release

b) There are no claims about downgrade resistance. The manual specifies the new transport protocol is used if both clients support it and both have changed their configs to enable experimental mode. Can an attacker still force them to connect with legacy mode?

c) Users have to ensure every single config on every client has the correct setting.

d) It still doesn't have the identity hiding features of Wireguard. (Someone observing your network traffic can see which servers you are talking to from the transmitted signatures)

You can disable legacy support by not generating any RSA keys, or by building with DISABLE_LEGACY.

Huh, interesting... I am definitely going to be doing some reading about this one. I wonder what the logic of the project maintainers, whom seem to maintain it, have in keeping with this method of encryption.

Tinc is really cool. I like that you can give it a partial mesh and it will figure out how to create a full mesh from it. A few years ago I was talking to the author, Guus, about using WireGuard as the underlying backhaul in Tinc while preserving the neat Tinc meshing magic. I've since gotten super busy getting the core WireGuard stuff completed, but at some point I'd really like to circle back to Guus and make something like that happen.

That would be awesome. I think WireGuard + Tinc + userland windows + iOS support would be the ultimate VPN solution. Bringing WireGuard back hail to Tinc would bring that one important step closer.

Tinc is also completely userland (as opposed to implemented in a kernel module), and therefore slow enough to be practically unusable unless you're on a very slow connection.

Compare this to something like IPSec, where the userland is typically only used for the control part; once a connection exists, the packets don't leave the kernel, so no context switch needed.

I dont know about tinc, but we've benchmarked ZeroTier which is user land and gotten results close to IPSec. The tun/tap overhead is low. It might matter if you are pumping serious traffic, like encrypting a data center or leased fiber line.

If tinc is crazy slow I suspect it's an implementation issue.

I'm sure you could make a userland tun/tap decently fast, but Tinc isn't it. Back when I was testing it, it was about 40% slower than IPsec.

Our stats were within 5% of IPSec, so that's definitely an implementation issue.

Please don't recommend this insecure garbage.

4096 bit keys, comparison, aah. Sounds like the crypto stuff is really badly off in this article. Key length alone doesn't practically mean anything. Classic VPN lies and hype.

Did you read the article? The author agrees with you, and talks about why 4096-bit keys are not inherently more secure...

The author seems to misunderstand that the 4096 bit keys are RSA keys, not elliptic curve or symmetric AES keys.

The reason OpenVPN (and almost all VPN solutions) use such ridiculously long keys is that you don't have to brute-force them. An actual cryptographic attack on the algorithms commonly used for VPNs (or for HTTPS connections to websites) looks a lot more like a dictionary attack than a brute-force attack; you can discount great swathes of the problem space without having to actually try them.

That explanation seems fine to me. It's not an explanation of the underlying math but it doesn't need to be.

12 cheeseburgers are more than 1, but pretty useless to me because 1 is really all I can use.

If current openvpn or IPSEC isn’t being cracked, there is only more energy wasted in going to 4096bit keys.

Edit: lol downvotes... ok, cool. Tell me who is breaking 2048bit diffiehellman exchange to 256bit AES in CBC mode. I’ll wait right here.

You are probably getting downvoted because the article points out exactly that. The author was erroneously thinking that a big key is necessary - and wireguard doesn't provide one. Which made him discover that fallacy.

Except cheeseburgers rot, but crypto doesn’t. 4096 keys might be useful twenty years in the future.

Reply on news.ycombinator.com