Staff

Hello! On server side, we use OpenVPN 2.5 to support ChaCha20 on the Data Channel, so any server with OpenVPN 2.5 will be marked as "Experimental", to make clear that the OpenVPN running in it is a beta version. As soon as OpenVPN 2.5 stable is released, all the servers will be upgraded to support ChaCha20 on the Data Channel without the "Experimental" warning. Our next, imminent step is releasing Eddie Android edition with OpenVPN 3 supporting ChaCha20-Poly1305 to allow immediate testing from those devices based on Android that need ChaCha20 most, for performance and load reasons (such as any Android tablet, smart phone, Amazon Fire TV and any other Android based mediacenter using a CPU that does not support AES-NI). Kind regards

Hello! In addition to what HannaForest wrote, use end-to-end encryption in any case. Kind regards

@prebrov Please see also here to avoid conflicts: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! We see now that the web site you mention also blocks some Tor exit-nodes we tested. This fact alone puts an end to your insinuations: go trolling somewhere else. Kind regards

A user can be sure that we do not infringe end-to-end connectivity principle and draw his/her own conclusions. It makes a world of difference and raises various questions, for example why does a service want to know your real IP address? Kind regards

Hello! The final web server and/or firewall on the final service machine blocking our VPN servers exit-IP addresses on ports 80 and 443 explains your observations. Kind regards

Hello! We do not block any outbound port except 25. We are forced to do it to mitigate mail spamming. Outbound ports 80 and 443, as well as any other port except 25, are not blocked for any destination. Kind regards

Hello! We are very glad to inform you that our OpenVPN 3 development is progressing swiftly. Today we implemented directive ncp-disable which was still unsupported in OpenVPN 3. https://github.com/AirVPN/openvpn3 The directive is instrumental to allow clients Data Channel cipher free selection between those available on server, when ncp-ciphers is declared on server side, and keep at the same time total backward compatibility. Since when we implemented ChaCha20-Poly1305 https://airvpn.org/forums/topic/43850-openvpn-3-development/ on OpenVPN 3 Data Channel, "ncp-disable" has become a priority to provide servers and clients with maximum flexibility. We can therefore leave total freedom to clients to pick between AES-GCM, AES-CBC and ChaCha20 while preserving full backward compatibility. Clients with AES-NI supporting processors will prefer AES, while clients running on CPUs without AES-NI, for example most ARM CPUs, will of course tend to prefer ChaCha20. We are working hard to bring you first and foremost a new Eddie Android edition beta version to let you test ChaCha20-Poly1305 on your Android devices as soon as possible. All internal tests both with ChaCha20 and ncp-disable have been fully successful so far. Fingers crossed, maybe you will see a beta release as early as next week. https://github.com/AirVPN/openvpn3 Changelog 3.3 AirVPN - Release date: 13 July 2019 by ProMIND - [ProMIND] [2019/06/02] Forked master openvpn3 repository 3.2 (qa:d87f5bbc04) - [ProMIND] [2019/06/06] Implemented CHACHA20-POLY1305 cipher for both control and data channels - [ProMIND] {2019/07/10] Implemented ncp-disable profile option Kind regards and datalove AirVPN Staff

Nonsense. The tags were meant to make the review easier and in the subsequent commit they were removed as required. Kind regards

Hello! The problem doesn't occur anymore, but if you still experience the issue, probably Eddie won't open again for a corrupt configuration file. If you use Windows version, download and launch this hotfix . Otherwise, please delete default.xml file (on Linux and Mac it's located in ~/.airvpn/default.xml). At the next run, Eddie will re-create a configuration file with default settings. You will need to enter again your AirVPN credentials.  Kind regards

Yes, we're very glad to confirm that the implementation of ChaCha20-Poly1305 on OpenVPN 3 Data Channel is complete and fully working according to our tests, which have been quite thorough. Schwabe's objections are questionable and never enter into the real argument: look at the previous source code of OpenVPN 3 and the new code by ProMIND. You will see all you need to know. Of course our OpenVPN 3 source code will remain available to the community and we want to underline that the style is compliant to the most up to date Knuth's guidelines on the Art of computer programming, while OpenVPN 3 source code is not. We have doubts to comply to Schwabe's requirements and we need to consider the matter carefully: if higher standards are deemed as a problem, then the real problem lies probably in the low standards, not in the higher ones. We now need an additional commit to OpenVPN 3 (almost ready to be published, already tested successfully) and then we will start to develop and release all the software according to the plans we have published. We are talking about days, stay tuned! Kind regards

Hello! The problem doesnn't occur anymore, but if you still experience the issue, probably Eddie won't open again for a corrupt configuration file. If you use Windows version, download and launch this hotfix . Otherwise, please delete default.xml file (on Linux and Mac it's located in ~/.airvpn/default.xml). At the next run, Eddie will re-create a configuration file with default settings. You will need to enter again your AirVPN credentials. Kind regards

Hello! We deeply apologize for the problem that was not caused by Eddie, but by our bootstrap servers. The problem has been resolved. Kind regards

Hello, since 2017 we've been contributing to run about 5-7% of all the worldwide Tor traffic through exit-nodes maintained by Quintex Alliance, please check our mission page. Kind regards

Updated. Please see https://gitlab.com/AirVPN/EddieAndroid/ and feel free to contact us if you have problems to build it. Kind regards

@air521745 We're sorry, the plan to make it available on F-Droid has been dropped. Kind regards

@💩💩💩 Thank you for your feedback! We will consider seriously your suggestions. About point 2, however, that would not be a master password, but something mainly useless. Maybe an option that could meet your needs is simply disabling the Master Password, but that affects security just like your proposal. Letting the user to opt-out from the MP seems the only reasonable way (i.e. the user deliberately and freely renounces to a security feature). About point 7: yes, the app is authorized by Android system. Remember that the Android system option you mention is not strictly meant to prevent any POSSIBLE leak outside a VPN tunnel, but to mitigate them by restricting comms to registered apps only. Also, your ISP sees the IP addresses your system contacts to connect to a VPN, over TLS or not, with Eddie or not. By the way, we don't think that Eddie pings at any time ipleak.net (we will check with ProMind) and when the network is in lock state (by Eddie) the app can't access anything, including ipleak.net. Remember in any case that ipleak.net is controlled by airvpn.org. Connection to it is very important to let the app understand what the best server to connect to can potentially be, as we can't use "ping" in any way to determine round trip times. That's a great feedback, thank you! Kind regards

Hello! On April 2018 we made an important step forward: we began to accept Bitcoin directly, through no intermediaries at all. Today, we're very glad to announce that we are able to accept directly more cryptocurrencies. In alphabetical order: Bitcoin Bitcoin Cash Dash Dogecoin Ethereum Ethereum Classic Litecoin Any intermediary acting as a payment processor is no more required. As we wrote in 2018, we stll feel it as an additional, important step forward in privacy protection. Moreover, cutting out any intermediary is very coherent with cryptocurrencies spirit and unleashes their potential. Kind regards and datalove AirVPN Staff

Hello! We're glad to inform you that we have released Eddie Android edition 2.3. Eddie Android Edition 2.3 is available on the Google Play Store as well as Amazon Appstore. https://play.google.com/store/apps/details?id=org.airvpn.eddie https://www.amazon.com/Eddie-AirVPN-official-OpenVPN-GUI/dp/B07KTD6DH9  You can also download Eddie Android 2.3 apk directly from our repository: https://eddie.website/repository/eddie/android/2.3/org.airvpn.eddie.apk Available languages: Chinese (simplified), Chinese (traditional), Danish, Dutch, English, French, German, Italian, Portuguese, Spanish, Russian, Turkish. Source is code available on GitLab: https://gitlab.com/AirVPN/EddieAndroid/ Eddie for Android is free and open source software released under GPLv3. We invite you to check from independent 3rd parties the lack of trackers code signatures, for example here: https://reports.exodus-privacy.eu.org/en/reports/search/org.airvpn.eddie New in version 2.3: Disabled data backup on uninstall Server statistics shown in Favorite/Forbidden/Countries & Servers groups Logout drops user credentials Native library updated to the latest openvpn3, lz4, mbedtls and asio commits Minor bug fixes See changelog at the end of this post for a complete list  Main features: Free and open source OpenVPN GUI based on OpenVPN 3 The only Android application officially developed by AirVPN Robust, best effort prevention of traffic leaks outside the VPN tunnel Battery-conscious application Low RAM footprint Ergonomic and friendly interface Ability to start and connect the application at device boot Option to define which apps must have traffic inside or outside the VPN tunnel through white and black list Localization in simplified and traditional Chinese, Danish, English, French, German, Italian, Portuguese, Russian, Spanish, Turkish Full integration with AirVPN Enhanced security thanks to locally stored encrypted data through master password Quick one-tap connection and smart, fully automated server selection Smart server selection with custom settings Manual server selection Smart attempts to bypass OpenVPN blocks featuring protocol and server fail-over Full Android TV compatibility including D-Pad support. Mouse emulation is not required. Enhancements aimed to increase accessibility and comfort to visually impaired persons AirVPN servers sorting options Customizable "Favorite" and "Forbidden" servers and countries OpenVPN mimetype support to import profiles from external applications Multiple OpenVPN profile support. The app now imports and manages multiple OpenVPN profiles Support for custom bootstrap servers Support for favorite and forbidden countries AirVPN broadcast messages support User's subscription expiration date is shown in login/connection information The app is aware of concurrent VPN use. In case another app is granted VPN access, Eddie acts accordingly and releases VPN resources Optional local networks access. In such case, local network devices are exempted from the VPN and can be accessed within the local devices Localization override. User can choose the default language and localization from one of the available ones Favorite and forbidden lists can be emptied with a single tap VPN Lock can now be disabled or enabled from settings VPN reconnection in case of unexpected OpenVPN disconnection. (It requires VPN Lock to be disabled) User can generate an OpenVPN profile for any AirVPN server or country and save it in OpenVPN profile manager Server scoring algorithm implementing the latest AirVPN balancing factors in order to determine the best server for quick connection Network name and extra information are shown along with network type Device network status management Kind regards & datalove AirVPN Staff Complete changelog available here: https://gitlab.com/AirVPN/EddieAndroid/blob/master/ChangeLog.txt Changelog 2.3 (VC 23) - Release date: 02 July 2019 by ProMIND [ProMIND] - Updated default manifest - Updated native library - AES-256-GCM is now the default cipher - Language override reported to the log - Improved connection error handling - Added statistics in server tab - Minor bug fixes Changelog 2.3 beta 2 (VC 22) - Release date: 27 June 2019 by ProMIND - [ProMIND] About page and webview function now point to https://airvpn.org - [ProMIND] Updated native library with the latest sub-project branches and releases AirVPNUser.java - [ProMIND] getOpenVPNProfile(): AES-256-GCM is now the default cipher MainActivity.java - [ProMIND] Language override is reported to the application log OpenVPNTunnel.java - [ProMIND] improved connection error handling - [ProMIND] removed doRun() method. Method's body moved to run() VPN.java - [ProMIND] Added CONNECTION_ERROR to Status enum VPNService.java - [ProMIND] Added method handleConnectionError() Changelog 2.3 beta 1 (VC 21) - Release date: 17 May 2019 by ProMIND AndroidManifest.xml - [ProMIND] set android:allowBackup and android:fullBackupOnly to false airvpn_server_listview_group_item.xml - [ProMIND] added server statistics layout ConnectAirVPNServerFragment.java - [ProMIND] AirVPNServerExpandableListAdapter.GroupListViewHolder: added server statistics items - [ProMIND] AirVPNServerExpandableListAdapter.getGroupView(): added server statistics items to HEADER and GROUP types - [ProMIND] createGroupList(): compute server statistics for HEADER and GROUP types AirVPNUser.java - [ProMIND] getUserLocation(): set connection timeout to SupportTools.HTTP_CONNECTION_TIMEOUT - [ProMIND] getUserLocation(): set read timeout to SupportTools.HTTP_READ_TIMEOUT - [ProMIND] logout(): user name, password and current profile are set to empty and forgetAirVPNCredentials() is called native library - [ProMIND] updated to the latest openvpn3, lz4, mbedtls and asio commits manifest.xml - [ProMIND] updated to the latest document

Thank you! Of course. The idea has been floating around since several years ago https://community.openvpn.net/openvpn/wiki/RoadMap The OpenVPN 3 Core Library is based on a different approach, implementing the OpenVPN protocol as a C++ library. This gives lots of the same possibilities and modularity as this draft tried to resolve. Further, OpenVPN 3 is multi-thread capable and integrates with ASIO for all asynchronous processing and socket handling.

We agree, when AES-NI are supported. Note that some processors do support AES-NI but the system doesn't use them (examples: AES-NI disabled at BIOS level; OpenSSL or other SSL library not properly compiled). Also see https://tools.ietf.org/html/rfc8439#appendix-B (however note that the comparison is made between AES-128-GCM and ChaCha20 but a more correct comparison would be with AES-256-GCM because of the 256 bit key size of ChaCha20). Not only the appendix but also important considerations in the introduction and later. Kind regards

Hello! We're very glad to inform you that AirVPN has begun to actively contribute to OpenVPN 3 development. Our first goal has been adding support for ChaCha20 cipher with Poly1305 as authenticator on OpenVPN 3 Data Channel. ChaCha20 is a stream cipher developed by Daniel J. Bernstein which combines strength and remarkable performance. https://en.wikipedia.org/wiki/Salsa20#ChaCha20_adoption When compared with AES-GCM, ChaCha20 offers significant computational relief to all AES-NI non supporting processors, such as ARM processors. ARM processors, routinely used on very many tablets, smart phones, media centers, smart TVs and routers, will get great benefits from OpenVPN with ChaCha20. Our tests show that CPU load caused by ChaCha20 on recent ARM 64 bit processors is at least 50% less than AES-256-GCM, on equal terms, which translates into dramatic performance boost and longer battery life (if you have ever tested Wireguard on an ARM based device you know what we mean). OpenVPN 3 is a client library. However, OpenVPN 2.5, which is currently in beta testing and includes all the necessary servers features, supports ChaCha20 on the Data Channel. Therefore, making OpenVPN 3 with ChaCha20 available to our users and allowing a real life test will be a matter of days. We will progressively release beta clients for Android, Linux, OpenBSD and FreeBSD, in this order. We are considering a porting to OpenIndiana as well. Internal alpha testing has concluded successfully. We have already pulled a merge request to OpenVPN 3 main branch, to let the whole community take advantages from our code, and let OpenVPN developers merge the new code into the main branch if they wish so. https://github.com/OpenVPN/openvpn3/pull/78 Implementation has been designed, developed and programmed for AirVPN by ProMIND, who is also Eddie Android edition developer. Stay tuned, more will come! UPDATE: https://airvpn.org/forums/topic/44069-openvpn-3-development-by-airvpn/ The above linked topic is now the central thread to discuss anything related to OpenVPN 3 development and testing. Kind regards and datalove AirVPN Staff

Hello, we wish (in our setup, we mean) that stunnel accepts any connection to bypass restrictions, even when it will have certificate replacement and therefore it is subjected to MITM exploits. The integrity and data security layer is ensured by the underlying OpenVPN tunnel. stunnel is not there to add anything to security when you use OpenVPN over SSL, it is there to try to punch a hole in the filters through which OpenVPN can establish its tunnel. Kind regards

@idealist You don't understand. With static IP addresses stored on the servers you map uniquely and permanently an IP address to a user. Once that IP address is discovered (no need to crack the server, as we wrote) the correlation is done because we know which user always has that IP address, even if we don't log traffic, and we would give away the information under a court order. Which is exactly what go558a83nk already explained to you. This is not possible with OpenVPN, as the dynamic IP addresses are never correlated to a user once the session is over, they are lost. So if the attacker asks "who has that IP address?" with OpenVPN in our setup we don't know, while with Wireguard in the current (at the time of writing) stage of development we would know. If now or in the future Wireguard will allow dynamic addresses assignments, so that no address must be stored permanently for any client, the problem is resolved, but at the time we wrote the article it was not. Kind regards

The issue has been already explained: the keys and the internal IP addresses are all on the server, and they are on every and each server. They can be used to correlate specific targets and disclose their identities, while on our current setup that's not possible. It makes a world of difference when you consider threat models in which VPN users are specifically targeted. Maybe you don't understand the importance of this menace because you wrote: which is correct in our setup, but incorrect in Wireguard setup. The attacker CAN get the internal IP address via WebRTC for example and: 1) in our setup he/she does not correlate the internal IP address with the client key 2) in Wireguard setup he/she does Once that's done the attacker may obtain legally (via a court order) the payment data of the user because it can ask us which user is linked to a single IP address (and also the user key for subsequent forensic evidence). Since the VPN IP address is static and unique, we would be of course forced to comply. We wish to underline for the last time that the problem has been acknowledged by developers and we had been told that it would be resolved. Kind regards