Staff

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

The fact remains when a connection is made to a server, the login credentials must be authenticated and the user's IP be visible in order to process the connection. Yes, this information is not "recorded" but it is visible--and it has to be. So in the final analysis, if a strong opponent comes after you (a government warrant), this "visible" information will be recorded and used against you. No, that's plainly false. If you connect over Air over TOR, our servers see the TOR exit-node IP address. We don't perform authentication on an IP basis and we our servers don't block connections from TOR exit nodes. Please see here: http://www.zoklet.net/bbs/showthread.php?t=99012 Nodes like that are not uncommon and it's very easy to run them and sniff all the traffic. Sites which allow non-https connections are very many. Even Yahoo and Facebook do not force https (and GMail forced it only recently) and for the experience of this admin even activists living in human rights hostile countries make those mistakes, which are fatal in social networks and e-mail web wrappers sites. The guy in the above thread was able to discover some interesting things and passwords, and a government can do much more. Unfortunately the evidence shows the contrary. Even e-mails of chinese people (who surely have a lot to fear from their government) could be sniffed in the above example. So you confirm that partition of trust is very necessary when someone deals with critical activities for which identity disclosure causes direct harm to physical safety and personal freedom. Look deep into darknets and specialized forums, you will discover a lot of interesting things. The above link was just an example. In real life, anonymity is not unlinked from privacy. The correlations you can perform when you control a significant portion of the TOR network may well lead to identity disclosure So the fact remains that the VPN can see your IP--and in truth, it has to, in order to connect to the server and to forward the IP packets. No, that's plainly false. If you pay with Bitcoin and you use the code to activate an account with a configuration to connect over Air over TOR, our servers NEVER come to know neither your identity nor your real IP address. If you forget to run the TOR proxy the OpenVPN client will not even reach any of our servers. On the contrary, if you use TOR over Air, our servers can see your real IP address. So one solution or the other is to be decided on a case by case basis, according to the adversary you have to face. They are two different partitions of trust. But "keep" does not mean it cannot be seen. And in truth, it has to be seen to authenticate the user. But the larger point here is this: if compelled to by a government, all users can be identified by their login credentials and their IPs. Connecting to Tor first to "hide" an IP from the VPN would be senseless since the authorities would already have identified you by the credentials and the IPs recorded. By exiting out of Tor, neither the authorties nor the VPN operator can know your destination. If the authorties come after you, for whatever reason, and they see you exited out of Tor--it is by magnitudes more difficult to be identified than if you exit out of a VPN server. No, again this is false, see above. With the specified setup, we NEVER know neither the identity nor the IP address of the customer, so we can't disclose those information, not even if we had a gun pointed to our head. Those information could not be discovered not even if one of our servers was monitored in real time. Kind regards

Hello! With the due respect, are you joking? First of all we're not in the USA, second and more importantly we don't turn on logging because "an USA individual" asks us to. Kind regards

Hello! Thank you for the nice discussion. Absolutely not: Air has been designed exactly with the purpose to leave the option to customers to NOT allow the admins to know the identity from the login credentials. It is well explained in the link given in the previous post: if you buy a code with Bitcoin from an independent reseller and you connect over TOR, there's no way in this world that Air admins can get to know your identity. Unfortunately not. If you use only TOR, you anyway need to trust: - that the exit node is not malicious or compromised; - that your adversary does not control the relevant portion of the TOR network you connect to. Control over the TOR network is possible by an adversary with enough power (for example a well determined government which controls the ISPs and the border routers). Bypassing the trust on one single party requires partition of trust. So, with VPN over TOR you defeat a malicious exit node and an adversary which has the power to control your line AND (the Air server you connect to OR the relevant portion of the TOR network). With TOR over VPN, you can't defeat this type of adversary and you don't defeat a malicious exit node. 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

Hello! It's not possible to decrypt the packets you send to the VPN server and the packets you receive from the VPN server (not even by someone who's monitoring your line), except by your client. The device you link is meant to decrypt and re-encrypt SSL traffic for which it has already all the keys. This can be obtained in corporate environments or with malicious means, to which an OpenVPN hardened security based VPN is not vulnerable. To have a closer hint on how these devices work: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65123 EDIT If you're curious to see the strength of AES (Air data channel is encrypted with AES-256-CBC): http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks The fastest known attack against AES-256 requires 2^254 operations for key discovery... and OpenVPN executes TLS re-keying every 60 minutes. Kind regards

Hello! That's the whole point. An account used for critical activities for which the account holder does not want to let VPN administrators know its real IP address must always connect over the VPN over TOR. It's not difficult at all (once you have configured OpenVPN or our client to use a TOR proxy, OpenVPN will not even connect if you forget to run the proxy) and a careful person will always do that, or use separate accounts for separate activities. In our case, we are unable to correlate because we don't keep logs. But if a server is monitored in real time by an hostile entity, here you can see the great advantage of VPN over TOR. You can defeat an adversary even if it can monitor YOUR line AND VPN servers lines simultaneously, and this is a huge, really enormous benefit. Anyway, this sends us back to partition of trust. We have repeatedly been talking about the strong advantages of Air over TOR in order to perform partition of trust when absolutely necessary: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Obviously partition of trust can be performed with any other socks or http proxy, or with VPN over VPN (for example just running a client in a host machine and another client which connects to a different server in a VM), TOR is just a significant example which gives some notable advantages (for example in TOR Browser Bundle you find a customized browser perfectly prepared to mitigate any privacy assault). It all depends on which adversary you have to face. A file sharer adversary is completely different from the adversary in human rights hostile countries. Kind regards