Staff

Hello! The premise is wrong, there's no known such "weakness" in HMAC SHA1, in the sense that in HMAC SHA1, SHA1 collisions based attack is currently irrelevant. The article you linked refers to SHA1, not HMAC SHA1 (for a precise description of the reason, keep reading). See also for a quick, qualitative confirmation https://www.schneier.com/blog/archives/2005/02/sha1_broken.html : We'll say more, even HMAC MD5 can still be considered unaffected by collisions, see for example http://crypto.stackexchange.com/questions/9336/is-hmac-md5-considered-secure-for-authenticating-encrypted-data The article you linked in your other post talks about SHA1 used for digital signatures (of certificates or anything else). That's really a problem because real world attacks are estimated to be feasible in the near future (2017). Switching Data Channel packet authentication digest in our setup would be swift on our side, but would break compatibility with customers using OpenVPN/OpenSSL versions that can't support it. For this reason, we will carefully evaluate the switch, with no hurry. See here: http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html Now, in spite of all of the above, let's take a conservative approach. SHA1 collisions can easily become real-world feasible within a couple of years. So, not later than 2017, we will (most probably) assist to the first time practical collision attacks breaking SHA1. In this scenario, let's imagine that someone can figure out how to turn that into a pre-image attack against HMAC, making both conditions 1 and 2 of the above cited paper NOT met. In this case, switching digest will be mandatory, because we would be in a scenario where the packet-injection resistance of OpenVPN would be potentially compromised. Therefore, in order not to cut out customers without any reasonable, valid reason, we will prepare a switch with no time pressure but with careful planning. EDIT: PRF = Pseudo Random Function Kind regards

Hello, no, those points are all blatantly false. We don't understand how you could infer those from the .ovpn file, which on the contrary should have led you to opposite conclusions. Fist and foremost, AirPVN OpenVPN daemons operate in tls-mode. From the manual: That's exactly what it happens. Additionally, DH keys are 4096 bit. And that's what you see in the .ovpn file. An element that might have contributed to your confusion is that you don't see in the .ovpn file of your client the "tls-client" directive to enable TLS mode. That's because the directive "client" is used instead, which is expanded into "tls-client" + "pull". Again, reading the manual helps: You can easily check all of the above by looking at your OpenVPN client logs pertaining to a connection to any VPN server. You will see something like: ... - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key ... - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication ... - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key ... - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication ... - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA Enjoy AirVPN! Kind regards

Website: http://www.ardmediathek.de/tv/Das-Erste/live?kanal=208 German TV channel Das Erste. Status: OK Native: NO Routing: All servers.

Hello! Can you please try again now? Please note that share-online only allows one download per IP per a given period time. So, if someone downloads one file while connected to some VPN server, all the users connected to that VPN server will not be able to download anything during that period of time (presumably some hours). We don't know if this restriction applies to their Premium subscribers. As LazyLizard14 points out, their business practices are very questionable (please see the first message in this thread). Kind regards

Hello! Please make sure that you're running client version 2.10.3. Select "AirVPN" -> "About" to check. Network Lock in Windows activates Windows Firewall so the feature can not be used in any way when a different firewall is active. Running two different firewalls may cause unpredictable behavior because (to put it briefly) you have two programs with same high privileges which compete to modify concurrently the OS packet filtering tables. Kind regards

Hello! In our testing systems and according to a significant amount of independent reports, Network Lock works fine with Eddie 2.10.3 and Windows 10. Kind regards

Hello, it's not specific to Linux, it's an OpenVPN directive, tls-cipher It accepts a list of TLS ciphers (with IANA and/or OpenSSL names format) that your client can accept for the Control Channel. If the directive is specified your OpenVPN will only try the listed ones (watch out, therefore). If you set only one, you will force that one (again, the server must support it too). Currently it's not necessary (for our service) if your OpenVPN version is 2.3.3 or higher, see our previous post. On the other hand, if your OpenVPN version is older than 2.3.3, you can't use TLS 1.2 DHE-RSA-AES256-GCM-SHA384 For a more precise explanation, please see directive tls-cipher in the OpenVPN manual Kind regards

Hello, we have identified the problem. Can you try again and confirm that it works now ? Kind regards

We cross-checked the reports of dozens of our customers with Virgin Media UK, asking them to resolve "airvpn.org" on two of Virgin DNS servers. Since all the reports matched exactly throughout one year, we can safely assume that the reports are reliable. It is also worth mentioning that DNS poisoning of airvpn.org is intermittent, and when contacted directly about the issue, Virgin Media responded to us that it was a technical problem, totally unintentional. How are we supposed to know? All in all even the cyber workers of the government of China are interested in our web site, not only with DNS poisoning but also IP blocking. Who knows, maybe it's really just an obscure technical error that re-occurs periodically. Kind regards

Hello, the Data Channel cipher for packets authentication is HMAC SHA (edit: note that there is no GCM support for the data channel yet... it will be probably implemented in OpenVPN 2.4). Perhaps your libraries do not support DHE-RSA-AES256-GCM-SHA384 with TLS 1.2 (also listed as "TLS-DHE-RSA-WITH-AES-256-GCM-SHA384" in OpenVPN 2.3.8). In this case use "TLS-DHE-RSA-WITH-AES-256-CBC-SHA". Edit: note that there is absolutely no rational reason to rush to SHA384 and drop HMAC SHA1 which is NOT vulnerable to SHA collisions. We often read (even in our forum) a confusion pertaining to SHA1 vulnerabilities, which are thought (with an unexplainable mistake) to be extended to HMAC SHA1. See also here: https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure Back to the Control Channel, which is the subject of this topic. By default, OpenVPN 2.3.3 or higher will first choose TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 if available, over TLS-DHE-RSA-WITH-AES-256-CBC-SHA, so if you needed an explicit directive for the first, very probably your system does not support it. So, at the end of the day, you normally do not need any additional directive, OpenVPN will pick automatically the best cipher between those available both in your and our systems. See also "openvpn --show-tls". One more edit: please see also here https://security.stackexchange.com/questions/92638/openvpn-cipher-vs-tls-cipher , in particular: Kind regards

Hello! Ok, anyway, if you prefer so, probably you have noticed that since some weeks ago you can use (provided that your OpenVPN and OpenSSL or PolarSSL supports it) the following TLS cipher: DHE-RSA-AES256-GCM-SHA384 with TLS 1.2. The RSA keys are of course the same (4096 bit) as well as DH keys (4096 bit). If you feel that HMAC SHA1 is not adequate for the Control Channel (but we see no reasons for that) you can use the above cipher. Kind regards

Hello! The boxes are displayed on most, if not all, of our web site pages. This is a very light one https://airvpn.org/aboutus Kind regards

@just-me & others Hello! It looks like Eddie behaves correctly and properly. By default, it appears that Windows Firewall is disabled in your system. When you enable Network Lock in Eddie, it activates the firewall. You can see here that your firewall was disabled and Eddie enables it: ! 2015.10.15 22:47:17 - Activation of Network Lock - Windows Firewall ... . 2015.10.15 22:47:21 - Shell of 'cmd.exe','/c netsh firewall set notifications mode=disable profile=DOMAIN' done sync in 218 ms . 2015.10.15 22:47:21 - Shell of 'cmd.exe','/c netsh advfirewall set private state on' done sync in 219 ms . 2015.10.15 22:47:21 - Shell of 'cmd.exe','/c netsh firewall set notifications mode=disable profile=STANDARD' done sync in 218 ms . 2015.10.15 22:47:22 - Shell of 'cmd.exe','/c netsh advfirewall set public state on' done sync in 219 ms . 2015.10.15 22:47:22 - Shell of 'cmd.exe','/c netsh firewall set notifications mode=disable profile=CURRENT' done sync in 218 ms . 2015.10.15 22:47:24 - Shell of 'cmd.exe','/c netsh advfirewall firewall delete rule name=all' done sync in 1903 ms . 2015.10.15 22:47:24 - Shell of 'cmd.exe','/c netsh advfirewall firewall add rule name="AirVPN - ICMP V4" dir=in action=allow protocol=icmpv4' done sync in 172 ms ... ... Then, when you either disable Network Lock or shut down Eddie, Eddie restores the firewall to its previous state (which was DISABLED): ! 2015.10.16 07:43:40 - Deactivation of Network Lock . 2015.10.16 07:43:42 - Shell of 'cmd.exe','/c netsh advfirewall set domain firewallpolicy ,' done sync in 1498 ms . 2015.10.16 07:43:42 - Shell of 'cmd.exe','/c netsh advfirewall set private firewallpolicy ,' done sync in 171 ms . 2015.10.16 07:43:42 - Shell of 'cmd.exe','/c netsh advfirewall set public firewallpolicy ,' done sync in 188 ms . 2015.10.16 07:43:44 - Shell of 'cmd.exe','/c netsh advfirewall import "C:\Users\Anon\AppData\Local\AirVPN\winfirewall_rules_backup.wfw"' done sync in 1669 ms . 2015.10.16 07:43:44 - Shell of 'cmd.exe','/c netsh advfirewall set domain state off' done sync in 218 ms . 2015.10.16 07:43:45 - Shell of 'cmd.exe','/c netsh advfirewall set private state off' done sync in 234 ms . 2015.10.16 07:43:46 - Shell of 'cmd.exe','/c netsh advfirewall set public state off' done sync in 1279 ms Kind regards

Hello! If you had Network Lock enabled in our Air client, you have always prevented "WebRTC leaks", as well as any other packet out of the tunnel sent by any process binding to your physical network card. https://airvpn.org/faq/software_lock/ Kind regards

Hello! We remind you that we use 4096 bit keys for DH and unique primes on each VPN server. Kind regards

Hello, in several cases it's not enough that a second firewall is disabled. Conflicts can arise anyway according to our experience with Comodo and Windows Firewall. Kind regards

Hello! We inform you that a rack relocation of servers Aquilae, Tauri and Velorum (DE) will occur during the night between October the 19th and the 20th (UTC). We will shut the servers down at: 10-19-15 21.00 UTC We expect to bring the servers back on line approximately at: 10-20-15 05.00 UTC Kind regards AirVPN Staff

In this case there is a pinned topic on this very same forum. Kind regards

Hello, probably it has nothing to do with Network Lock feature. It's not unusual that public WiFi hot spots block UDP. Maybe that's the cause of the problem. Try a connection in TCP, or even "SSL Tunnel - Port 443" to see whether it solves the problem. In Eddie you can change connection mode in "AirVPN" -> "Preferences" -> "Protocols". Kind regards

Dozens of reports throughout 2014 and 2015 show that in Virgin network DNS poisoning is (probably intermittently) used against https://airvpn.org Solution: use a publicly accessible, not poisoned DNS, for example OpenNIC https://opennicproject.org or contact us to know alternative domain names to access various https front ends in our infrastructure.

A report dated September 2015 shows that it is not possible to use OpenVPN in UDP mode. Possible interference/disruption. Solution: connect in TCP.

Hello! We're very glad to inform you that a new 100 Mbit/s server located in Ukraine is available: Procyon. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Procyon supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello, just an idea: please check the OpenVPN socket buffers sizes in the router (you can see how they are set for example in the OpenVPN logs). When you run the client, it tells OpenVPN to set buffers of 128 kB. Buffers smaller than 64 kB may slow down performance significantly when required throughput exceeds 20 Mbit/s. The directives for OpenVPN are (respectively for the send and the receive buffer): sndbuf n rcvbuf n where n is in bytes (so set them to 131072 to have 128 kB buffers). Kind regards

Hello, the performance looks bad even without VPN. By the way do not trust our speed test (or any other speed test) and make sure to test different servers in different countries. How are the OpenVPN socket buffers sizes set? Kind regards

Hello, not reproducible on any testing machine. Never reported by thousands of customers using Eddie with Windows every day. It must be something extremely peculiar and specific to your system. Can you provide complete details of your system setup (including any antivirus, firewall and packet filtering/inspection tool installed) and exact steps to reproduce the issue? Kind regards