Jump to content
Not connected, Your IP: 3.228.21.204
airdev

Is AirVPN's fork of OpenVPN safe to use?

Recommended Posts

This may seem like a clickbait-y title, but it's a genuine question and concern. Reading a hackernews post the commenter said:

> All of the changes are by a single user without any clear indication that they've been reviewed by someone qualified to do cryptography.

This fork, without any formal verification, or any ack's/signed-off-by, with commits done by a single user account with no traceable history (this is the github page of the fork's dev).

This fork also makes AirVPN "unique" in the sense that their fork is only being used by AirVPN, from a fingerprinting perspective, that makes AirVPN a "unique" provider, as only their software will provide support for "ChaCha20-Poly1305".

I feel it would be safer if AirVPN allowed users to choose directly the fork of OpenVPN to use, in a straight-forward easy to undertstand way (Eddie allows you to provide a custom .exe). This could be a GUI or CLI option to pick "AirVPN" or "OpenVPN direct".

This new fork should for sure be part of users' threat models, and you are placing a huge amount of trust the code promindsd writes is safe, because even though it's open source doesn't ensure the right people are looking at the code and verifying and vouching for it.

Personally, I'd like a human being whose name is known to vouch for this fork and a firm to analyze the changes to assure the community all is well. Many of us won't understand the code itself

Share this post


Link to post

If somebody isn't knowledgeable enough to examine the code for themselves (to see if it's OK) then they aren't knowledgeable enough to write about how it's not a good idea to use.

Share this post


Link to post

In fairness, it is reasonable for anyone to call into question new code that has not yet seen much testing.  However,
 

3 hours ago, airdev said:

This fork, without any formal verification, or any ack's/signed-off-by, with commits done by a single user account with no traceable history


Doing "formal verification" now would be useless and wasteful — I'm assuming this code will see many changes in the months ahead.  Besides, the client and OpenVPN3 fork were only officially released a couple weeks ago!  How much faster should everyone work just because a few cynical posters on HN aggressively posture over matters they didn't even investigate to impress friends and employers?
And as the user of a service purpose-built to enable increased privacy/anonymity on the internet, why does "no traceable history" bother you?
 
3 hours ago, airdev said:

I feel it would be safer if AirVPN allowed users to choose directly the fork of OpenVPN to use, in a straight-forward easy to undertstand way


What good would this serve?  The original OpenVPN3 codebase hasn't seen anything approaching "formal verification" either.  It's also widely regarded (not just by Air Staff) as being buggy and incomplete, and hasn't seen much in the way of serious review either.
If you are not comfortable running custom code written by AirVPN then stick with tried & true OpenVPN2.

Share this post


Link to post
22 minutes ago, hawkflights said:

In fairness, it is reasonable for anyone to call into question new code that has not yet seen much testing.  However,
 


Doing "formal verification" now would be useless and wasteful — I'm assuming this code will see many changes in the months ahead.  Besides, the client and OpenVPN3 fork were only officially released a couple weeks ago!  How much faster should everyone work just because a few cynical posters on HN aggressively posture over matters they didn't even investigate to impress friends and employers?
And as the user of a service purpose-built to enable increased privacy/anonymity on the internet, why does "no traceable history" bother you?
 
What good would this serve?  The original OpenVPN3 codebase hasn't seen anything approaching "formal verification" either.  It's also widely regarded (not just by Air Staff) as being buggy and incomplete, and hasn't seen much in the way of serious review either.
If you are not comfortable running custom code written by AirVPN then stick with tried & true OpenVPN2.

Hi.

AirVPN started work on this 6 months ago now, their announcement can be found here, it was used in Android less than a week later. That's a pretty quick time to go from a new fork to release then production. Android has no capability to use Eddie for Android without their fork. According to your logic there is never really a good time to do verification because code is always changing - true, but that shouldn't be a reason why not to reassure a security focused community.

>
why does "no traceable history" bother you?

I can agree making yourself known publicly might put a target on your back - Staff suggested this in their PR for their changes to be upstreamed. This is less important than the validity of the code being added.

> as being buggy and incomplete

By extension ANY OpenVPN fork is also "buggy and incomplete", that's the nature of software development and extensive codebases. However, OpenVPN I suspect has my eyes watching each and every commit, with ack's and signed-off-by's and mailing list discussions. AirVPN's repo likely has little attention from the security community, theirs is just 1 fork of hundreds.

> If you are not comfortable running custom code written by AirVPN then stick with tried & true OpenVPN2.

That's not so easy. Android and now Hummingbird use Air's own fork by default, and changing this should be a 1 click/tap/CLI-option process.

It's concerning this code has been written, deployed and now utilized by many thousands of customers, perhaps without them even knowing, and we have to trust this code is not malicious in any way.

And my final question is this: Why? We have Wireguard coming to the mainline kernel soon. There's going to be some competition for VPN providers to support this new protocol and a sense of expectation - the talents of promindsd could be better utilized on making WG "AirVPN" ready - Staff had concerns about that in the past, hopefully soon we can forget OpenVPN altogether.

 

 

Share this post


Link to post

Has AirVPN offered patches to the OpenVPN project? A few years ago I formed the opinion that OpenVPN are prone to rejecting very reasonable extensions that I would have liked to see in the mainline. So I suspect that they would not be very welcoming. Even if AirVPN made it clear that they would be around to keep their stuff working as each release rolls out. But perhaps AirVPN should make a clear effort to contribute to the maniline? Or has AirVPN already tried?

 

Share this post


Link to post
24 minutes ago, airdev said:
...
It's concerning this code has been written, deployed and now utilized by many thousands of customers, perhaps without them even knowing, and we have to trust this code is not malicious in any way.
...
How many AirVPN users would know if the OpenVPN client that Eddie wraps was altered? They are already trusting AirVPN.

I once wrote a patch for the OpenVPN client that extended NAT code already in OpenVPN so that the perceived local VPN address would appear to be the same no matter what server you connected too. I mentioned this in a post here, but no reply from AirVPN. I never tried to offer it to OpenVPN because, as I said above, I had seen other very nice extensions/patches rejected by them. And, to be honest, I did not want to commit to maintaining my bit of code indefinitely.

If AirVPN is now willing to ship a modified client, there may be other extensions that may be helpful?

 

Share this post


Link to post
@airdev

Hello!

Why is a cryptographic "verification" required on OpenVPN 3 library? mbedTLS and OpenSSL libraries are there to play their role. We have not implemented proprietary ciphers or proprietary algorithms to mimic a cipher which would need, indeed, a thorough review.

If you need audits on CHACHA20 consult the proper literature. If you need audits on CHACHA20 implementation in mbedTLS and OpenSSL, consult the respective library audits.

OpenVPN 3 AirVPN included with Hummingbird is linked against mbedTLS 2.16.3 but you can build it and link it against OpenSSL if you prefer so. Why did nobody ask for audits about CHACHA20 implementation in OpenSSL, as OpenVPN 2.5 has been using it since almost a year and by default it is linked against OpenSSL?

AirVPN servers providing CHACHA20 run OpenVPN 2.5. If OpenVPN 3 AirVPN library fork were either unreliable or incomplete it would simply not work with OpenVPN 2.5. But, surprise surprise, it works great. Last but not least, audit yourself. Build it by yourself and monitor everything. nmap is your friend. Wireshark is too.
 
Quote

AirVPN started work on this 6 months ago now, their announcement can be found here, it was used in Android less than a week later.


Let's fix some lies and misleading claims.

First, OpenVPN 3 linked against updated mbedTLS and OpenSSL libraries went under testing with AirVPN's Eddie Android edition in spring 2018.

Second, we forked OpenVPN 3 only after OpenVPN 3 main branch maintainer refused our pull requests. When we pulled a commit request we had already tested extensively the content of the commits. Verify yourself that we forked only after the pull request was refused and note WHY it was refused. Of course, on the basis of the refusal, we did not waste time with them anymore to pull more requests while we fixed more and more bugs and implemented new features.

Specifically, CHACHA20 implementation was completed in April 2019 and tested for 3 months before we committed a pull request for it. Thus, when it was integrated into Eddie Android edition, it had been thoroughly tested internally, and then it went into public beta testing, exactly like we routinely do and like the best practices recommend. The public beta testing ended successfully at the end of July 2019.

Third, CHACHA20-POLY1305 have both been under heavy scrutiny since 2008 or so.

Fourth, mbedTLS and OpenSSL are also audited, and anyway what other library would you suggest to link OpenVPN 3 AirVPN against?

 
Quote


I feel it would be safer if AirVPN allowed users to choose directly the fork of OpenVPN to use, in a straight-forward easy to undertstand way (Eddie allows you to provide a custom .exe). This could be a GUI or CLI option to pick "AirVPN" or "OpenVPN direct".


No OpenVPN 3 fork supports CHACHA20 as far as we know and OpenVPN 3 main branch does not even run correctly in Linux. Again, build it and see how miserably it fails. Also, OpenVPN 3 is a library, OpenVPN 2 is not.

If you want CHACHA20 without OpenVPN AirVPN, you can run OpenVPN 2.5 beta, and renounce to have a C++ library. Or simply use the OpenVPN 3 library main branch and renounce to everything (it will not even run). You will have then the marvelous joy to (not) run the software of the "highest standards" OpenVPN development team, which does not even know that in C you need to initialize data structures. You have no idea how many crashes OpenVPN causes because of that endemic error spread throughout the whole source code.

OpenVPN 3 team was unable to implement CHACHA20 in Data Channel after many years of development. They did not resolve 10 years old reported bugs. They systematically ignore / forget to initialize data structures. They use "goto" in C. They still have a non-working version for Linux.  We can't waste time with them anymore in commits (which have been all refused anyway) and/or bug fixing. we must fix and implement ourselves, but we'll do our best to keep our fork aligned with (and of course ahead) the main branch within the possible range, see also the loyal sync work with the master performed by fork maintainer.

Kind regards
 

Share this post


Link to post

@NaDre

Quote


Has AirVPN offered patches to the OpenVPN project? A few years ago I formed the opinion that OpenVPN are prone to rejecting very reasonable extensions that I would have liked to see in the mainline. So I suspect that they would not be very welcoming. Even if AirVPN made it clear that they would be around to keep their stuff working as each release rolls out. But perhaps AirVPN should make a clear effort to contribute to the maniline? Or has AirVPN already tried?



Hello!

Of course we did. AirVPN forked OpenVPN 3 library only after an OpenVPN 3 maintainer kept refusing AirVPN high quality pull request with trivial excuses and only after a long debate and a dozen modifications to meet the absurd maintainer requirements.

https://github.com/OpenVPN/openvpn3/pull/78

When the maintainer kept making requests one after the other, we noticed that he took care to make a new request only after each modification/refusal cycle: he never asked for all modifications at once. The maintainer did not even ever enter into technical issues of the code.

Since we needed a working Linux version, since we had detected and fixed several bugs, since we had a working version and the main branch still now does not work, we forked, we had no other choice and we really could not afford to waste more time.

If OpenVPN maintainers are happy to waste such a valuable work, so be it, it does not make any difference for us, our code remains GPL'd and available to the world community in spite of any OpenVPN maintainer obstructionism.

Kind regards

Share this post


Link to post
1 hour ago, NaDre said:

If AirVPN is now willing to ship a modified client, there may be other extensions that may be helpful?
 

Hello!

Yes and thank you! We are definitely interested in any extension pertaining to OpenVPN 3 AirVPN library.

About OpenVPN 2, no fork is currently planned. Maybe at the time you got no reply from us because we considered our involvement in OpenVPN development disproportionate to our resources.

Kind regards






 

Share this post


Link to post
Quote

This fork also makes AirVPN "unique" in the sense that their fork is only being used by AirVPN, from a fingerprinting perspective, that makes AirVPN a "unique" provider, as only their software will provide support for "ChaCha20-Poly1305".


Hello!

It sounds totally false, feel free to elaborate.

First of all, Hummingbird and Eddie Android edition can be used with any OpenVPN based provider.

As far as it pertains to the handshake, it's Irrelevant because OpenVPN 3 AirVPN supports tls-crypt which encrypts the whole Control Channel. You just need to avoid obsolete providers which still rely on TLS Auth only.

In other words, not only your ISP or any other man in the middle can NOT understand, via DPI, that you are using a specific OpenVPN version, but they can't even understand that you're using OpenVPN at all.

Only by knowing that a certain IP address belongs to a certain VPN provider that offers a certain VPN protocol on certain ports, then they can infer (and not see or prove) that you are using that protocol, anyway not a specific OpenVPN version. It's a totally different point which applies to any service and protocol.

Finally, about encryption, in general a man in the middle with DPI can understand whether a packet payload is encrypted or not, and that's quite simple, but can't determine the bulk encryption algorithm used to encrypt (it is computationally infeasible).

Kind regards
 

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...