Staff

Hello! https://duckduckgo.com/?q=how+to+encrypt+non-system+hdd+with+truecrypt Kind regards

@superameise @NaDre It's very puzzling. There is a key information missing, and source-code-closeness does not help, that is how uTorrent IP binding works? If uTorrent is firewalled, how come that the checkmytorrentip tracker gets the ISP IPv4 address of superameise's device? If everything stated is true, the only explanation that comes to mind is that uTorrent announces to the tracker the ISP IP address, but how? We know that this can happen when connecting uTorrent to a proxy (https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea) but this situation seems completely different. First of all, however, it would be important to replicate the problem. Without certain reproducibility under controlled conditions, it's problematic even to contact uTorrent community. @superameise Just an additional information, does your ISP IP address is diplayed in any of your network cards (if in doubt type ipconfig /all from a command prompt), or is the system which runs uTorent behind a router NAT? Also, can you please check carefully if there's any value into the "IP/Hostname to report to tracker" uTorrent field? Kind regards

Hello! Yes: you need to remotely forward a port for your account (menu "Client Area"->"Forwarded Ports"). You can't forward ports lower than 2049. You can't have two different processes (running at the same time) listen to the same port (it would be a process end-point fatal ambiguity on the system). Please consult the relevant FAQs on ports and p2p for additional information. Kind regards

@Royee Not exactly, partition of trust and all the discussed topic refer to the trust that you put on us. If you can't afford to trust us, or even if you can trust us but you can't afford to trust the datacenter personnel our servers are in (*), you have the tools to strengthen the anonymity layer. About the backend servers, it's another topic, although you're right that it's actually related, and it is important as well, because in this way we do not keep any account data, including user keys, on any VPN server, and above all we can in this way keep location of the clustered database totally private and unknown to anyone, which is also an additional protection against a wide range of attacks. (*) When we founded AirVPN we thought about how the anonymity layer of a person in need to disseminate information on organized crime, or the anonymity layer of a whistleblower, could be protected even from ourselves, so that those persons were not forced to trust blindly a single entity. Kind regards

Hello! The "No route to host", code 65, may be caused by a line drop or a null-routing of the destination IP address or a firewall in your system that drops packets (for example when it sees "too much" UDP flow). Please see here (about Tunnelblick): http://code.google.com/p/tunnelblick/issues/detail?id=120 and here (about SparkLabs Viscosity): http://www.sparklabs.com/forum/viewtopic.php?f=3&t=1227 We can't verify the logs on the server side because OpenVPN logs are sent to /dev/null according to our policy. Try to connect to a TCP port to see whether the problem gets solved or not, which may be a precious hint. Kind regards

Hello, because the traffic is still encrypted by your OpenVPN 'client' when it passes through the TOR nodes. It is decrypted by our VPN server and then sent out on the Internet. Remember that OpenVPN has the ability to connect to a VPN server over a socks or an http proxy. Example for outgoing packets: your cleartext packets headers and payloads are encrypted and then encapsulated in TCP or UDP by your OpenVPN. Before getting out of your system, they are again encrypted and encapsulated by TOR. When they reach the TOR exit-node, only the encryption layer by TOR is no more. The OpenVPN encryption is still there. See above. Yes, this the solution. It introduces other problems (see http://forum.dee.su/topic/vpn-tor-more-anonymity) so you must evaluate the purpose of this solution. The main purposes are solving the TOR exit-node problem you cited, hiding your IP address to our VPN servers (partition of trust, to defeat an adversary that's wiretapping a VPN server) and hiding to the final node (but not to your ISP!) the fact that you're using TOR. Additionally, this is a "starting point" for more sophisticated forms of partition of trust. Imagine for example to connect a host over OpenVPN over TOR. Then run a Virtual Machine in that same host and connect to a VPN service, or to TOR, or to another proxy, that VM (itself connected via NAT to the host machine). You will have an additional partition of trust which might be desirable in extremely critical data transfer, when low performance is considered an acceptable price to pay. Kind regards

Hello, side note: in 2010, when AirVPN was being born, we discarded PPTP (that was an obvious choice) and after a careful evaluation we picked OpenVPN and discarded IPsec as well. There are even additional considerations about IPsec, on top of those that you have kindly reported, which convinced us to prefer OpenVPN. Kind regards

Hello! Please see the above link on partition of trust. Even if we said (and beware, we're not claiming that) that this can't happen with our system and our providers, you would anyway have to trust us and we would anyway have to trust our provider. With partition of trust, you distribute trust between N parties, so that if N-1 parties betray the trust, your anonymity layer is NOT compromised, effectively solving the trust problem in a drastic and effective way. We faced this problem in 2010, at the birth of AirVPN. Kind regards

Hello! It does not matter at all, just use lynx. Most of our site pages are perfectly readable in text mode. And the menus are perfectly selectable without a mouse and a pointer. Example: lynx https://airvpn.org/status No, it's the DNS record that is updated (if necessary). OpenVPN will not disconnect without a command from you. Yes, please generate a file with the remote-random directive in the following way: - click "Advanced Mode" - tick "Resolved hosts in .ovpn file" - tick "All servers for area or region" In this way a configuration file that will cause OpenVPN to rotate randomly (at each connection) between all the servers of the selected area will be generated (for this operation: yes, you will need a graphical environment - then upload the configuration to your server). Kind regards

Hello! No, it wouldn't be compromised. If someone in any way could get in possession of your user.key, it could NOT decrypt your tunneled traffic. See also https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet in order to know why. That said: PKCS#12 is not currently supported. Kind regards

Hello, thank you, unfortunately that web site requires registration to read the link you provided and currently registrations are closed, but we'll keep an eye on it just in case they re-open registrations. Kind regards

Hello! Yes, it's an additional encryption layer. Unnecessary as you said, if the magic of the attacker could decrypt OpenVPN ciphers before we're all dead, instead of million of years, the additional SSL would be no match as well. Kind regards

Let's continue here (this forum section is not the proper place, for clarity purposes): https://airvpn.org/topic/9958-importance-of-partition-of-trust-for-critical-data-exchanges Kind regards

Hello! Yes, only physical servers. Your report is important, what is the Dutch provider? Do you have any additional reference to the case? And of course nobody can be 100% sure that a sufficiently powerful entity wiretaps your machinery, regardless of any kind of service or provider, not even if you run your own datacenter. Encrypting the OS on the server is not a solution, because the adversary can put two boxes on incoming and outgoing connections and correlate any traffic flow simply through timing (similarly to any timing correlation attack in any low latency network). Also see the importance of partition of trust, strictly related to the issue (and capable to defeat the aforementioned adversary, provided that this adversary is not also capable to monitor at the same time the relevant TOR circuit you have established or the external service you have picked - an extremely low probability): https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Kind regards

Hello! We don't use VPS or cloud servers for our VPN servers. Kind regards

Hello, currently there are more than 300 VPN services out there that actually offer a low security service. Just think of PPTP with MS-CHAP v1 or MS-CHAP v2 or MPPE authentication: cracking it is relatively easy and does not even require NSA capabilities. Then think about VPN services that run OpenVPN configured in Static Key Authentication mode. Obtaining the static keys in any way (sometimes it might be enough to just ask...) would give immediate capability to decrypt all past (if captured), present and future data streams. So the alleged purpose does not seem unrealistic at all. Kind regards

Hello! You can't change your user.key on your own. Please feel free to open a ticket if you wish to do so. No, it's not planned for 2013 because it's not necessary (on top of that, OpenVPN 2, 2.1 and 2.2 do not support natively ECC). It would require a massive conversion of all of our clients for nothing: we don't use SHA1 for packet encryption or authentication. We use HMAC SHA1 for packet authentication, which is a totally different beast. In order to try to find hash collisions in an attempt to inject forged packets, an attacker should first break HMAC to reach the underlying hash algorithm. Kind regards

https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet Kind regards

Hello, we need to create a FAQ for this! In the meantime please see here: https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet/ Executive summary: the answer to your question is yes. Kind regards

@degas432 Yes, we're saying that, but we're saying even more. We're also saying that if (just to make bad science fiction, because all the elements point to the contrary) NSA could break the encryption for ONE of your keys AND discern AND capture the packets stream of a client for THAT key, it could decrypt ONLY the packets stream included in the time frame between two TLS re-keyings (see also on Wikipedia "Perfect Forward Secrecy"). An interesting discussion is here http://crypto.stackexchange.com/questions/579/how-can-we-reason-about-the-cryptographic-capabilities-of-code-breaking-agencies one paragraph of one of the posts is particularly worth to be quoted. It's one month old but it was prophetic in light of the most recent leaked documents: Reading the slides for PRISM the cost of the program is way too low to include any sort of computationally intensive pursuits. It's not a far leap to infer PRISM being a key sharing effort. Several accounts seem to indicate the NSA are actively subverting security on the standards level or in collusion with software developers. If either proposition is true, any serious cryptographer needs to use systems where every component is known and excludes closed source operating systems and software black boxes. One side note as a figurative example: being worried about NSA decrypting your one-hour AES-256 traffic while at the same time running Windows is like being worried exclusively about an asteroid hitting your head when you walk at night alone in San Pedro Sula while happily waving 10000 dollars in your hand. Kind regards

Hello! Actually we had never met this problem before (at least it was not in the knowledge base). As a coincidence, we had two more customers who had this very same problem with Windows 8 just a few hours ago, one of them solved it just with a TCP/IP stack and Winsock reset ( https://airvpn.org/topic/9946-no-connection-on-win-8-w-airvpn-client/ ). In order to perform the reset please see here: https://airvpn.org/topic/8320-solved-connects-but-ip-doesnt-change-on-windows-server-essentials-2012/?do=findComment&comment=8321 Kind regards

Hello! Yes, it's planned. You're correct, some servers are using that version. Some servers have been already updated to 6.0p1, which is the version in latest Debian stable, Wheezy, if we're not mistaken. We'll check with the relevant persons (access to VPN servers is restricted for security reasons, only Air founders have full access to them). Kind regards

Hello! You can't without interrupting OpenVPN. Install "screen", launch a screen and run OpenVPN from inside the screen. Detach the screen by pressing CTRL+A, then pressing D ("D"etach). You can resume the screen with screen -r You can see the screens list (you can open as many screen as you wish) with screen -ls See "man screen" to get full advantage of this powerful tool. Every 300 seconds the control system performs many measurements then inserts observed parameters (such as latency between every node in the designated area, available bandwidth, packet loss, servers status and more) in a formula which returns a score. The higher the score, the "healthier" the server is. The server with the highest score is the "best" server. The domain name record for that zone is then updated, if necessary, to resolve to the entry-IP address of that best server. TTL is 5 minutes. You can anytime see the best server for every area in the right tables of the servers monitor (click "Status" from the upper menu). A graceful kill is recommended. Do not kill the screen in which OpenVPN is running, because in that case OpenVPN would be prevented to notify our servers of the disconnection (causing a 60 seconds delay in account unlocking if the connection is over UDP: being UDP connectionless, the server has no way to acknowledge a disconnection, so it will consider the client disconnected only after the ping timeout). Additionally, a non graceful kill can prevent OpenVPN to restore your system previous routing table. You can gracefully kill OpenVPN with a simple kill command, or by pressing CTRL-C from inside the screen where OpenVPN is running. Kind regards

Hello! Please note that the VPN DNS servers IP addresses are wrong, the correct ones are: 10.4.0.1 10.5.0.1 Kind regards

Hello! It seems just fine, your name (which is not x.airdns.org, please check) correctly resolves to the exit-IP address of the server you're currently connected to (even with Google DNS). Kind regards