Hacker News Reader

Comment by saurik | Hacker News Reader

> Based on OpenVPN 3 library fork by AirVPN with tons of critical bug fixes from the main branch, new ciphers support and never seen before features

Why are these changes not being contributed upstream? It does not inspire my trust to hear these people are making "critical bug fixes" and then hoarding them without explanation. Did OpenVPN3 refuse the updates, or are otherwise dragging their feet? Or, more likely, did AirVPN decide it was more interesting/important to use these fixes as a competitive advantage / differentiator for their fork, to get people to use their client or even leave upstream?

View on HN

> Why are these changes not being contributed upstream?

Perhaps more importantly, what are these supposedly "critical bug fixes"? How do you make a claim like that without clearly documenting it? Are there security impacts? CVEs?

Edit: if you click through to the actual library page[1], it makes no claims that I can find about "tons of critical bug fixes". I'm beginning to suspect that may be some extremely misleading marketing speak that made it into the README.

Edit: looking through the list of changes[2] does not inspire a lot of confidence in their fork.

[1] https://github.com/AirVPN/openvpn3-airvpn

[2] https://github.com/OpenVPN/openvpn3/compare/master...AirVPN:...

> does not inspire a lot of confidence in their fork

Just out of interest, what reasons do you have for this?

Much of the code seems... incomplete? I don't want to sound too harsh, but what scares me looking glancing at the changes, are the functions `set_ncp_disable` and `set_ncp_enabled`.

Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?

> Much of the code seems... incomplete?

Pretty much this exactly. There's not a lot here, but what is there leaves you kind of confused about what the point is.

I'm not a cryptographer and can't vouch one way or another for the safety of their fork, but a lot of the changes are just stuff like moving whitespace around, and the stuff that isn't pointless sometimes involves changes to important cryptography functions without clear explanations or justifications given in the commit messages. All of the changes are by a single user without any clear indication that they've been reviewed by someone qualified to do cryptography.

And above all there's no obvious reason this fork needs to exist. There's no evidence that it's fixing any "critical bugs" that the OpenVPN project is ignoring, and if the changes are worthwhile they should just be upstreamed. If you're going to pursue something as major as forking OpenVPN, it's really on you to provide some evidence that people should trust your work.

> Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?

For sure, but maybe they should put more effort into getting Wireguard support for their servers instead?

>Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?

What's the advantage of those new ciphers? AFAIK they have better performance than AES on hardware without AES acceleration, but most consumer devices already have it.

Most (all nowadays?) Android tablets and smart phones are based on ARM processors that do not support AES-NI. Even a lot of consumers' routers, which can run OpenVPN, do not support AES-NI.

Raspberry Pi, nVidia Shield, Amazon FireStick are additional examples that come to mind, not to mention many other embedded devices, mediaplayers, Android based TVs...

I have verified impressive improvement (up to 45%) in throughput with CHACHA20 vs. AES-256 in several ARM based devices running either Android or Linux ARM (connecting to the same AirVPN server with same router, same ISP and same application based for Android or Linux ARM on their forked library).

About desktop computers, things might change with AVX-512 wider adoption: it remains to be seen whether AES-NI can perform better with AES-256-GCM than AVX-512 supporting processors can do with CHACHA20. I don't have the option to test that, anybody did?

-- Sasha

Upstream isn't responsive. I have had a bug open with them about broken TAP mode routing for years, with patch, and they've ignored it.

After seeing the codebase, I'm a lot warier of using OpenVPN. It's quite a mess. I'm personally looking forward to WireGuard becoming the standard, but I'm glad to see an OpenVPN fork. These things, even if they don't replace upstream, tend to motivate them to stop dragging their feet.

WireGuard will completely replace OpenVPN with time.

Like IPv6 specified in the early 90s fully replaces Ipv4 with time.

Like reiserfs has become the standard Linux file system. Like btrfs is becoming the standard Linux file system (Redhat has announce to discontinue support)

Predictions are difficult, especially when they cover future developments...

Not really for the type of VPN AirVPN provides. Wireguard (still) has many issues in that area, some of them foundational.

Unsure what the downvotes are for.

Wireguard is not designed to provide any obfuscation. It has very clear fingerprints. This is by design. Jason is very clear that Wireguard does not consider obfuscating its packets to be in scope for the project.

AirVPN (I believe) attempts to provide a service that also features an obfuscated / hidden VPN.

This does not mean that Wireguard cannot become the underlay used by VPN providers like AirVPN. Just that they'll need an obfuscation overlay as well.

By "obfuscation" do you mean a way to disguise packets sent as some other protocol? What methods does OpenVPN provide for this?

I use wireguard with Mullvad since it launched without issues. They even have it in the official client. I talked to them about the article that one VPN provider wrote about it not being scalable and not privacy preserving and their response was that it was mostly FUD. I believe one of their technicians wrote a blog about it, but now I can't find it.

Not just you. Linus Torvalds [1] has said that Wireguard's code is a "work of art" when compared with the "horrors" that are OpenVPN and IPSec.

1: https://www.phoronix.com/scan.php?page=news_item&px=Linus-Li...

Nice misquote.

Full quote is: "Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art."

Source: the given link.

I'm staring at both lines and I can't tell what you think is a misquote.

Uh...the parts he quoted are word for word...

Unfortunately it is blocked in mainland China where it is needed.

As a paid customer of OpenVPN I have to admit I find their attitude over certain matters incredibly frustrating.

Their continued lack of interest in IPv6 is a prime specimen. We're now in 2020, IPv4 depletion is no longer a distant thought, and yet OpenVPN still don't have full support for IPv6.

The lack of support for modern algos is also frustrating, although not exactly a deal breaker.

That said, to give them their due, when a CVE worthy issue arises, they are quick to react and issue a patch (or at least no slower than your average).

As for WireGuard, yes, I'm looking forward to it. But let's face the truth. The WireGuard homepage makes it quite clear in no uncertain terms that WireGuard is still a work in progress. Until such time as its had a full suite of codebase reviews, including multiple independent security audits, I refuse to touch it for production. Maybe in 12–24 months things might have changed at WireGuard to an extend that makes it more worthy for consideration.

So at the moment OpenVPN is the best we've got as an alternative to IPSec (which is quite frankly a pain to deal with, especially in NAT environments and so unsuitable for road warriors).

> Until such time as its had a full suite of codebase reviews, including multiple independent security audits, I refuse to touch it for production.

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

https://www.wireguard.com/papers/wireguard-formal-verificati...

https://www.wireguard.com/papers/dowling-paterson-computatio...

https://www.wireguard.com/papers/lipp-computational-2018.pdf

https://www.wireguard.com/papers/kobeissi-bhargavan-noise-ex...

Additionally: https://lists.zx2c4.com/pipermail/wireguard/2019-December/00...

If you use Linux 5.6 when it comes out, you have WireGuard available.

The code that's still under "heavy" development? Mostly the clients for other platforms (i.e. Windows).

> Or, more likely, did AirVPN decide it was more interesting/important to use these fixes as a competitive advantage / differentiator for their fork ... ?

You mean these fixes that are available in this repo that are available to absolutely anyone?

The changes have been committed as far as I can see and refused with absurd explanation IMHO, but check yourself, it's only my opinion.

What I know for sure, because it's public, is that AirVPN forked only after a long (harsh?) public debate on the commits with the main branch maintainer.

I can see bug fixes summarized in the changelog, look at "Changelog 3.3.2 AirVPN - Release date: 10 October 2019". Then look at the fixes in the code: the AirVPN developers are indeed right as far as I can see, without those fixes the library could have never worked (and the main branch still does not work!) in Linux.

I wonder whether AirVPN would have forked were those commits accepted. Surely they forked only after some time the commits were there, available, as a precious gift IMHO, but still refused without any serious analysis.

The code’s been released under the GPL, so seems unlikely to be an issue of hoarding.

Look: I work on a lot of open source projects; I assert a bunch of undocumented changes without any attempt at organizing them, pushed to a fork on GitHub is still close enough to "hoarding".

I don't agree, but I don't want to act as an outstanding coder. I don't even want to defend AirVPN developers because their software "Eddie" for Linux is ugly, IMHO, and I say it as an AirVPN customer too. But hey I hate Mono. :)

But the OpenVPN 3 fork and Hummingbird too appear to me as good, very good. The fork is well organized, the new parts are quite elegantly coded at least to me, very readable and well commented, and it's kept ahead in alignment with the main branch. Some time ago I also followed AirVPN commits to the main branch and after I took my time to watch the code I was astonished that they were rejected with some arguments that, I think, are either pretentious or wrong, but that's an opinion of mine, the facts can be seen by anyone looking at the code and some smart solutions/implementations I find delicious such as pointers to methods to optimize and save time in packets cipher dependent decisions. I wonder... if the initial commits to the main branch were not rejected, would AirVPN have forked? They forked only after a long debate... I don't know but...

-- Sasha

Reply on news.ycombinator.com