Staff

Yes, if you can do that you might give us some useful information for troubleshooting. We will anyway try to reproduce your problem if you can't do that. Basically TCP protects against some replay attacks on top of OpenVPN protection, while with UDP the replay attacks are defeated with OpenVPN replay-protection sliding-window and time window, besides HMAC authentication. https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3773&Itemid=142#3784 Kind regards

Hello! Actually not, no particular problem is displayed in them before the credentials rejection. What happens with a connection over a TCP port? Kind regards

Hello! You're right, under a performance point of view UDP is better. Please see here for more information: https://airvpn.org/faq#udp_vs_tcp Kind regards

Hello! Thank you for the information. If you try a connection over a TCP port do you have the same problem? Kind regards

Hello! In the last 28 minutes your account has never connected and has tried no connections. If you tried the connection during this time window, can you please send us the Viscosity logs? Kind regards

Hello! We're looking into this. Did it start to happen to you since yesterday? Kind regards

Hello! Were you using different devices? Kind regards

Hello! Your account is currently connected and exchanging data. Please let us know at your convenience if the issue is solved. Kind regards

Hello! Normally you don't need to change any setting (but you might like to see anyway how to optimize p2p performance here: https://airvpn.org/faq#p2p ). For additional security you can perform the following test while you are connected to the VPN: http://checkmytorrentip.com Finally, you can consider to secure your connection against leaks in case of unexpected VPN disconnection. According to your system please see the guides that are linked in the announcement section of the forum. https://airvpn.org/forums Kind regards

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