Hummingbird – AirVPN's free and open source OpenVPN 3 client
gitlab.com
gitlab.com
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?
You mean these fixes that are available in this repo that are available to absolutely anyone?
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
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:...
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?
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?
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.
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
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.
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...
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.
1: https://www.phoronix.com/scan.php?page=news_item&px=Linus-Li...
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.
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).
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).
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.
Edit: It appears to be here: https://github.com/AirVPN/openvpn3-airvpn
OpenVPN is a mess, both in code and configuration, getting it to work as you want can be more difficult than editing Xorg.conf.
Wireguard is very very easy to setup (simple enough to fit the entire configuration plus encryption keys into an QR code you can scan with the Android App).
Now opentext host explorer
https://www.opentext.com/products-and-solutions/products/spe...
For example as of today Wireguard only works with static ip addresses. Using the official client it is not possible to assign IP (or pass DNS information) through a DHCP.