Torrent Freaks updated VPN 2014 list with Q&A

Interesting read with updated questions asked for the top VPN providers.

http://torrentfreak.com/which-vpn-services-take-your-anonymity-seriously-2014-edition-140315/

I noticed an answer from PrivatVPN

'5. If we get a court order to monitor a specific IP then we need to do it, and this applies to every VPN company out there'

every VPN company out there

Sounds a bit strange considering all the other VPN providers said we don't log so no info anyhow on the same question!

 

This raised my eyebrows.

"I worked for Astrill so I can tell you the claims attributed to them on that page are mostly ********.

1) We do not keep logs

Reality) False. They do keep logs. With reguard to http traffic, they log every single single page loaded for every customer using their VPN servers. They log your account number, the requested url, the time of the request. This information is kept for months at a time and then thrown into a journal system."

etc.


http://www.reddit.com/r/technology/comments/20k0i0/which_vpn_services_take_your_anonymity_seriously/

 

interesting info, no doubt some of them are fibbing just to show they are as good as others!

also Airvpn has recently updated that article with there own answers.

 

Pasted below is Air's response forwarded directly to them and discussed over on their forums:

This is the text we sent to TorrentFreak a few minutes ago:

(posted by Air Staff)



Hello Ernesto and thank you for your inquiry.



1. No, we don't keep any log that might be exploited to reveal customers' personal data during connections, including real IP address. For example OpenVPN logs are sent to /dev/null (Air is based on OpenVPN). Our privacy policy is available here: https://airvpn.org/privacy



On top of that our VPN servers do not maintain any account database.



2. Italy. We do not share any information with any 3rd party.



3. Automatic triggering based on patterns to detect and if possible block as soon as possible various types of attacks (for example UDP floods) against or from our servers.



4. They are ignored. Now and then we reply asking for a more substantiated proof and asking to disclose the technical method according to which a takedown notice has been prepared, but so far none of the entities we queried disclosed such information, in absence of which the notices pertaining to p2p are simply vague and unproven claims from some private entity.



5. No help can be given about past connections because we don't log, monitor or inspect our clients traffic, and we don't and can't require a proof of identity from our customers. However, if the court order pertains to presumed actions which infringe our Terms of Service and in particular that in any way violate, directly or indirectly, or aid the violation of, the ECHR, we can try to help the court in the best way we can with subsequent investigations and if possible with the help of proper and competent authorities.



6. Yes. p2p protocols are perhaps a set of the most exciting protocols invented in the last 12-13 years, so they are actively encouraged on every server. We do not discriminate against any application or protocol, in compliance with our mission and to stay a mere conduit of data.



7. We accept Bitcoin, many credit cards, PayPal. Each payment is linked to an account only in order to provide service delivery and to comply to our refund policy.



8. First of all it is mandatory that the key exchange is not exploitable. Even the strongest encryption is useless if the key exchange is flawed.



In light of the most recent releases about how NSA attacks VPNs and VoIP, it is essential that you pick a service which relies on ephemeral key exchange, that correctly implements Perfect Forward Secrecy and that correctly implements a robust key exchange procedure.



That's not trivial: for example H.323 VoIP protocol could be "broken" by NSA and other entities because, even though it employs DHE, which is a very wise choice, the implementation is wrong: vendors skip the TLS/etc. encryption of the signaling channel and the Diffie-Helmann keys are unprotected.



Finally (and this might be a surprise for some people) we would not recommend ECC (Elliptic Curve Cryptography) at the moment.



We momentarily avoid ECC (Elliptic Curve Cryptography) in Control Channel, Data Channel and in key exchange, according to Bruce Schneier's suggestions and keeping into account reasonable suspects of deliberate poisoning and weakening of ECC (with possible backdoors) by NSA in cooperation with industry.



We put into practice the recommendations of security expert and best practices on our setup, based exclusively on OpenVPN with the following features:



Data Channel: AES-256-CBC

Control Channel: HMAC SHA1

RSA keys size: 2048 bit

PFS (Perfect Forward Secrecy): yes. TLS re-keying is performed by default every 60 minutes through DHE as well as at each new connection. As an additional option the re-keying time interval can be lowered by the client unilaterally.



The client key is used to authorize the access to the system, not to encrypt the data channel, so that even if an adversary catches the client private key, the client traffic can't be decrypted.



Kind regards

Paolo Brini
AirVPN co-founder

 

There's an important distinction that tends to get lost in the "we don't log" contest.

Say that you're a VPN service provider. Unless you're self hosting, and somehow anonymously stealing an Internet uplink, you have providers, and they have providers, and so on. Everyone needs to keep their providers happy, or they lose whatever's being provided. Right?

If one of your users is up to something that generates grief upstream, and it gets back to you, you need to deal with it. At one extreme, you could change providers, or move to a different country. Or you could go out of business. But those options would generally involve considerable money (or loss thereof) and/or effort. At the other extreme, you could block the "abuse", investigate, and then cut off the offending user.

However, before you can decide how to proceed, you need to understand the situation. And logging traffic will very likely play a role in that. Even so, it's possible to carry out such logging and analysis in remote VMs that run entirely in RAM. Once you've taken the necessary actions, all logs and analysis are gone.

A better approach is to automatically block grief-creating activities. If users don't like your service, they'll switch to another. Everybody's happy

 

I appreciate the way BolehVPN handles it, its why I'm a long time subscriber. Its nice that they are also very open with their practices of turning on logging for a few hours very rarely to remove negative users from the service, no law enforcement no DMCA or court orders. Its a form of self policing I really appreciate due to the fact that the worst can be done to a user/subscriber is losing the privilege to be on the service anymore.

 

I totally agree.

When you're using a VPN service, it's rather like you're a guest in their club, or whatever. Doing things that get your host in trouble is disrespectful.

Just to be clear, I'm not saying that VPN providers should ever compromise their clients' identities.

 

Neither am I, but when one of your masked guests is doing cocaine off of a rhinoceroses back its probably best for everyone else to ask them to leave politely.

 

Those are some great points to be made. Handling "grief" properly instills confidence. Those methods are mostly good only for one hop members. On the other hand if multiple hops are used the "grief" would move upstream too.

 

Right. If you're chaining VPNs, and create enough grief for the final exit VPN, they can just nuke your account. If you keep trying with new accounts, they can block all entry traffic from the VPN that you're using to reach their entry. If you keep trying to reach their entry via new VPNs, they can just block them too. And much of that blocking can be totally automatic. pfSense can do that too

It's very different with Tor, because (1) there's no way to reliably define a particular user, (2) no way to reliably associate activity (including grief) with a particular user, (3) no way to block a particular user, and (4) no way to block particular sorts of grief, except by blocking associated ports.

However, it's very easy for Internet sites to block Tor exits, and many do. Even worse, as more and more sites use CloudFront and similar services, such blocking can simultaneously prevent (or at least impede) access to many sites.

You can circumvent Tor-exit blocks by using VPNs via Tor, but then you're back at the first paragraph

 

Its the kill switch which concerns me with these VPN providers.....

I guess one could MacGyver a plan, put yanking the power plug before 8 guys go wrestlemania on you is not ideal either.

 

For certain things there is nothing like TOR!!

 

If that's an issue, use Tor

Drama aside, friends that would die for you are hard to find (outside military, anyway)

 

Very true I always use Whonix under the right setup

 

Thanks for your support

We've also recently implemented some firewall rules in some problematic servers that would prevent certain types of abuse (mostly in the DoS category). This reduces the need to turn on logs since hopefully the DoS is mitigated/blocked at the firewall level.

 

Ahh, Netherlands Fully-Routed was one of these? I was having problems that could be explained by DoS'ing which have recently gone away and everything works fine now.

Thanks, Reuben.