Staff

Hello! HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect secure HTTPS websites against downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security The implications of your report are deep. It means that your browsers correctly connected to airvpn.org in the past, but now are connecting to some web site that is not forcing HTTPS. Please check airvpn.org resolution in the system with this problem. Kind regards

Website: Swisscom TV Switzerland streaming television from Swisscom, Live and On Demand. Status: OK Native: CH servers. Routing: All other servers.

Hello, welcome aboard. The information you are looking for are easily and clearly accessible on our web site. It is beyond our imagination how you could not find them. This is a Frequently Asked Question, for example, and it is also reported in our guides. Did you read answers to Frequently Asked Questions? Specifically, please see here; https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses Have you had a look to our real time servers monitor by clicking "Status" from our web site upper menu? Did you know that we're the only consumers' VPN service in the world providing a tool with such features? https://airvpn.org/status "Sort of" the bollocks of the Big Brother. Our client features selections based on countries, single/specific servers, group of servers with any custom definition through user defined white list and black list, automated, asynchronous and synchronous scripting/executables triggering at seven different events and much, much more. Servers switching is unlimited and without time constraints. For additional information, please see our home page: https://airvpn.org and the technical specifications page: https://airvpn.org/specs Direct link to Frequently Asked Questions: https://airvpn.org/forum/24-frequently-asked-questions/ Direct link to Guides, Manuals and How-To: https://airvpn.org/forum/15-how-to The "Search" function available in the upper right corner, in the "Advanced" form, is quite powerful, use it, it's free. Please note that all of the above information is reported even in the welcome e-mail which is sent automatically at each new subscription. Kind regards

Hello, that's correct, logging with a username containing spaces in an xmpp server is not possible. You can't change your username in our system (you can only change your Display Name, which does not affect your username) so you'll need to open a ticket asking "Support" dep. for this action Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the Czech Republic is available: Alioth. 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"). Alioth accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Alioth 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! The problem is here: Your system can't resolve localhost name. This is required by Air client Eddie to communicate with OpenVPN management. It may be required by several other applications too. localhost is generally not resolved with a DNS query but at hosts level. Make sure that in your hosts file the line: 127.0.0.1 localhost is the first line in the hosts names list. How to edit hosts file in Windows 7: http://helpdeskgeek.com/windows-7/windows-7-hosts-file Kind regards

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

Hello! Oh, ok, in this case what we wrote earlier is totally irrelevant. Kind regards

@Afronautz Please note that port 6970 is NOT forwarded to your client. Please see also here about port forwarding: https://airvpn.org/topic/9161-you-provide-remote-port-forwarding-what-is-it Kind regards

No.

Hello! We're sorry to inform you that according to the following message from UrDN http://www.urdn.com.ua/ all the servers in the Kiev datacenter, including AirVPN servers, have been illegally stolen by Ukrainian "security services" SBU and should be released only after payment of a bribe. We have no way to verify this message unfortunately, but in any case our servers, as you probably know, do not contain any log and/or any database and/or any sensitive information. Therefore, Procyon and Theemim will not come back anytime soon, as UrDN declares that they will not pay any bribe/ransom to get back the servers. If the message is truthful, we would like to express our complete solidarity with UrDN and condemn the acts of the Ukrainian "security services" SBU which would be identical to those of a criminal organization. Kind regards AirVPN Staff

Hello! We're glad to inform you that Eddie developer has put this issue as a priority for the next Eddie release. Kind regards

Hello! There are no particular issues on our side, the service is very good as usual. The problem must be somewhere either in your system, local network, router, or ISP... please feel free to open a ticker for further investigation. Kind regards

You can read the regulation here: http://data.consilium.europa.eu/doc/document/ST-10788-2015-INIT/en/pdf

Hello, it appears that there are some misunderstandings about the new regulation. In the worst case scenario, it just leaves the situation as it is already and has always been since years ago. But there are some interesting things for the citizen. Please read it before commenting! See also here: https://airvpn.org/topic/15717-possible-new-law-in-europe-about-vpns-and-torrents/?do=findComment&comment=33267 You can find the regulation in its current form here: http://data.consilium.europa.eu/doc/document/ST-10788-2015-INIT/en/pdf Move to that thread, please, this one is now locked. Feel free to explain how it is a bad thing for Net Neutrality instead of a (although small) step forward to it. Kind regards

Anyway, it's important to know that Network Lock is important for other purposes, not only for leaks prevention in case of unexpected VPN disconection. In Windows 10, in particular, due to DNS new phantasmagorical implementation (nope, no global DNS in Windows... again... probably never...) Network Lock can play a key synergy role in DNS leaks prevention, and a key role under a very peculiar attack exploiting usage of Win 10 DNS and Eddie settings that one of our customers found and kindly informed us of. On top of that Network Lock prevents leaks due to processes binding to the physical interface (remember WebRTC for example) etc. etc. Kind regards

Hi, actually throttling of p2p and VPN is what routinely occurs in the European Union. It is illegal, though, to do it if the customer has not been fully and clearly informed on the contract, please see here: https://airvpn.org/topic/10967-slow-airvpn-speeds-050mbs-down-or-less/?do=findComment&comment=15358 The new regulation is an additional and nice step forward to Net Neutrality, but it's still weak and actually it still allows various discriminations. However, when the regulation is in force, situation for the EU citizen will be better or equal to the current situation, not worse. Since years ISPs have put encrypted traffic to the slow lane. But since HTTP is being discarded more and more and HTTPS is becoming dominant in the World Wide Web, OpenVPN over SSL to port 443 has always been a perfect patch, because usually ISPs tend to treat pure TLS traffic to port 443 totally equivalent to HTTPS, which you can't throttle too much without impacting 100% of your customers. Kind regards

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