Jump to content
Not connected, Your IP: 34.231.243.21

Staff

Staff
  • Content Count

    9126
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1350

Posts posted by Staff


  1. 19 minutes ago, Valerian said:
    @Staff

    All my browsers are set to UK English/en-GB, as is Windows, but in all of them the dates are shown like 07/26/2021 instead of 26/07/2021.

    Understood. Maybe an error by Invision? Go to your account "Client Area" > "Preferences" page, and force the date time, language and format you wish, instead of "browser". Click "Save" and verify whether the change complies to your choice.

    Feel free to keep us posted.

    Kind regards
     

  2. Hello!

    We're very glad to announce that, in compliance with its mission, AirVPN proudly supports WikiLeaks https://wikileaks.org in 2021 too, with a 0.32577602 BTC donation, around 20,000 USD at the moment of the transaction.

    WikiLeaks is an international non-profit organization that publishes news leaks and classified media provided by anonymous sources. Since 2006, the group has released a huge amount of documents of paramount importance and public interest, with an outstanding 100% accuracy so far, which deeply changed our vision and knowledge of the world.

    https://www.blockchain.com/btc/tx/527abecb9e8959556fd01cba66b45890a71f643eddff3cb1d6f9d4ffd39dc15b

    AirVPN's mission:
    https://airvpn.org/mission

    Kind regards & datalove
    AirVPN Staff

     


  3. On 9/19/2021 at 2:42 PM, Staff said:
     

    ExpressVPN has always been perfectly aware that one of its executives was an American intelligence operative who helped UAE human rights hostile government in cracking operations. We do agree with Edward Snowden when he says that you must not use ExpressVPN. Incidentally, ExpressVPN is now part of a big group that, throughout the past decade, was an adware based business with shady privacy practices.
     

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

    Kind regards
     

  4. @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
     

  5. 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
     


  6. 14 hours ago, jeromec said:

    Thanks @Staff for the reply and quickfix, but I do not understand "At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so ."


    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.

     
    Quote

    I really do not think it is viable to use expired certification routes for up-to-date-systems.


    That was never the case. The problem is caused by bugged TLS libraries in your system.
     
    Quote

    I hope I can re-enable "check DNS" in AirVPN soon on my Macs.


    Yes, you can do it now!
     
    Quote

    I understand you want to keep compatibility with older Android versions, but shouldn't you have a specific version or specific settings for older Android and not degrade security for more recent platforms?


    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
     

  7. @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

     

  8. @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
     

  9. @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
     

  10. 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
     

  11. 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
                          


  12. @apero

    We confirm what we wrote in our initial message, we're sorry.
     
    Quote


    Important note for Android TV users. In Android 10 and 11, a VPN application can start and connect during the device bootstrap if and only if "Always on VPN" option is active. Unfortunately the option is not available in Android TV 10 and 11. Therefore the ability to start at boot is lost. OpenVPN for Android and openvpn-connect applications are affected by the same constraint.


    @apero
     
    Quote

    The inability to have VPN auto-connect during boot, like on Android TV 9, is a real bummer and something that would be greatly appreciated.


    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
     

  13. UPDATE 2021-10-01: we have modified server side chain order. Therefore, even old TLS libraries bugs should not enter into play anymore. The quick fix is no more needed. Please feel free to report any malfunction.


    Hello!

    If you are running Eddie Desktop edition and you have started experiencing route check failures, read on. We have here a clear explanation, an easy solution and a slightly more complex solution as an alternative.

    Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary).

    The best solution is upgrading your TLS library and your curl and libcurl packages.

    However, if you can't or don't want to do so, a quicker and very simple workaround is available:

    • from Eddie's main window select "Preferences" > "Advanced"
    • de-tick "Check if the VPN tunnel works"
    • click "Save"
    • from Eddie's main window select "Preferences" > "DNS"
    • de-tick "Check Air VPN DNS"
    • click "Save"
    • from Eddie's main window enable Network Lock

    The above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security. We are considering whether packaging Eddie with proper curl and libcurl builds linked against very recent TLS libraries, but we must consider all the potential issues in each system.

    Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here:
    https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/

    Now, if you run a cURL version linked against OpenSSL older than 1.1.0, or LibreSSL version older than 3.2.0, or GnuTLS version older than 3.6.7, the validation chain will fail (messed up path building) with the current LetsEncrypt certificates. It's a TLS library bug working in negative synergy with LetsEncrypt decision.

    Special thanks to Ryan Sleevi who made us understand exactly the nature of the problem with his great article written more than a year ago and which we read only now:
    https://medium.com/@sleevi_/path-building-vs-path-verifying-implementation-showdown-39a9272b2820

    Kind regards
     

  14. Hello and thank you for your choice!

    Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary).

    Then, please try the following settings:

    • from Eddie's main window select "Preferences" > "Advanced"
    • de-tick "Check if the VPN tunnel works"
    • click "Save"
    • from Eddie's main window select "Preferences" > "DNS"
    • de-tick "Check Air VPN DNS"
    • click "Save"
    • from Eddie's main window enable Network Lock

    Try again connections to various servers.

    Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here:
    https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/

    Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS library bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so .

    Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security.

    Kind regards
     

  15. Hello and thank you for your choice!

    Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary).

    Then, please try the following settings:

    • from Eddie's main window select "Preferences" > "Advanced"
    • de-tick "Check if the VPN tunnel works"
    • click "Save"
    • from Eddie's main window select "Preferences" > "DNS"
    • de-tick "Check Air VPN DNS"
    • click "Save"
    • from Eddie's main window enable Network Lock

    Try again connections to various servers.

    Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here:
    https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/

    Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS library bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so .

    Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security.

    Kind regards
     

  16. Hello and thank you for your choice!

    Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary).

    Then, please try the following settings:

    • from Eddie's main window select "Preferences" > "Advanced"
    • de-tick "Check if the VPN tunnel works"
    • click "Save"
    • from Eddie's main window select "Preferences" > "DNS"
    • de-tick "Check Air VPN DNS"
    • click "Save"
    • from Eddie's main window enable Network Lock

    Try again connections to various servers.

    Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here:
    https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/

    Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS library bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so .

    Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security.

    Kind regards
     

  17. Hello and thank you for your choice!

    Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary).

    Then, please try the following settings:

    • from Eddie's main window select "Preferences" > "Advanced"
    • de-tick "Check if the VPN tunnel works"
    • click "Save"
    • from Eddie's main window select "Preferences" > "DNS"
    • de-tick "Check Air VPN DNS"
    • click "Save"
    • from Eddie's main window enable Network Lock

    Try again connections to various servers.

    Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here:
    https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/

    Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS ibrary bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so .

    Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security.

    Kind regards
     

  18. Hello!

    VPN DNS and "Assigned IP address" technical specifications just changed. All the changes have been reported in the https://airvpn.org/specs page.

    The changed section is:

    Assigned IP

    Servers support both IPv4 and IPv6 tunnels and are reachable over IPv4 and IPv6 on entry-IP addresses.
    DNS server address is the same as gateway, in both IPv4 and IPv6 layer.

     

    Chosen IPv4 Local Address

    OpenVPN: 10.{daemon}.*.*, Subnet-Mask: 255.255.255.0
    WireGuard: 10.128.0.0/10

    Chosen IPv6 Unique Local Address (ULA)

    OpenVPN: fde6:7a:7d20:{daemon}::/48
    WireGuard: fd7d:76ee:e68f:a993::/64

    The new sections are:

     

    DoH, DoT

     

    Every gateway/daemon assigned to you acts as a DNS (port 53), DoH (dns-over-http, port 443), DoT (dns-over-tls, port 853).
    DoH and DoT don't add any actual benefit, because plain DNS requests are encrypted inside our tunnel anyway.
    However, users might need it for special configurations. In such cases, use dns.airservers.org (automatically resolved into VPN gateway address).
    Our DNS returns a NXDOMAIN for "use-application-dns.net", for compatibility reasons.


    Special resolutions

    check.airservers.org - Gateway IPv4 and IPv6 addresses
    exit.airservers.org - Exit-IPv4 and exit-IPv6 addresses
    use-application-dns.net - NXDOMAIN, for DoH compatibility, ensuring Air DNS will be used (for anti-geolocation features)


    Special URLs

    https://check.airservers.org - Info about connected server
    https://check.airservers.org/api/ - Same as above, in JSON
    Use https://ipv4.airservers.org or https://ipv6.airservers.org - Same as above, specific IP layer


    Kind regards and datalove
    AirVPN Staff
     

×
×
  • Create New...