Staff

More very important information: https://english.almayadeen.net/articles/analysis/exclusive:-expressvpn-insider-tells-all-on-companys-israelua Kind regards

@maasenstodt Hello! Currently Eddie does not re-download automatically any new certificate/key pair: in Eddie main window, log your account out and then log it in again, in order to force Eddie to re-download client certificate(s) and key(s). A detailed guide is available here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! Frequently, the wintun driver can solve different problems caused by the TAP driver. If you have problems with the TAP driver (including installation issues), try and switch to the wintun one: in "Preferences" > "Advanced" window tick "Use wintun driver" then click "Save", finally re-start Eddie. Eddie 2.19 or higher version is required. Kind regards

Hello! Ignore that sentence, actually we fixed the issue on server side to maintain compatibility with bugged TLS libraries and at the same time old Android versions will not be affected. That was never the case. The problem is caused by bugged TLS libraries in your system. Yes, you can do it now! You understood exactly the opposite of what it really happened. Security degradation is on client side affecting those systems still running with obsolete TLS libraries affected by critical bugs. Although we now keep compatibility even with bugged TLS libraris, please consider to upgrade your system anyway. Bugged TLS libraries are (at least) OpenSSL 1.1.0 or older versions, LibreSSL older than 3.2.0 version, GnuTLS older than 3.6.7 version. As you can see they are all obsolete versions which should not be used anymore. Kind regards

@Iyam Nadie Hello! Yatse "receiver" and client listen to ports 8083 and 9077. Can those ports be configured, both in server and client? If so, you can remotely forward ports in our system (from your account "Client Area" > "Ports" panel) and then configure Yatse server and client to listen / reach to the same port numbers you remotely forwarded, as long as you need to contact Yatse receiver from the Internet. If those ports are hard coded (but hopefully in 2021 nobody hard codes anything anymore) you can't follow our suggestion. However, you could consider to reach the Yatse listening service from and to the local network, no need to send the packets to the Internet from your home network, and then receive them back, after they traveled around the world, to your home again. Can Yatse service be configured to bind to a specific interface? Kind regards

@y0wl Hello! Thank you. It's an Eddie 2.21.1 problem, so this is not the proper thread, and we are moving your messages to the following thread: https://airvpn.org/forums/topic/49638-eddie-desktop-221-beta-released/ Please continue there. We will also make sure that developers get your report. Kind regards

@cloudofsky Hello! Can we see the complete Goldcrest log, Bluetit log and bluetit.rc and goldcrest.rc files content? To print Bluetit log: sudo journalctl | grep bluetit Kind regards

@Breeze Hello! Thank you! Access activation to Wireguard beta testing will be available in the "Client Area". We will have more information on a definite date very soon, we're still working on it. Announcement will follow in "News" forum. Can you also tell us your Linux distribution name and version? If you run Eddie beta from other packages (not the AppImage) do you see the same crash? Kind regards

Hello! Please be aware that the core router serving our servers in Dallas (TX, USA) will be replaced on Saturday October the 9th at 18.00 UTC (20.00 CEST). Expected downtime of all of our servers is approximately 1 hour. Kind regards

@y0wl Hello! The procedure you describe should not be necessary as Eddie must take care of it. However some old Eddie version has a bug and Hummingbird could not be launched because it was not owned by root. Eddie, for security reasons, does not start with root privileges anything not owned by root. Do you still need the procedure you describe with Eddie latest release 2.20.0? Kind regards

Hello! The current state of play as well as important clarifications. The issue occurs only in those OpenVPN clients linked against OpenSSL 3 and only to some of our users, see below Since 2017, our system generates CRT signed with SHA512 algorithm. Previously they were signed with SHA1. Regeneration of old CRT is not triggered and forced by us automatically, because it would invalidate any previous OVPN configuration file out there and lock out the user who does not follow our forum, notification e-mails etc. @rprimus you have a client CRT (user.crt) dated 2015. You and anybody else using pre-2017 user certificates: please go to your "Client Area" > "Devices" menu, renew your cert/key pair, re-download your OVPN configuration files from the Configuration Generator, use them and you will be fine. (*) The problem has never been caused by the CA certificate. Replacing the CA.crt is not mandatory, it just avoids warning message (that you can safely ignore and has nothing to do with the main issue of this thread) you may meet in Eddie Android edition, Hummingbird and Bluetit. Anyway, now even ca.crt is SHA512 signed, so you will not get anymore the mentioned warning (*) Yellow rows show certificates which use a signature based on a deprecated for security reasons hash algorithm (SHA1). They are still here to ensure backward compatibility, because we can't know whether you still use them in generated profiles. However, future OpenVPN versions might not allow them anymore. Click 'Renew' or 'Delete' to resolve the issue. After that, re-generate profile(s) with our Configuration Generator. If you run our client software Eddie, you just need to log your account out and in again from the main window. Kind regards

@OpenSourcerer @77festus77 Thank you. Can you tell us how you reproduced the problem? In our current tests, OpenVPN for Android 0.7.25 (latest version on the Play Store) connects fine to our servers, both on entry-IP addresses 1 and 3. Tested on various devices based on Android 6, 10, 11. Apart from various app explosions, when it does not crash it connects fine. Kind regards

Hello! Signature of a root CA certificate is there only as a dummy one, and the verification of a CA certificate is not based on any signature, obviously. So, there is no security hazard coming from the signature algorithm of a root CA certificate. Anyway if the source of the problem is the one you mention we will plan some solution to have OpenVPN for Android compatible again. It will take some time, so you might consider to run Eddie Android edition 2.4 or 2.5 alpha in the meantime. "The purpose of the signature in a certificate chain is that a higher authority certifies a lower authority. For a root CA, there is no higher authority by definition (that's what "root" means), so there is nobody who could possibly sign the certificate. Since, as was mentioned, certificates must be signed, root CAs are signed with a "dummy" signature, and the simplest way to do that, is to self-sign. So, not only is there no need to verify, the very idea of verifying the signature of a root CA is non-sensical." Jörg W Mittag, in https://serverfault.com/questions/837994/why-are-ca-root-certificates-all-sha-1-signed-since-sha-1-is-deprecated Kind regards

@cloudofsky Hello! Yes, please check the manual here: https://airvpn.org/suite/readme/#goldcrest-client The option meeting your needs is: List items shall be separated by a comma. Enjoy AirPVN suite! Kind regards

@apero We confirm what we wrote in our initial message, we're sorry. @apero No doubts, but it's the system that's designed to prevent VPN connections at boot, and we loosely suspect that it's a deliberate choice. Remember that you have very limited control on "your" Android TV device, with limited privileges. We would be glad to implement some hack to allow connection at boot; so far we did not find any, unfortunately. Kind regards