Staff

Hello! The support answers typically take 1-2 hours (4-5 hours during the weekend nights, CET). If you did not receive any reply please check your spam folder and anyway re-send your support request. You can also elaborate your problem here in the forum, if you wish so. Kind regards

Hello! Unfortunately Phoenicis crashed again and again. We are keeping the server unavailable to premium users while we investigate with the help of the datacenter technicians. Kind regards

Hello! In this case you can't have a DNS leak, the rules will prevent all of them. Even assuming that you mean Mbit/s instead of MB/s, it's quite odd. Maybe your ISP allows bandwidth bursts? Kind regards

You seem to not understand. Even if a website's SSL certificate is compromised, a VPN will not protect you. The data will be sniffed. So this argument is not against Tor alone, but all services. Are you actually arguing that using an OpenVPN will protect you from this type of attack? Are you joking? Hello! The VPN will effectively protect the victim because it lets him/her to get out of the cage. It accomplishes (and accomplished in reality) the attacker purpose. Please note that there's a significant difference between blocking TOR and handling the routes so that the probability that the wished by the attacker circuit is established. Unfortunately the purposes of the attackers in the past were more sinister. Catching the login credentials and exchanged data of activists in Skype, GMail and Facebook is very useful for a human rights hostile regime. Actually, when 300.000 iranian citizens suffered this attack, and the attack was successful (see the previous link about the incident), the purposes were essentially repression and control. That was a significant example, a proof of concept to show you the basis of more sophisticated MITM of SSL attacks. It should appear quite obvious to the careful reader. While with AirVPN this problem is solved with partition of trust (which not necessarily requires TOR), you can't perform partition of trust with TOR alone in the depicted scenario. In that case, the only remaining option to the attacker is disrupting OpenVPN connections (we will soon provide an additional service to mitigate or even solve the problem of OpenVPN connections disruption). It's even worse: actually, as it was repeatedly showed, it is not necessary at all to hack a website to succeed with the attack. The main difference is that if you can't allow yourself to trust the Air operators, you can hide them all your real packet headers AND payloads, while you can't do that with TOR alone in the depicted scenario. We have faced this problem since when we designed AirVPN, and our suggested solution is partition of trust, so that you have a service which you don't need to trust if you can't allow yourself to trust it. Additionally, we have designed the system so that (if the customer wishes so) no identity can be correlated to an account. In this case, the only option remaining to the attacker is perform correlations (typical vulnerability of any low latency "anonymity" network). However, timing attacks become extremely difficult with OpenVPN, and even more with OpenVPN over TOR, theoretically the only adversary that can successfully perform them is the global adversary. Multi-hopping within the same VPN infrastructure (or within different VPNs owned by the same entity), while perfectly possible with Air, does not solve the problem unfortunately, since the operators can trivially correlate all the traffic amongst all the VPN servers, while multi-hopping with different VPNs owned by different entities which do not cooperate with each other, or with a connection over OpenVPN over a proxy, does. Of course you can solve the problem as well connecting over TOR|I2P|etc. over OpenVPN over TOR|I2P|etc. (but not TOR over OpenVPN, unfortunately), in which case you don't have to worry neither about a malignant VPN operator nor a malignant TOR|I2P|etc. exit node. In this case the target can only be defeated by an adversary who can control simultaneously the TOR exit nodes and the VPN server. That this VPN operators can be this adversary, i.e. that they can have the power of a government which can control ISPs and border routers, is an extraordinarily near zero probability. TOR over OpenVPN does not solve the problem because, if you imagine a really nasty VPN operator, you can assume that he/she hi-jack TOR connections from the VPN server to which you connect to, in order to enhance greatly the probability that you establish a circuit where the exit node is controlled by the same nasty operator (but obviously he/she can't do that if you connect over OpenVPN over TOR). I think you are sorely confounding many different things. Let's make a step back before proceeding. Have you understood how the attack works and why it does not need to hack https website and/or authority servers, and how the SSL/TLS packets to and from the victim are decrypted and re-encrypted? Yes, I am aware of that. I was not making specific references to any particular hack. The argument was that the breach was on a third party site; it was not the Tor service. Whether the third party site is CA website or Google, it matters little. We have seen real cases in which the attack does not need neither a breach on any authority website nor a breach on any https website (see the links on the Wikipedia article). We are making specific references to real incidents which really occurred, while the impression (but this admin may well be wrong, no offense meant) is that you are facing the issue in a fantastic, ideal scenario, ignoring the incidents really occurred in the past years. It must be said also, for completeness, that some of the most critical TOR vulnerabilities have been fixed at the end of 2011 ( https://blog.torproject.org/blog/tor-02234-released-security-patches ), while critical vulnerabilities in OpenVPN have not been found until today. Kind regards

Hello! As shown, there are currently various known TOR exit nodes which perform exactly that. In the previous scenario, as it was clearly stated, the attacker was able both to control the significant portion of the TOR network and had valid SSL certificates, regularly signed. In this way using AirVPN can defeat the attacker, simply because the attacker has full control of the border routers, the ISPs in its country and runs a significant number of the only TOR exit nodes (if any) available for establishing a circuit, but not of the networks out of its country. Actually, currently the only way for the attacker to solve this "problem" is only disrupting completely OpenVPN connections. By “normal,” I am here referring to Tor exit nodes (as in the original discussion, before you changed the definitions and the argument) and that data transmitted from Tor exit nodes is safe for encrypted websites, since the encryption of the third party website is independent of the Tor service and is assumed to be secure. So, what makes you think that the above conditions are met for tvhawaii or any other person? This admin has showed you at least two scenarios in which this was not true, and several scenarios which actually occurred in the recent years, so without knowing the power of the adversary that a person must face, those assumptions can't be held generally true. In particular, the assumption that encryption of the third party website is secure is totally irrelevant: actually the attack does not require to compromise the https website at all. The https website is NOT compromised: this is the essence of the attack, and this is the reason for which using a VPN protects the victim. As already stated, currently the only know method to solve this problem for the attacker is only disrupting OpenVPN connections to the victim, thus alerting him/her. No, the real header and payload can't be unencrypted when inside the VPN. You're free to believe what you want to believe. Kind regards

Hello! That's strange, the Air client stores the information in that window just when you close it. Which Windows version are you using? When you perform any change, close the preferences window and then you re-open it, are the changes lost? Kind regards

Hello! Unfortunately this admin knows only the Muppet character Cookie Monster and this Cookie Monster: http://en.wikipedia.org/wiki/Cookie_Monster_%28computer_program%29 so no proper comparison is currently possible by this admin. It's very hard if not impossible to answer in a definitive manner to this question. The Tor Project gives some suggestions to lower the probability to establish a circuit with a malicious relay, please see here: https://trac.torproject.org/projects/tor/wiki/doc/badRelays Local Shared Objects are files stored by Flash (for which they are also called Flash cookies; since they also vaguely remind cookies, they are also called Super Cookies). Their size is arbitrary, there's no theoretical limit to the amount of information which can be stored in them. They are perfect for websites to track users. They might be considered a browser potential security breach. "On 10 August 2009, Wired magazine reported that more than half of the top websites used local shared objects to track users and store information about them but only four of them mentioned it in their privacy policy." http://en.wikipedia.org/wiki/Local_Shared_Object You can delete them with options in Flash and you can refuse them by deactivating Flash. Since you use Firefox, an easy way to handle LSO (view, delete, automatic delete etc.) is Firefox add-on BetterPrivacy. Your OpenVPN client works at a lower layer than http and https. It encrypts all your outgoing packets up to Air servers, and all your incoming packets from the server to you. Just like with any higher-layer operating protocol, http and https usage depends on you and the destination website, not on the VPN. For example, let's say that you connect to an Air server, and then to an http website which does not offer https. The data exchanged by you with the website are encrypted between you and the Air server. They remain encrypted between the server and you, so that your ISP (and anybody between you and Air servers) can't see them (neither the real header nor the payload). Once/when the http packets are out on the Internet (out of the VPN, that is), they are NOT encrypted but they never have your IP address. Kind regards

Hello! Yes, that can be the cause: the logs show a high packet loss. If the problem persists, please try a TCP connection, or tune your OpenVPN client, for example with mssfix. Please see here for details: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=4853&limit=6&limitstart=12&Itemid=142#4957 If you suffer significant performance loss with a TCP connection, then it's worth trying the above on an UDP connection. You can insert the directives directly in the .ovpn configuration file (anywhere). In this case you will have to use OpenVPN, not the Air client. Please feel free to keep us updated. Kind regards

Hello! Please re-read, you have been given all the elements on how such attacks have the chance to be successful. In particular, to achieve the scope the adversary, in addition to regularly signed certificates, needs to block TOR or increase significantly the probability that the circuit is established with nodes controlled by the attacker (see the previous message for more details). The purpose of the previously mentioned attacks are the opposite, that is intercepting the traffic to the real website: the hi-jacking may be only at the login page, which may be absolutely necessary in order to allow (only if needed) the correct "interfacing" with the victim toward the real website. After that all the victim traffic comes and goes to the real website. On the victim side, the outgoing traffic is encrypted with the keys already known by the interface, which decrypts the victim traffic, re-encrypts it and sends it to the real website. On the victim inbound flow, the interface decrypts the traffic from the real website (in this phase, if it is wished, packet injections/packet forging are performed) re-encrypts it with the previous keys and sends it to the victim. It is a very similar thing which can be performed in corporate environments to check the payload of https traffic, for which vInspector has been designed, with the difference that in corporate environments certificates don't need to be properly signed or stolen. Also (this is just out of curiosity), it is similar to what currently performed by some malicious TOR relays. Currently there are: - 1 known exit node which performs MITM of SSL attack; - 1 known exit node which performs MITM of SSL attack with self-signed certificate; - 1 known exit node which performs MITM of SSL attack with a Fortinet certificate; - 1 known exit node which performs MITM of SSL attack with Kaspersky AV antivirus certificates https://trac.torproject.org/projects/tor/wiki/doc/badRelays Absolutely not, this is not a fault of the original website (for example Google), which suffered no security breach. In the example the security breach was in a CA website, but in the given links (for example in the Wikipedia article and in its references) you can see how it is possible to do that without even breaching the security of the sites of an authority. Aobut all the rest, you are confusing two different threads so you are making assumptions on what admin wrote which are not true. Kind regards

Hello! You have confused two different threads, you're mixing up this one with "What's the point of VPN over TOR?". Kind regards

The link does not work. And I strongly suspect this is rubbish to the nth power. The traffic is encrypted and cannot be parsed in plain text. I have never heard or read of anything bypassing strong encryption. This is fanciful nonsense. Hello! You can imagine a situation where a citizen is "locked in a cage": the adversary must have the ability to poison the victim DNS and propose alternative (or stolen) SSL certificates which "look like" the original site. The victim is led to believe that he/she is not in a such a "caged" network and that the certificates he/she receives from the https websites are not fake. With the device advertised in the tvhawaii's link, the adversary can more easily succeed in its attack, because the device acts as a gateway to the real https website and sends fluidly (quickly enough so that the victim can't notice any suspect lag) the real pages of the site the victim connects to. Each vInspector devices is advertised as capable to handle up to 3.5 Gbit/s SSL throughput. Actually, this admin has had direct experience that this method has been repeatedly used by human rights hostile governments in order to capture and "decrypt" the traffic of their citizens to/from https websites, including GMail and Facebook. Kind regards I followed the link from https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5149&limit=6&limitstart=12&Itemid=142 to see the evidence and I cannot see it. As for the argument above, this is an entirely different animal altogether and can apply to any service or website. This is not applicable only to Tor and never has been. The original poster never meant his words to mean what you wrote above. The ISP cannot sniff the traffic under normal circumstances. No one disputes the ability of a strong opponent to do what you describe above but this goes beyond decrypting encrypted data. I fail to see the connection to Tor alone. Thank you Hello! About the link provided by tvhawaii, it works, please check it out. About the required evidence on how it has been possible to successfully attack a target and decrypt the victim's traffic even with https-only websites, it is this admin's direct experience. Some of these events (but not all) have been anyway widely documented, for example: http://www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail In these types of attacks, the device advertised in the link provided by tvhawaii is indeed useful and can help the attacker, because the attacker obviously does not want to reproduce the victim website in its entirety, but does want that the victim connects finally to the real website without getting warnings from his/her browser. Assuming that the victim does not have from a trusted source the SH1 and MD5 certificate fingerprints and/or does not check manually them (the manual check is necessary because the browser will not issue any warning, being the certificate "trusted" for the browser), the attacker has been able to decrypt all the victim's https traffic to and from https websites while the victim was believing that his/her traffic was securely encrypted. Using vInspector or similar products is an additional comfort for the attacker and adds some more "nice" options, such as real time de-cryption and re-encryption of the https website pages accessed by the victims, de-cryption and re-encryption of the data the victims send to those sites, injections on the fly. Wikipedia has a short but nice article about the huge problem with SSL certificates emitted by CA authorities, their intrinsic weaknesses, some examples on how to perform a successful attack and some more references to notable attacks in the past which were successful: http://en.wikipedia.org/wiki/Certificate_authority The vulnerabilities can be greatly mitigated with OpenVPN, because once the connection is established toward servers which present certificates not subjected to subversion, the attack basis is no more available to the attacker. Therefore the attacker must face the new problem to hi-jack the victim without having the victim in the cage anymore. While this cage might still work with TOR (working in the cage so that a circuit either can not be established or it has high probability to be established only with relays and exit nodes controlled by the attacker), a VPN with non public entry-IP addresses is much more difficult to block. Currently the only solution to the attacker (as far as we know, of course) is just to disrupt OpenVPN connections completely (without disrupting SSL/TLS connections, because the attacker wishes that the victim remains able to connect to https websites), which can be achieved for the typical fingerprint of OpenVPN handshake, which is uniquely recognizable with DPI (we are working to try to bypass this limitation because this method is currently applied at least in Syria, Iran and intermittently in vast areas of China). About the "normal circumstances" you cite, it would help that you define what these normal circumstances are, and anyway it can be a dangerous mistake to assume that such circumstances surely apply to tvhawaii or any other person. Kind regards

Hello! The logs are just fine and yes, what you see is exactly how it works. When you use an application not configured to be tunneled over TOR, you will tunnel it over AirVPN over TOR transparently. On the Internet "you will be visible" with the exit-IP of the Air server the TOR exit-node sends to and receive from the packets. When you use a program that is configured to be tunneled over TOR, you will tunnel it either over TOR alone (if it connects over the same proxy OpenVPN connects over as well, apparently your case) or over TOR over AirVPN over TOR (if you tunnel it over a different TOR proxy). In all the above cases, your real IP address is never known to our servers. So, to tunnel over Air over TOR, you need to use a browser NOT configured for TOR. In order to tunnel over TOR over Air over TOR, you need a browser configured to be tunneled over TOR which connects over a different TOR proxy. You can easily do that for example in a VM. In this way, when using the TOR browser in the VM, you will tunnel it over TOR over Air over TOR and you will be visible on the Internet with the Air server exit-IP address. In this case our servers will be able neither to see your real IP address, nor your "real" encapsulated packet headers nor your packets payload. In general the second circuit of your TOR browser in the VM will be different from the first, established circuit "used" by your OpenVPN client. Kind regards

Hello! You need to start OpenVPN as a daemon in client mode. At the boot OpenVPN will read your configuration file you specify and thus connect to one of our servers. Please see here for one of the possible working configurations: http://ubuntuforums.org/showthread.php?t=1627920 You don't need to worry about login/password. The authentication is performed through certificates and key, therefore no human intervention or any other setup is needed at the connection. With the configuration generator (menu "Member Area"->"Access without our client") you can generate and download all the files you need. Kind regards

Hello! It depends if you route the DNS queries inside or outside the tunnel. In the first case your ISP DNS servers will receive the queries from our VPN servers, thus preventing any privacy breach. In the second case, you would be sending out unencrypted DNS queries directly to your ISP DNS servers (this is commonly named "DNS leak"), so your ISP (and any other entity that potentially monitors your connection) can see them. DNS queries are used for domain names resolutions, therefore your ISP can't see anyway any other packet payload, and can't see the files that you share via p2p. It can however see which hosts you connect to, each time your system performs a resolution for a hostname not included in hosts. We recommend that you solve the issue if your system is leaking DNS queries. In order to determine if it's the case, can you please tell us your OS and the client you're using? Kind regards

Hello! It's in menu "Member Area"-->"Access without our client", direct link: https://airvpn.org/direct_access Instructions for Windows are here: https://airvpn.org/windows Kind regards

Hello! Thank you for your inquiry. Under a technical point of view, you can find some information on the FAQ, while this admin will leave to customers and users comments and reviews about p2p performance on different servers and from different locations. p2p is allowed on all servers. p2p is allowed on all servers. Anyway, you will be able to access Pandora and some other USA geo-discriminatory services even from non-USA servers. We'll launch soon (a matter of days, indeed) this additional service. Please see the FAQ for exhaustive explanation on that. https://airvpn.org/faq In order to see servers availability and information: https://airvpn.org/status Kind regards

Hello! The hardware check is over and no faults have been found in the hardware. Therefore, the reasons of the crashes remain unfortunately unexplained at the moment. We have brought the server up again and we'll investigate the issue further. Kind regards

Hello! Can you please try a connection over the TOR proxy directly with OpenVPN (i.e. not using the Air client)? You can generate the appropriate configuration and get certificates and key with the configuration generator. Kind regards

Hello! Can you please make sure that you have selected a TCP port (the proxy can't handle UDP) and that the proxy type (http or socks) is correct? Kind regards

Hello! Your current setup already provides a very robust anonymity layer. You can restrict the TOR exit node for which a circuit is established. However, narrowing down the possible exit-nodes might or might not lower the anonymity and/or the security layer, you should evaluate that. Some links: http://www.wilderssecurity.com/showthread.php?t=311501 http://www.ghacks.net/2008/01/29/configure-tor-to-use-a-specific-country-as-an-exit-node/ Just in case you estimate that the above restriction is necessary but potentially dangerous for you, you might evaluate AirVPN over TOR as a replacement of your current TOR over OpenVPN setup, in order not to allow the few exit nodes you'll be going to use to see your traffic and real packets origins and destinations. https://airvpn.org/tor In the vision of a "connection as secure and anonymous as possible", if performance has not high priority you can also consider to: - connect over OpenVPN over TOR in a host machine - connect over TOR from a VM, in order to have TOR over AirVPN over TOR in your VM If performance has higher priority, but anyway you want to harden your anonymity layer (if for any reason you can't allow yourself to trust only our servers), you may consider OpenVPN over OpenVPN (however, you'll need two accounts to do that): - connect over OpenVPN in a host machine - connect over OpenVPN in a virtual machine toward a different Air server OR a competitor VPN service server, so that in the VM you will have a connection over OpenVPN over OpenVPN, which is generally much faster than [TOR over] OpenVPN over TOR Just search for "MAC spoofing". Anyway, you should ask yourself whether you really need that. The MAC address of your computer card never gets out of your LAN (it's just not a part of the network layer so the MAC address of your computer network card is visible only to your router and the devices inside your LAN). See here for some more information: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5303&Itemid=142#5306 Kind regards

@HorseClaws Hello! Outbound port 25 is blocked to prevent spam. This is the only non-neutral constraint on our servers, it is absolutely necessary because spamming would cause a quick blacklisting of all of our IP addresses. The solution is quite straightforward, just use a different port and use SMPT over SSL or other forms of encryption/authentication. Clear text SMTP handshaking and mail sending must be avoided at all costs in any case. Kind regards Hello! If your ISP SMTP server does not accept connections from IP addresses outside its own IP range even if you have a valid account with it, you are forced either to disconnect from the VPN each time you send the e-mail (very annoying) or just find another mail provider that does not impose such (perhaps idiotic) restrictions. Kind regards

Hello! Phoenicis has "badly" crashed three time in 7 days. The datacenter technicians will therefore perform a full hardware check in order to try to detect the problem. The hardware check will take at least 6 hours, and the downtime will be even longer if some parts will have to be replaced. We will keep you informed. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the Netherlands is available: Lyncis. 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 "Member Area"->"Access without our client"). The server accepts connections on ports 53, 80 and 443 UDP and TCP. 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 admins

Hello! As far as we can see, the maximum supported throughput (to encrypt and decrypt AES-256 on the fly) by the E2000 CPU is 7 Mbit/s. So the performance you detect is probably fine for the routers capabilities. You can try a connection directly from your computer to make a comparison. Kind regards

Hello! This is your own personal vision of practicability. Our vision is meeting our customers and users requirements. We have been asked how to hide the IP address of a client to our own servers, and an answer is OpenVPN over TOR, not TOR over OpenVPN. We have been asked how to hide the IP address of a client AND the payload contents of the clients packets to our own servers, and the answer is again OpenVPN over TOR, not TOR over OpenVPN. When you tunnel over TOR over OpenVPN, there's nothing more you can do, our servers will see your real IP address. When you tunnel over OpenVPN over TOR, you have plenty of chances to hide your traffic to our servers as well (just to make an example, with TOR over OpenVPN over TOR: you connect a host machine over OpenVPN over TOR, and you connect a guest machine over TOR, so from the VM you have TOR over OpenVPN over TOR). Actually, when life or personal freedom is at stake, our users don't mind about performance. If they have to send out highly sensitive data (for example for whistleblowing or to document brutality of an oppressive regime) it's a fact that they don't care whether it will take 10 hours instead of 1 minute. We just offer all the available options, then it's up to the user to decide which one to follow according to the power of his/her adversary or adversaries, but it's important that there's no confusing information about that, it must be very clear that TOR over OpenVPN does NOT meet the requirement to hide simultaneously the client real IP address and the traffic payload to our servers. This is a very Western-like point of view which does not take into account how an "anonymous" activist works and what he/she really needs. Actually, performance is not a problem up to the point that the most careful persons go even further, chaining OpenVPN over TOR over another VPN over proxy etc. This can be easily done following the most basic security rule, separate accounts and routes for separate activities. The price in terms of performance hit is totally irrelevant. That's quite obvious, because if you tunnel Bitcoin over TOR, it does not matter the the TOR exit node will come to know your transaction, because when you obtain the code and use it to activate any account you wish in our https website (always over TOR, to hide the IP address to our website) you solve automatically the two problems: it's irrelevant that the TOR exit node is compromised/malicious AND the correlation between the Bitcoin payment and an account in Air is destroyed. The importance of their posts is their reproducibility, just like with any scientific inquiry. Run your own TOR exit node and you'll be able to reproduce those results. This is argument has been partially faced in another thread: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5317&Itemid=142 In general, if you are not "caged" and you can entirely trust an SSL certificate, then you're safe, but that's not always the case (and we go back to the discussion about vInspector and similar products). The real and successful attacks performed by hostile entities are numerous and we can come back to them when possible. I do not think your first sentence is entirely accurate, on various levels. The second sentence is true—if it were true, but you need evidence to buttress it. You have just to consider all the stolen SSL certificates in real cases in the past (for example the Comodo affair http://techblog.avira.com/2011/03/24/stolen-ssl-certificates/en/ ) to have some significant examples and ideas about how it was possible that such attacks were successful. It is indeed a real world scenario and the argument is exactly on this point. Feel free to start a poll, although there might be a bias due to users who don't care or don't have the time to answer about that. Most of the demands for hardening the anonymity layer through partition of trust (in order to hide IP address and traffic to our own servers) come from citizens living in human rights hostile countries. It's not a setup really necessary to file sharers, for example. In addition, you can use two different accounts, only one of them connects over OpenVPN over TOR every and each time. Kind regards