Staff

Hello! Thank you for your feedback. 1) Client, DDNS handling and port checks need an update. We are already working on it and a solution will come out very soon (a matter probably of days). 2) We don't use any RADIUS or other kind of software for authentication purposes. There is no change about privacy and no additional monitoring. Internal details: - Each AirVPN server runs simply OpenVPN daemons - When a new connection is received, after the cryptographic validations, the VPN server contacts indirectly a backend server to notify the connection. This updates a centralized 'active sessions' table in our db, data queried by our website pages for real time stats. Previously, if our backend server already had a session from a user, it replied to OpenVPN server to reject the connection Now, if our backend server already sees 3 sessions from the same user, it tells OpenVPN server to reject the connection. Technically, there isn't any architectural change. It is a 'political' change. Kind regards

Hello! No, wait, the download of keys and certificates is NOT in the clear. It's encrypted via HTTPS with TLS up to 1.2 and Perfect Forward Secrecy (with DHE or ECDHE key exchange). Just don't use Internet Explorer 6 or 8 otherwise you will lose FS and TLS 1.2. Kind regards

Hello! We're glad to inform you that from now on: every account can establish 3 simultaneous connections to DIFFERENT AirVPN servers EDIT 29-Nov-17. This thread is obsolete, now limit of concurrent connections is FIVE. Please see https://airvpn.org/topic/24167-five-simultaneous-connections-per-account/ No impact on quality of service will occur: the guaranteed allocated bandwidth pertains to accounts, regardless of the number of established connections. If you establish 2 or 3 connections with the same account, we guarantee the SAME allocated bandwidth as before, NOT the double or the triple of it. No price increase has been planned for this new feature. As specified above, you can NOT connect the same account twice or thrice to the same AirVPN server. Each connection must go to a different AirVPN server. We're confident that allowing 3 connections per account at the same price will meet fully the requirements expressed by several customers. Please do not hesitate to contact us for any further information. Kind regards & datalove AirVPN Staff

Hello! Crucis is under maintenance and we'll make an announcement soon about it. Kind regards

Hello! We're glad to inform you that in a short time we'll release an Air client version supporting connections of OpenVPN over SSL/SSH. Kind regards

Hello! We're glad to inform you that upgrade completed successfully! Kind regards

UPGRADE IS IN PROGRESS. You can already download the new configuration files (which include new keys and certificates) if you wish so. Kind regards

Tunnelblick users need to re-generate certificates, configuration files and keys, just like users of any other OpenVPN wrapper (except the Air client) need to do. Kind regards

Hello! It's a warning, not an error. The system warns you that the key is accessible by a whole group. Just change the ownership and flags (if necessary) of the file to fix it. For example, make it readable only by root. Kind regards

Hello! Because the service could use different methods than your IP address to detect which country you're in. For example the service can (in HTML5) just ask your browser which country you're in and your browser (if authorized) will tell it. Kind regards

Hello! 2048 bit keys, currently. So what...? The Control Channel cipher is HMAC SHA1, not SHA1. SHA1 is the underlying hash verification. Deprecation has nothing to do with it. It is well known that SHA1 should never be used as a security cipher and OpenVPN does not use it. In HMAC SHA1 we don't even have to care at all about SHA1 hash collisions. In order to inject forged packets in your traffic flow, an attacker should first break every single upper layer, starting from HMAC which is extremely robust, and THEN try hash collisions. Kind regards

Hello! This might help: http://help.smugmug.com/customer/portal/articles/84385-how-do-i-install-the-godaddy-root-certificate-in-windows- Kind regards

Hello! Yes, that's correct. Only AFTER the end of the upgrade. Kind regards

UPGRADE COMPLETED SUCCESSFULLY Hello! We're glad to inform you that a major system upgrade will take place during Sunday, 13 April 2014, 21:00:00 - Sunday, 13 April 2014, 22:00:00 UTC This upgrade has a triple, important purpose: close any possible exploitation chance, regardless of how unlikely it could be, deriving from past "Heartbleed" vulnerability, bring AirVPN in an even higher security environment and open the road for an important new feature of the service: 3 simultaneous connections per account on different servers (details will be provided soon after the major upgrade which takes precedence). The upgrade in details switch to 4096 bit size RSA and DH keysimplementation of additional OpenVPN TLS-Auth layerre-generation of certificates and keysgeneral optimizationDuring the upgrade all the VPN clients will be forcefully disconnected and will not be able to reconnect. The upgrade will take approximately 30 minutes. Disconnections will occur on all servers from-to: Sunday, 13 April 2014, 21:00:00 - Sunday, 13 April 2014, 22:00:00 UTC that is: Sunday, 13 April 2014, 14:00:00 - Sunday, 13 April 2014, 15:00:00 PDT Sunday, 13 April 2014, 16:00:00 - Sunday, 13 April 2014, 17:00:00 CDT Sunday, 13 April 2014, 17:00:00 - Sunday, 13 April 2014, 18:00:00 EDT Sunday, 13 April 2014, 23:00:00 - Monday, 14 April 2014, 00:00:00 CEST Monday, 14 April 2014, 06:00:00 - Monday, 14 April 2014, 07:00:00 JST Click here to find your town: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Switch+to+4096+bit+size+keys&iso=20140413T23&p1=215&ah=1 Mandatory actions After the upgrade, customers running the Air client for Windows will need to shut down and restart the Air client. It is assumed that customers have already downloaded the new package for Windows which includes OpenVPN with non-vulnerable OpenSSL, available here https://airvpn.org/windows and installed the new OpenVPN version. Customers running any other OpenVPN wrapper or OpenVPN will need to re-download configuration, certificates and keys files. Additional information for customers running manually configured wrappers: the "TLS-Cipher" or equivalent name in your configuration becomes: TLS-DHE-RSA-WITH-AES-256-CBC-SHAin Tomato, DD-WRT, pfSense, Fritz!Box etc., the client certificate, the server certificate, the client key and the TLS key must be pasted again (after they have been generated and downloaded from the Configuration Generator as usual) in the appropriate fields of your configurationPlease do not hesitate to contact us for any further information. Kind regards AirVPN Staff

Hello! Of course. It appears that you have not followed https://airvpn.org/topic/11298-openssl-heartbleed-bug-tlsssl-vulnerability/?do=findComment&comment=16461 in the last three days but we strongly recommend that you do that. Of course. Please follow our recommendation. It is premature to allow generation of new private keys as long as the old certificate is not revoked (revocation ordered on 8-Apr, so it should go into effect real soon now) and anyway client private key leak is not such a big deal. Stay tuned, an important announcement is due in a few hours. EDIT: announcement published https://airvpn.org/topic/11319-major-system-upgrade/ Kind regards

Hello! Please post the logs taken just after a connection has been allegedly established. Please right-click on the Air tray icon, select "Logs", click "Copy to clibpoard" and paste into your message. Kind regards

Hello, it's worth checking whether you have some packet filtering tool that might "think" that the UDP traffic is a flood attack. When you connect OpenVPN in UDP mode, all the traffic to your system is UDP only. This may trigger security systems which start to drop packets. Please check your router as well. Kind regards

Hello, yes, TLS Auth shall be implemented. Stay tuned. Kind regards

Hello! Please follow the main thread on the issue or see "News and announcement". https://airvpn.org/topic/11298-openssl-heartbleed-bug-tlsssl-vulnerability/?do=findComment&comment=16461 Kind regards

Hello! The Air client is an OpenVPN wrapper. We are preparing a new package with the new OpenVPN (just released, see NaDre message) which includes a non-vulnerable OpenSSL version. Kind regards

Even nicer: https://www.ssllabs.com/ssltest/analyze.html?d=airvpn.org Kind regards

Hello! The attacker should perform attacks against your node, not ours. Assuming that the attacker knows your real IP address, then the attacker can try to exploit the Heartbleed vulnerability. Please upgrade to Tunnelblick 3.4beta22 build 3789 which implements OpenSSL 1.0.1g. http://code.google.com/p/tunnelblick/wiki/RlsNotes About Android and iOS, openvpn-connect does not use OpenSSL, it employs PolarSSL which (as far as we know) is not affected by this vulnerability. Kind regards

Hello! Please read here: https://airvpn.org/topic/11298-openssl-heartbleed-bug-tlsssl-vulnerability/?do=findComment&comment=16461 Kind regards

Hello! Warning: this document could be updated by the technical staff if necessary. Please consult it again in the near future. After a deeper analysis we would like to inform you about problems, solutions, what we did and what you need to do, in compliance with our transparency policy. The OpenSSL 1.0.1a-->f vulnerability is huge, but several factors in our infrastructure design made the menace a minor threat, without any potentially catastrophic consequence. some of our OpenVPN servers used a vulnerable OpenSSL version. They have been all updated and upgraded between 3 PM and 6 PM 08-Apr-14 CET+1. The non-updated VPN servers running branches of OpenSSL like 0.9.8 were not and are not vulnerable. Assuming that an attacker could steal your user.key on those servers or directly from your system (in case you ran a vulnerable OpenSSL version), the worst damage is that he/she will connect with your account in the future (see below for a solution to this problem). He/she will not be able to decrypt your OpenVPN Data Channel. Various factors help mitigate the problem even on those vulnerable VPN servers: the attacker could not perform an attack through the exit-IP address (he/she should have known the entry-IP) and Perfect Forward Secrecy does not allow the attacker to decrypt your datathe primary frontend (the web site you normally visit) used a vulnerable OpenSSL version which has been upgraded at 3 PM 08-Apr-14 to a non-vulnerable version. All sessions were reset. The vulnerability allowed an attacker to dump a memory portion of the server which could disclose information useful to exploit future access of those users using browsers or web clients not supporting DHE or ECDHE: Internet Explorer 6, Internet Explorer 8, YandexBot 3, or browsers manually forced NOT to use Perfect Forward Secrecy.the backend servers and other vital parts of the infrastructure were not and are not vulnerable, since they were NEVER running a vulnerable OpenSSL versionWhat we have already done: we replaced on every part of the infrastructure the vulnerable OpenSSL versions (if any) with non-vulnerable ones between 3 PM and 6 PM 08-Apr-14 CET+1we changed in advance all administrative accounts passwords (this was not strictly necessary, but it has been performed anyway)we updated the internal SSL certificateswe reset connections of clients connected to VPN servers running OpenSSL vulnerable version and rebooted the server to make sure that no old dynamically linked SSL version was still used by OpenVPNwe performed attacks against our servers, even with the help of independent attackers as peer review, to check that the vulnerability has been resolvedwe have ordered the revocation of the frontend web server previous SSL certificate (this will go into effect in 72 hours according to authority policy)UPDATE 11.15 PM 08-Apr-14 CET+1 we changed the SSL certificate and private key of our frontend serversUPDATE 12.40 AM 09-Apr-14 CET+1 we released a new package for Windows with OpenVPN using non-vulnerable OpenSSLWhat we will additionally do: we're going to add the option to generate new user.key from the client side, with no more need of our manual intervention, just in case someone wishes to use our service for free with your accountUPDATE 1.50 PM 9-Apr-14 CET+1 We are planning a major change in the system with new RSA and DH keys, new certificates and more. The operation is complex and will cause interruptions to the service. You will need to re-download configuration files, certificates and keys, re-configure DD-WRT/Tomato/pfSense etc. so we are planning it with care. A discussion about it is still ongoing and will go on probably for hours, so we can't provide more details. Please stay tuned.UPDATE 11-Apr 14 3 PM CEST IMPORTANT https://airvpn.org/topic/11319-major-system-upgrade/?do=findComment&comment=16533What YOU need to do: change your account password and your API key (if you used our API) and do it as soon as possible especially if you use Internet Explorer 6, Internet Explorer 8 or YandexBot 3 or any other browser that you specifically configured NOT to use TLS with DHE-ECDHE in any way to log in our web site. On this occasion, please consider to drop once and for all Internet Explorer 6 and 8 and prefer browsers supporting PFSchange your user.key when this option will be availableWindows users only download and install new package with OpenVPN using non-vulnerable OpenSSL https://airvpn.org/windows Allow Air client to upgrade OpenVPN version if requiredOS X Tunnelblick users only download and upgrade to new Tunnelblick with non-vulnerable OpenSSL http://code.google.com/p/tunnelblick/wiki/RlsNotesUPDATE 11-Apr 14 3 PM CEST IMPORTANT https://airvpn.org/topic/11319-major-system-upgrade/?do=findComment&comment=16533Kind regards

Hello, the RSA keys are generated with OpenSSL. The TLS keys are exchanged via Diffie-Hellman (DHE, Diffie-Hellman Merkle key Exchange in TLS ephemeral mode to provide Perfect Forward Secrecy, see http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange about previous question on MITM and how to exchange a shared secret key over an insecure channel). Additionally re-keying occurs every 60 minutes by default (in addition to each new connection of course). Kind regards