To prevent their IP-addresses from being visible to the rest of the Internet, millions of people have signed up to a VPN service. Using a VPN allows users to use the Internet anonymously and prevent snooping.

Unfortunately, not all VPN services are as anonymous as they claim.

Following a high-profile case of an individual using an ‘anonymous’ VPN service that turned out to be not so private, TorrentFreak decided to ask a selection of VPN services some tough questions.

By popular demand we now present the third iteration of our VPN services “logging” review. In addition to questions about logging policies we also asked VPN providers about their stance towards file-sharing traffic, and what they believe the most secure VPN is.

Last update: October 7, 2014 (added partial Russian translation)

—

1. Do you keep ANY logs which would allow you to match an IP-address and a time stamp to a user of your service? If so, exactly what information do you hold and for how long?

2. Under what jurisdictions does your company operate and under what exact circumstances will you share the information you hold with a 3rd party?

3. What tools are used to monitor and mitigate abuse of your service?

4. In the event you receive a DMCA takedown notice or European equivalent, how are these handled?

5. What steps are taken when a valid court order requires your company to identify an active user of your service?

6. Is BitTorrent and other file-sharing traffic allowed on all servers? If not, why?

7. Which payment systems do you use and how are these linked to individual user accounts?

8. What is the most secure VPN connection and encryption algorithm you would recommend to your users?

—

What follows is the list of responses from the VPN services, in their own words. Providers who didn’t answer our questions directly or failed by logging everything were excluded. Please note, however, that several VPN companies listed here do log to some extent. The order of the lists holds no value.

Private Internet Access

1. We absolutely do not log any traffic nor session data of any kind, period. We have worked hard to meticulously fork all daemons that we utilize in order to achieve this functionality. It is definitely not an easy task, and we are very proud of our development team for helping Private Internet Access to achieve this unique ability.

2. We operate out of the US which is one of the few, if only, countries without a mandatory data retention law. We explored several other jurisdictions with the help of our professional legal team, and the US is still ideal for privacy-based VPN services.

We severely scrutinize the validity of any and all legal information requests. That being said, since we do not hold any traffic nor session data, we are unable to provide any information to any third-party. Our commitment and mission to preserve privacy is second to none.

3. We do not monitor any traffic, period. We block IPs/ports as needed to mitigate abuse when we receive a valid abuse notification.

4. We do not host any content and are therefore unable to remove any of said content. Additionally, our mission is to preserve and restore privacy on the Internet and society. As such, since we do not log or monitor anything, we’re unable to identify any users of our service.

5. Once again, we do not log any traffic or session data. Additionally, unlike the EU and many other countries, our users are protected by legal definition. For this reason, we’re unable to identify any user of our service. Lastly, consumer protection laws exist in the US, unlike many other countries. We must abide by our advertised privacy policy.

6. We do not discriminate against any kind of traffic/protocol on any of our servers, period. We believe in a free, open, and uncensored internet.

7. Bitcoin, Ripple, PayPal, Google Play (Mobile), OKPay, CashU, Amazon and any major Gift Card. We support plenty of anonymous payment methods. For this reason, the highest risk users should definitely use Bitcoin, Ripple or a major gift card with an anonymous e-mail account when subscribing to our privacy service.

8. We’re the only provider to date that provides a plethora of encryption cipher options. We recommend, mostly, using AES-128, SHA1 and RSA2048.

Private Internet Access website

TorGuard

1. TorGuard does not store any IP address or time stamps on any VPN and proxy servers, not even for a second. Further, we do not store any logs or time stamps on user authentication servers connected to the VPN. In this way it is not even possible to match an external time stamp to a user that was simultaneously logged in. Because the VPN servers utilize a shared IP configuration, there can be hundreds of users sharing the same IP at any given moment further obfuscating the ability to single out any specific user on the network.

2. TorGuard is a privately owned company with parent ownership based in Nevis and our headquarters currently located in the US. Our legal representation at the moment is comfortable with the current corporate structuring however we wouldn’t hesitate to move all operations internationally should the ground shift beneath our feet. We now offer VPN access in 23+ countries worldwide and maintain all customer billing servers well outside US borders.

We would only be forced to communicate with a third-party in the event that our legal team received a court ordered subpoena to do so. This has yet to happen, however if it did we would proceed with complete transparency and further explain the nature of TorGuard’s shared VPN configuration. We have no logs to investigate, and thus no information to share.

3. Our network team uses commercial monitoring software with custom scripts to keep an eye on individual server load and service status/uptime so we can identify problems as fast as possible. If abuse reports are received from an upstream provider, we block it by employing various levels of filtering and global firewall rules to large clusters of servers. Instead of back tracing abuse by logging, our team mitigates things in real-time. We have a responsibility to provide fast, abuse-free VPN services for our clients and have perfected these methods over time.

4. In the event of receiving a DMCA notice, the request is immediately processed by our abuse team. Because it is impossible for us to locate which user on the server is actually responsible for the violation, we temporarily block the infringing server and apply global rules depending on the nature of the content and the server responsible. The system we use for filtering certain content is similar to keyword blocking but with much more accuracy. This ensures the content in question to no longer pass through the server and satisfies requirements from our bandwidth providers.

5. Due to the nature of shared VPN services and how our network is configured, it is not technically possible to effectively identity or single out one active user from a single IP address. If our legal department received a valid subpoena, we would proceed with complete transparency from day one. Our team is prepared to defend our client’s right to privacy to the fullest extent of the law.

6. BitTorrent is only allowed on select server locations. TorGuard now offers a variety of protocols like http/socks proxies, OpenVPN, SSH Tunnels, SSTP VPN and Stealth VPN (DPI Bypass), with each connection method serving a very specific purpose for usage. Since BitTorrent is largely bandwidth intensive, we do not encourage torrent usage on all servers. Locations that are optimized for torrent traffic include endpoints in: Canada, Netherlands, Iceland, Sweden, Romania, Russia and select servers in Hong Kong. This is a wide range of locations that works efficiently regardless of the continent you are trying to torrent from.

7. We currently accept payments through all forms of credit or debit card, PayPal, OKPAY, and Bitcoin. During checkout we may ask the user to verify a billing phone and address but this is simply to prevent credit card fraud, spammers, and keep the network running fast and clean. After payment it is possible to change this to something generic that offers more privacy. No VPN or Proxy usage can be linked back to a billing account due to the fact we hold absolutely no levels of logging on any one of our servers, not even timestamps!

8. For best security we advise clients to choose OpenVPN connections only, and if higher encryption is called for use AES256 bit. This option is available on many locations and offers excellent security without degrading performance. For those that are looking to defeat Deep Packet Inspection firewalls (DPI) like what is encountered in countries such as China or Iran, TorGuard offers “Stealth” VPN connections in the Netherlands, UK and Canada. Stealth connections feature OpenVPN obfuscation technology that causes VPN traffic to appear as regular connections, allowing VPN access even behind the most strict corporate wifi networks or government regulated ISPs.

TorGuard website

IPVanish

1. IPVanish has a no-log policy. We keep no traffic logs.

2. IPVanish is headquartered in the US and thus operates under US law.

3. IPVanish has no monitoring in place. To elaborate, IPVanish does not sniff or monitor any user’s traffic or activity for any reason.

4. IPVanish keeps no logs of any user’s activity and responds accordingly.

5. IPVanish, like every other company, has to follow the law in order to remain in business. Only US law applies.

6. P2P is permitted. IPVanish in fact does not block or throttle any ports, protocols, servers or any type of traffic whatsoever.

7. PayPal and all major credit cards are accepted. Payments and product use are in no way linked. User authentication and billing info are help on completely different and independent platforms.

8. OpenVPN generally provides the strongest encryption algorithm, so that is the recommended encryption protocol. IPVanish also allows a choice between TCP and UDP, and UDP is generally recommended for better speed.

IPVanish website

BTGuard

1. We do not keep any logs whatsoever.

2. The jurisdiction is Canada. Since we do not have log files, we have no information to share. We do not communicate with any third parties. The only event in which we would even communicate with a third-party is if we received a court order. We would then be forced to notify them we have no information. This has not happened yet.

3. If serious abuse is reported we enable tcpdump to confirm the abuse and locate the user. These dumps are immediately removed. If the user is abusing our service they will be terminated permanently but we have never shared user information with a 3rd party.

4. We do not have any open incoming ports, so it’s not possible for us to “takedown” any broadcasting content.

5. We take every step within the law to fight such an order.

6. Yes, all types of traffic our allowed with our services.

7. We accept PayPal and Bitcoin. All payments are linked to users accounts because they have to be for disputes and refunds.

8. 256-bit AES is the most secure. However 128-bit blowfish is plenty good. If you’re concerned about surveillance agencies such as the NSA, their capabilities are shrouded in secrecy and claiming to be able to protect you is offering you nothing but speculation. As far as what’s publicly available for deciphering encryption, both of the encryptions I mentioned are more than sufficient.

BTGuard website

Privacy.io

1. We do not log any information on our VPN servers. The only scenario is if a technical issue arises, but we request permission from the user first, and we only do it for the duration of the job, and then it is removed.

2. We are in the process of moving jurisdictions away from Australia at present as we are unsure what our current government plans to do in regards to our privacy. We have not decided where yet.

3. Only SMTP port 25 is filtered to mitigate spam, but we are working on some tools to make it easier for users to send mail.

4. Any DMCA request is ignored, as we have no logs to do anything about them.

5. Same as above, as we do not log, so we are unable to provide any information. If the law attempts to make us do such things, we will move our business to a location where that cannot occur, and if that fails we will close up shop before we provide any information.

6. All protocols are allowed with our service, with the only exception of SMTP port 25 currently being filtered.

7. At present we only accept PayPal and CC (processed by PayPal), but we are looking into alternative types of payments. We go out of our way to make sure that PayPal transactions are not linked to the users, we generate a unique key per transaction to verify payment for the account is made, and then nuke that unique key. Bitcoin and Litecoin are also on the agenda.

8. At present we offer 128 bit for PPTP and 256 bit for OpenVPN, We plan to offer stronger encryption for the security conscious.

Privacy.io website

VikingVPN

1. No. We run a zero knowledge network and are unable to tie a user to an IP address.

2. United States, they don’t have data retention laws, despite their draconian surveillance programs. The only information we share with anyone is billing information to our payment gateway. This can be anonymized by using a pre-paid anonymous card. If asked to share specific data about our users and their habits, we would be unable to do so, because we don’t have any logs of that data.

3. That is mostly confidential information. However, we can assure our users that we do not use logging to achieve this goal.

4. In the event of a DMCA notice, we send out the DMCA policy published on our website. We haven’t yet received a VALID DMCA notice.

5. We exhaust all legal options to protect our users. Failing that, we would provide all of our logs, which do not actually exist. If required to wiretap a user under a National Security Letter, we have a passively triggered Warrant Canary. We would also likely choose to shut down our service and put it up elsewhere.

6. Yes. Those ports are all open, and we have no data caps.

7. We currently only take credit cards. Our payment provider is far more restrictive than we ever imagined they would be. We’re still trying to change payment providers. Fortunately, by using a pre-paid credit card, you can still have totally anonymous service from us.

8. A strong handshake (either RSA-4096+ or a non-standard elliptic curve as the NIST curves are suspect). A strong cipher such as AES-256-CBC or AES-256-GCM encryption (NOT EDE MODE). At least SHA1 for data integrity checks. SHA2 and the newly adopted SHA3 (Skein) hash functions are also fine, but slower and provide no real extra assurances of data integrity, and provide no further security beyond SHA1. The OpenVPN HMAC firewall option to harden the protocol against Man-in-the-Middle and Man-on-the-Side attacks.

VikingVPN website

IVPN

1. IVPN’s top priority is the privacy of its customers and therefor we do not store any connection logs or any other log that could be used to associate a connection to a customer.

2. IVPN is incorporated in Malta. We would ignore any request to share data unless it was served by a legal authority with jurisdiction in Malta in which case we would inform them that we don’t have the data to share. If we were served a subpoena which compelled us to log traffic we would find a way to inform our customers and relocate to a new jurisdiction.

3. We use a tool called PSAD to mitigate attacks originating from customers on our network. We also use rate-limiting in iptables to mitigate SPAM.

4. We ensure that our network providers understand the nature of our business and that we do not host any content. As a condition of the safe harbor provisions they are required to inform us of each infringement which includes the date, title of the content and the IP address of the gateway through which it was downloaded. We simply respond to each notice confirming that we do not host the content in question.

5. Assuming the court order is requesting an identity based on a timestamp and IP, our legal department would respond that we don’t have any record of the user’s identity nor are we legally compelled to do so.

6. We ‘allow’ BitTorrent on all servers except gateways based in the USA. Our USA network providers are required to inform us of each copyright infringement and are required to process our response putting undue strain on their support resources (hundreds per day). For this reason providers won’t host our servers in the USA unless we take measures to mitigate P2P activity.

7. We currently accept Bitcoin, Cash and PayPal. No information relating to a customers payment account is stored with the exception of automated PayPal subscriptions where we are required to store the subscription ID in order to assign it to an invoice (only for the duration of the subscription after which it is deleted). Of course PayPal will always maintain a record that you have sent funds to IVPN but that is all they have. If you need to be anonymous to IVPN and don’t wish to be identified as a customer then we recommend using Bitcoin or cash.

8. We recommend and offer OpenVPN using the strongest AES-256 cipher. For key exchange and authentication 4096-bit RSA keys are used.

IVPN website

PrivatVPN

1. We don’t keep ANY logs that allow us or a 3rd party to match an IP address and a time stamp to a user our service. The only thing we log are e-mails and user names but it’s not possible to bind an activity on the Internet to a user.

2. We operate in Swedish jurisdiction. Since we do not log any IP addresses we have nothing to disclose. Circumstances doesn’t matter in this case, we have no information regarding our customers’ IP addresses and activity on the Internet. Therefore we have no information to share with any 3rd party.

3. If there’s abuse, we advise that service to block our IP in the first instance, and second, we can block traffic to the abused service.

4. This depends on the country in which we’re receiving a DMCA takedown. For example, we’ve received a DMCA takedown for UK and Finland and our response was to close P2P traffic in those countries.

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.

6. Yes, we allow Torrent traffic.

7. PayPal, Payson and Plimus. Every payment has an order number, which is linked to a user. Otherwise we wouldn’t know who has made a payment. To be clear, you can’t link a payment to an IP address you get from us.

8. OpenVPN TUN with AES-256. On top is a 2048-bit DH key.

PrivatVPN website

PRQ

1. No. Wo do not log anything and we only require a working e-mail address to be a customer.

2. Swedish. We do not share information with anyone.

3. Not disclosed.

4. Put it in the trash where it belongs!

5. None, since we do not have any customer information and no logs.

6. We host anything as long as it’s not SPAM related or child porn.

7. Visa/Mastercard, Bitcoin, PayPal. No correlation between payment data and customer data.

8. We provide OpenVPN services (along with dedicated servers and other hosting services).

PRQ website

tigerVPN

1. Absolutely not! We built tigerVPN to purge all data once the transmission of a IP package was completed successfully. Its impossible to trace back any customer. On top of that we decided to use shared IPs in order to further randomize and anonymize our customers. The combination of having absolutely no logs at all and multiple customers per IP, wipes our customers digital footprint

2. We are a limited liability company in Slovakia. Slovakia does not have any data retention programs and furthermore encourage ISP’s to protect their customers privacy on the net. We are not required to share any information with 3rd party hence it would be illegal thanks to the law of telecom secrecy.

3. Since we don’t keep logs, we can’t monitor abusive behavior, which is the price for building a customer secure environment!

4. We can’t comply since we can’t identify customers, therefore it’s pointless to follow any requests. We have a specific folder for these eMails ;-)

5. Same as above. We seriously can’t tell which customer did what, when, where, at any given time.

6. It’s allowed on all servers although we gently ask our customers to use either Romania or Netherlands. Some infrastructure service providers do not want file sharing so it happened to us that we were asked to move our servers due to file sharing. We found some reliable partners in Romania and Netherlands which tolerate p2p so we kindly ask our customers to use these server parks.

7. Customers can pay with Visa, Mastercard and Debit. On top of that we also use PayPal. We use hash keys and tokens to identify a payment but it’s not logged or linked to the customer. We had to do this anyway hence we are a PCI Level 1 compliant merchant. Therefore we are not allowed to store any card or payment data with the records of our customers. These keys are pointless for anyone else so there is no chance to build a connection.

8. We offer PPTP, L2TP and OpenVPN, while out of nature OpenVPN comes with the highest encryption and algorithm. L2TP and OpenVPN are 256bit SSL encrypted while PPTP comes with a solid 128bit. Although our customers are individual and have their own sense of why and what to use, we recommend L2TP as solid protocol. It’s less geeky and more secure than PPTP, but our customers can pick any of them in all the 47 network nodes around the globe.

tigerVPN website

Mullvad

1. No. This would make both us and our users more vulnerable so we
certainly don’t. To make it harder to watch the activities of an IP address from the outside we also have many users share each address, both for IPv4 and our upcoming IPv6 support.

2. Swedish jurisdiction. Under no circumstance we will share information with a third-party. First of all we take pains to not actually possess information that could be of interest to third parties, to the extent possible. In the end there is no practical way for the Swedish government to get information about our users from us.

3. We don’t monitor our users. In the rare cases of such egregious network abuse that we can’t help but notice (such as DoS attacks) we stop it using basic network tools.

4. There is no such Swedish law that is applicable to us.

5. We make sure not to store sensitive information that can be tied to publicly available information, so that we have nothing to give out. We believe it is not possible in Swedish law to construct a court order that would compel us to actually give out information about our
users. Not that we would anyway. We started this service for political reasons and would rather discontinue it than having it work against its purpose.

6. Yes.

7. Bitcoin (we were the first service to accept it), cash (in the mail), bank transfers, and PayPal / credit cards. Payments are tied to accounts but accounts are just random numbers with no personal information attached that users can create at will. With the anonymous payments possible with cash and Bitcoin it can be anonymous all the way.

8. We use OpenVPN. We also provide PPTP because some people want it but we strongly recommend against it. Encryption algorithms and key lengths are important but often get way too much attention at the expense of other important but harder to measure things such as leaks and computer security.

Mullvad website

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

Every licensed Blu-ray playback device since 2012 has supported the technology which is designed to limit the usefulness of pirated content. Illicit copies of movies protected by Cinavia work at first, but after a few minutes playback is halted and replaced by a warning notice.

This is achieved by a complex watermarking system that not only protects retail media but also illicit recordings of first-run movies. Now Verance has been awarded a patent for a new watermarking system with fresh aims in mind.

The patent, ‘Watermarking in an encrypted domain’, begins with a description of how encryption can protect multimedia content from piracy during storage or while being transported from one location to another.

“The encrypted content may be securely broadcast over the air, through the Internet, over cable networks, over wireless networks, distributed via storage media, or disseminated through other means with little concern about piracy of the content,” Verance begins.

Levels of security vary, Verance explains, depending on the strength of encryption algorithms and encryption key management. However, at some point content needs to be decrypted in order for it to be processed or consumed, and at this point it is vulnerable to piracy and distribution.

“This is particularly true for multimedia content that must inevitably be converted to audio and/or visual signals (e.g., analog format) in order to reach an audience,” Verance explain.

While the company notes that at this stage content is vulnerable to copying, solutions are available to help protect against what it describes as the “analog hole”. As the creator of Cinavia, it’s no surprise Verance promotes watermarking.

“Digital watermarking is typically referred to as the insertion of auxiliary information bits into a host signal without producing perceptible artifacts,” Verance explains.

In other words, content watermarked effectively will carry such marks regardless of further distribution, copying techniques, or deliberate attacks designed to remove them. Cinavia is one such example, the company notes.

However, Verance admits that watermarking has limitations. In a supply chain, for example, the need to watermark already encrypted content can trigger time-intensive operations. For this, the company says it has a solution.

Verance has come up with a system with the ability to insert watermarks into content that has already been compressed and encrypted, without the need for decryption, decompression, or subsequent re-compression and re-encryption.

In terms of an application, Verance describes an example workflow in which movie content could be watermarked and then encrypted in order to protect it during distribution. The system has the ability to further watermark encrypted content as it passes through various supply chain stages and locations without compromising its security.

“In a forensic tracking application, a digital movie, after appropriate post production processing, may be encrypted at the movie studio or post production house, and sent out for distribution to movie theaters, to on-line retailers, or directly to the consumer,” Verance explains.

“In such applications, it is often desired to insert forensic or transactional watermarks into the movie content to identify each entity or node in the distribution channel, including the purchasers of the content, the various distributors of the content, the presentation venue and the time/date/location of each presentation or purchase.”

Verance believes that being able to track distribution points, sales locations such as movie theaters or stores, and even end users will be a big plus to adopters. Those up to the complex analysis can see how the company intends to work its magic by viewing its extremely technical and lengthy patent.

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

Heartbleed is a bug in the open-source OpenSSL library that allows outsiders to read and dump encrypted data. When it was first made public it caused widespread panic with many experts describing it as “catastrophic.”

Among the affected services were a great number of VPN providers. At least momentarily, users of those affected services risked having their passwords and usernames intercepted, as well as other data they sent over a secure connection.

Perhaps even more worrying, successful hackers could have gotten their hands on private keys and certificates of VPN servers. For network adminstrators this was nearly undetectable before the bug was disclosed, and with the information the hacker could potentially decrypt users’ traffic.

With the keys and certificates in hand, hackers can still target live sessions of individual VPN users after the OpenSSL vulnerabilities are patched. That is, in cases where OpenVPN is used without ephemeral keys.

While not everyone agrees on the likelihood that these exploits are being used in the wild, they certainly are possible. For this reason, it’s important for VPN providers to take several steps. To the best of our knowledge the most crucial ones are the following:

• Update all vulnerable software components using OpenSSL (if statically linked) or OpenSSL itself.
• Replace all SSL certificates for all affected components and properly revoke the old certificates
• Generate new private keys for all affected components.

TorrentFreak inquired among the companies listed in our VPN provider overview to see how they responded to Heartbleed, and how this was communicated to their users. They all agreed that Heartbleed posed a significant threat but the countermeasures, posted at the bottom of this article, vary from provider to provider.

As for the future, more should be done to prevent these critical bugs from putting millions of Internet users at risk.

Heartbleed has shown that more in-depth peer reviews are needed to ensure that critical infrastructure software such as OpenSSL is built on clean and secure code. In addition, it might not be a bad idea to move away from the OpenSSL monoculture, and look at alternative such as PolarSSL, LibreSSL, or GnuTLS. Of course, these alternatives have to be carefully reviewed as well.

—

Below is the list of responses we received from various VPN providers, between April 22 and early May. The fact that these answers are posted here is not an endorsement, nor is it an indication that the steps taken were the rights ones. That’s not up to us to judge, we merely strive to get as much information out to the public as possible.

All VPN services answered the following questions.

1. What steps has your company taken in response to Heartbleed?
2. In your opinion, what were the risks users faced before these steps were taken?
3. How did you communicate the above to your users?

—

Private Internet Access

1. Heartbleed was an eye opener which helped to make the public more aware of the insecurities that exist in un-audited code. Regardless of being open or closed source, there will always be insecurities in systems. However, the best that companies can do is to strive to achieve 100% security. In our case, when the Heartbleed exploit was announced, we reacted immediately. It was publicly disclosed at or about UTC 19:00:00 on April 7, 2014. We patched our VPN gateways within 4 hours at or about UTC 23:17:15 on April 7, 2014 by upgrading our OpenSSL libraries to version 1.0.1g from 1.0.1f.

Our website was not exploitable given that we use a hardware load balancer that is not using a vulnerable version of OpenSSL.

Immediately after patching our VPN gateways, we then setup a non-production gateway that we attempted to exploit using the Heartbleed exploit POCs (proof of concepts). While it was recently announced that OpenVPN is exploitable, it is our best belief that our private keys were never leaked given that we have systems in place that make the exploitation of our servers very unlikely.

That being said, within 24 hours we are rolling out updates to our clients as well, even though it is highly unlikely that our keys were ever leaked.

2. The likeliness of our gateways being exploited prior to us rolling out these patches are extremely low. However, as stated earlier, at Private Internet Access, we strive to achieve 100% security, so we went through the motions as it is our policy to do so in best practice.

3. We waited to announce anything to our users until we were 100% certain of everything we were stating. That said, we posted on our blog after we performed our patches.

Additionally, we will be sending out a mass e-mail within 24 hours to our clients as certain users (DD-WRT, stock OpenVPN, etc.) will need to manually apply updates in order to connect to our service.

TorGuard

1. Upon hearing of the OpenSSL vulnerability our staff took immediate action to preserve the integrity and security of TorGuard services. This included a full audit of our VPN network, software, and websites. All VPN servers have now been updated to a non vulnerable version of OpenSSL and these new connections have been automatically downloaded in all TG VPN clients. TorGuard’s Pro VPN client software has also been updated to the latest patched OpenVPN version and pushed to all users. Our company’s website infrastructure, client area, and email services were not vulnerable even in the months prior when this bug was out in the wild.

2. While the threats posed by the OpenSSL HeartBleed vulnerability are wide reaching and potentially very serious, our team can confidently say this development had no impact on the security of TorGuard’s users. Rest assured, we won’t let your heart bleed.

3. TorGuard posted the findings of the network audit on our blog and immediately emailed all clients a direct link.

Ipredator

1. Once the vulnerability was made public we instantly started to patch all affected systems. This particular bug was present on our IPv6 VPN machines, a subset of the IPv4 VPN servers that were using OpenSSL 1.0.1 and all of our external SSL services like the website, the tor exit node, or jabber server.

After the upgrade to the latest OpenSSL version was finished we decided to replace the private keys from all affected components because the confidentiality of those keys could not be guaranteed anymore. The window of opportunity for an attacker who had this bug as a 0day up his/her/its sleeve was simply too long. Due to the nature of the bug it is very difficult to say retrospectively if it was used to gain access to possibly sensitive memory contents of the affected machines.

Since we had to replace all affected VPN server certificates we decided to deploy a new key management scheme for those machines. Each OpenVPN instance now uses one time private keys, cert and DH keys that are cycled on process restart.

In the same way we have seen the emergence of special purpose hardware for Bitcoin mining we should also assume that the entities that have the means to compromise cryptography also possess special hardware to deal with encryption. As an additional precaution against this scenario we deployed server and DH keys with variable lengths instead of sticking to the “well known” lengths/constants of 2048 and 4096 bit.

We are still working on making sure that all OpenSSL 1.0.1 components support the EC curve 25519 from DJB since any EC constants put forth by the NIST (or NSA) should be considered compromised.

2. Total exposure.

3. Users were informed through the usual channels (Twitter, blog, IRC).

Mullvad

1. We upgraded OpenSSL on all servers and client downloads. We created new keys on all servers. We revoked all old keys. We released a new client program with the revocation list that also creates new client keys. For those not using our client program we published new OpenVPN configuration files with the revocation list and new client keys for all users.

2. It was unknown how vulnerable OpenVPN was in practice so we decided to find out by trying to exploit the bug on a test server. We repeatedly succeeded in extracting the server’s private key. These findings were sent in full detail to the OpenVPN team and published in less harmful form e.g. here.

The conclusion is that before the fixes above all OpenVPN communication were at risk of decryption by anyone knowing about the bug *at the time*. Due to perfect forward secrecy they can’t be decrypted with a key leaked at a later time. So anyone who did not know about the bug but managed to snatch a key after the bug was published can’t go back and decrypt traffic they may have stored.

3. We put a big red warning banner on our website that is still there and published a news item explaining the situation and urging all users to upgrade.

VikingVPN

1. We learned about the vulnerability at 9:17PM CST on April 7th. From that point forward, we did not sleep until the vulnerability was closed and every server was penetration tested against all known forms of the exploit to ensure that the vulnerability was closed.

At the time we found out about the vulnerability, there wasn’t even a CVE entry in the database explaining the nature of the vulnerability or the attack. We knew that because of the integration of OpenSSL into the Windows OpenVPN open-source client, and the default builds of OpenSSL installed into almost all distros of Linux/BSD that this was going to be huge.

As more information unfolded and the OpenSSL updates hit the verified repositories, we began the patching process on our servers. After the main vulnerability was closed and a rolling restart was issued to the server clusters, we went to work with notifying clients of the bug and advising them to update their clients to current.

The servers were patched and confirmed safe by 7:00AM CST on April 8th. This is when we released our transparency post advising our users on the situation, and how they can respond to close the bug client-side. A mass email was sent shortly after advising our clients to read the post, and had instructions on updating their clients.

2. The bug is catastrophic in scale. We avoided disaster by having a very strong security model and not allowing clients to change security settings. During the vulnerable period where the bug was unknown publicly, there was no way for a VPN provider to detect if they were attacked. It is possible that server keys and certs were lost although we have had no evidence of this. Our root CA was not exposed. Our website was unaffected. Our load-balancers were unaffected.

The worst case scenario for our security topology is that keys and certs and the tls-auth server key were lost to a nefarious attacker who was subscribed to the service. (because of TLS-Auth, there was no way to exploit heartbleed from outside of the network, only inside). If this were to occur, an attacker could attempt to impersonate a VPN server. In order for the attack to work they would have to take many specific steps to circumvent various load-balancing and routing steps that place during the connection process. We think that this is highly unlikely to have happened, but is not impossible, so we are disclosing it to be as open and transparent as possible.

Note that a VPN service that claims zero exposure to Heartbleed is almost certainly lying or has so little knowledge about network security that they should not be in the business. Heartbleed hit everyone, it is a matter of how badly.

3. We responded publicly here, and also also had a Heartbleed article here. We also made informational posts to the community at /r/VPN on Reddit and reached out to other VPN services we are close to in order to discuss countermeasures and implementations. We also made an effort to educate the /r/VPN community on proper countermeasures.

IVPN

1. We revoked all VPN server certificates and generated new 4096 bit certificates within a few hours of the announcement. We’ve also had our websites EV certificate reissued. Most of our client software was not using a vulnerable version of OpenVPN but where necessary we patched the client software as well.

2. A successful attack could reveal the server’s private key which could be used to impersonate the server in a MITM attack or to passively decrypt the session keys during SSL negotiation. Although we implement tls-auth this doesn’t mitigate the risk substantially since the auth keys are visible to all customers. Its important to understand that a successful attack prior to the announcement would likely only be possible from a very sophisticated and well funded adversary targeting a specific individual. Such adversaries almost certainly continue to possess undisclosed vulnerabilities that they can use to exploit targets.

3. We sent out a tweet immediately after installing the new certificates. We then emailed all our customers with information about the vulnerability and instructions on how to update the client software where required. We also made an infographic to help customers understand what passwords to change on other services.

PrivateVPN

1. Yes, we have updated OpenSSL on both OpenVPN servers and the website. The certificate for the VPN server has been updated as well.

2. Hard to say. Worst case is that information has been leaked when we had the old version of OpenSSL.

3. We posted two updates on our website.

tigerVPN

1. We constantly monitor all upstream software providers and keep current with the upgrades they provide. As such, as soon as a fix was made available that would suit our platform as well as our internal security standards, we took all steps necessary to upgrade our systems.

Following a routine audit we’ve concluded that none of our critical systems were affected during the period between the public release of the proof of concept and the date at which the necessary fixes were applied.

2. As our systems are being actively monitored there is no reason to believe that our customers were affected by the Heartbleed attack in any way. Since the exploit seems to work on both server software and client software, there is a slight chance that, if some of our users are also using other providers, they would be affected in case a malicious provider – by choice or having been affected themselves – were to attempt to extract information from them.

The information – from what we’ve seen in the behavioral analysis of the exploit by various security professionals – that they would be able to obtain would be pertinent only to their specific connection to that provider. Also, from a client’s perspective, running a Windows machine the only service potentially affected by this bug would be OpenVPN as the others are key services provided by Microsoft in the core OS and do not share anything in common with the OpenSSL library.

3. We constantly run security audits, monitor our network and improve TigerVPN. Although the incident was hyped on a big scale, we did a lot of upgrades, fixes and improvements throughout the month. If we would inform our customers about every single time we work on our software or hardware, they’d unsubscribe and report us as spam :-). We understand this is in the nature of our responsibility to pro-actively react to events such as Heartbleed. In case we ever noticed any kind of breach, all our customers would get notified immediately as with a single click.

BlackVPN

1. Our website was running an unaffected version of OpenSSL (0.9.8g) however we updated OpenSSL there anyway.

Some VPN servers were vulnerable so we updated all servers on April 8th to protect against further attacks.

On April 17 we issued new VPN configs with new 4096 bit certificates. We were working on this after we found out about Heartbleed but as soon as it was proven that the bug can be used against OpenVPN we immediately made the new configs + certificates available to everyone. On the VPN server side all the certificates, keys and DH keys have been replaced.

2. It has been proven that Heartbleed can be used to steal the private key and impersonate a VPN server (if the VPN server was running a vulnerable version of OpenSSL). People connecting to what they thought was their real VPN provider could actually be connecting to a fake VPN server or honeypot – although this would take the resources of a powerful government agency or similar.

3. In order to be as open and transparent as possible we started a new blog to warn people of the potential dangers and to update them of the changes we made. We echoed this message on all our social media channels (1, 2), Facebook (1, 2), Google+ and Reddit (1, 2) ) as well as emailing all our current and previous customers (in case a previous customer renewed without being aware that they should update).

Anonymizer

1. The website itself was not vulnerable at all, at any time. Our OpenVPN servers though, were changed to a different version of OpenSSL that was vulnerable on 2/27/2014. So, a vulnerability existed on our servers from 2/27/2014 through 4/8/2014, for a total of 39 days. We replaced/regenerated the certs on all clients and servers, since they were potentially exposed, within the day.

2. Small, but of course possible. We use HMAC-based TLS authentication at both ends of the connection, using separate halves of a shared key, as recommended by OpenVPN. This creates a signature of each packet which is attached to the packet. The server drops any packets that are unsigned or incorrectly signed. In the past, this has primarily been used to prevent / slow down a DDoS attack, since the attacker would need to securely hash each packet using the right half of the shared key in the way that the OpenVPN client does.

Even with the suggestion from OpenVPN that TLS auth could form a kind of protection against Heartbleed, it isn’t foolproof, given that we have to distribute the key with each client or no one would be able to connect to our servers. As the researcher who created the OpenVPN penetration test earlier this week noted, it wouldn’t be that difficult for a determined hacker to discover the TLS auth key and modify his attack to use it. It does, however, prevent a drive-by attack where we are hit more or less randomly as a VPN services provider.

The worst case scenario is that someone obtained our older server private key and was able to decrypt live data and create a man-in-the-middle attack against our users during the 39 days we were using OpenVPN 2.3.2. Account credentials could have been compromised, and the private key could have conceivably been as well. Once we replaced OpenVPN to a non-vulnerable version and the server certificate was replaced, that vector was closed.

3. We sent out an email notice to our customers.

BolehVPN

When the Heartbleed announcement first broke, on the 7th April, we reviewed our servers and customer portal system and found that they did not utilize the affected OpenSSL versions. When OpenVPN released their patch to fix HeartBleed, we immediately implemented this in our own client and released this on the 10th April 2014. Moving forward, our next client release will use OpenVPN 2.3.3 which we hope to release in the coming week.

We are also in the midst of an entire customer portal revamp to improve security and usability which we hope to release in a month or so and are considering a complete reissue of all keys when this is released. The revamp was initiated many months ago and was not as a result of the HeartBleed bug but is in line in our continuing efforts to improve our system’s security.

Our OpenVPN implementation implements tls-auth with Perfect Forward Secrecy (PFS) would protect past communications from retrospective decryption so the risk is mitigated. In this scenario an attacker can not attack OpenVPN instances without the TLS-auth key. Our customer portal processing system never used the affected OpenSSL versions and remained with the older OpenSSL 0.9.8. Users may request for a manual regeneration of their keys if they wish to be overly cautious by opening a ticket with us.

We sent out an email announcement to all users immediately, as well as a Facebook and Blog post on the 8th April 2014 3.22 PM GMT+8. We then pushed an update to our VPN clients on the 10th April with the patched OpenVPN version as well.

NordVPN

1. In a response to Heartbleed, NordVPN has changed private keys for all servers. Also, the main NordVPN’s certificate has been revoked and a new one has been added. Our OpenSSL libraries have been upgraded from version 1.0.1e to a safe 1.0.1g.

2. For users: potential user detail leaks such as user names and passwords, but this is very unlikely as data that malicious people could get was in random locations in a server memory and user details are not kept in the memory for an entire session.

For servers: Private SSL certificate keys are used to encrypt and decrypt data communications between user and a VPN server. If anyone could have received a certificate and perform a man in the middle attack, all data which was sent from a VPN server to the user could have been decrypted.

3. The information was constantly shared to our users via our live chat and e-mails. Also the pop-up, an announcement line and the blog records were used to inform the steps we were taking in a response to Heartbleed. Here was the latest blog record about Heartbleed: https://nordvpn.com/blog/heartbleed-vulnerability-has-been-removed/

Proxy.sh

1. When the Heartbleed security news broke, our engineering unit immediately scanned all our servers and upgraded to latest version the few servers (about 4% of our infrastructure) that were using vulnerable versions of OpenSSL. Our team then progressively patched absolutely all our servers in an attempt to enjoy other bugfixes (unrelated to security) accompanied with the successive new versions of OpenSSL. Vulnerable servers were patched within less than one hour and the non-vulnerable ones progressively got all upgraded within 24 hours.

We then researched about the implication of this bug and with the security community, we came to the conclusion that it was beyond reasonable doubt, even though most of our servers were non-vulnerable, that a new re-generation of private keys was indeed necessary. Indeed, extraction of private keys on vulnerable servers proved possible.

Since re-generating complete new sets of private and public keys undeniably involves a downtime and reconfiguration on user end, we also took this ‘opportunity’ to completely upgrade our encryption scheme, now leading the industry with CBC mode of AES with 256-bit as cipher, hash algorithm of 512-bit SHA (SHA512) and control channel of 4096-bit RSA through TLSv1/SSLv3 and with 256-bit AES, enforced to all customers by default.

The latest move does not necessarily respond to Heartbleed, but at least it makes it 100% theoretically impossible that the Heartbleed bug has any implication on the current VPN network, as the latter is using not only new private and public keys, but also completely new encryption algorithms.

2. It is very complex to answer with certainty what truly happened. But basically, a hacker who knew about this security hole before it went public (or within the few minutes between the time the news broke and the time we patched vulnerability), could have hacked the 4% of our servers infected with the vulnerable version of OpenSSL. They could have retrieved our private keys, and thus would potentially be able to decrypt the traffic that has been generated by our services before they have been updated with new private keys.

Any service that did not either re-generated new private keys (and offered new certificate files to customers) or upgraded completely its encryption scheme (or optimally having done both), is at risk of being exposed to full decryption because the keys could have been stolen at anytime before the patch was enforced on vulnerable servers, and vulnerability across any network of more than a hundred servers built over the course of several months or years was undeniably present at sporadic levels.

Now, factually, only a very close circle of white hat hackers were aware of this security hole and exploiting it in relation to keys vulnerability took us or anyone with security experience several days to figure out (wisely we applied precautionary principle and upgraded the keys well before). That means it would take at least some hours for most experienced hackers to have been able to exploit Heartbleed, hence the keys have had a thin chance of being compromised since the vulnerable servers were patched few minutes after 0day news.

3. We offered a public blog article within less than 24 hours after OpenSSL released new version and Heartbleed bug came out to public. This article can be found here and we explain in it that we successfully updated our OpenSSL software to latest version, even though most of our servers were using non-vulnerable versions of OpenSSL. The upgrade itself started few minutes after the security news broke.

Twenty four hours later, we published another article to warn customers that we will be shutting down the entire network for less than 5 minutes (with downtimes of few seconds for each server) as we will be both re-generating new private and public keys, as well as upgrading our cipher and authentification encryption.

Seventy eight hours later, we published a final article to explain that the upgrade has now been undertaken and that all users should download again the new configuration and certificate files in order to be able to connect to our network.

All these articles were advertised on our Twitter account. Finally, we sent a mass e-mail (the first time in our history) to all our customers to explain again to them that they should download new configuration and certificate files, as well as preferably change their passwords.

HideIPVPN

1. We are using Ubuntu on all servers. We have updated all our 12.04 Ubuntu versions next day, we are also using older Ubuntu where we use unaffected OpenSSL version.

2. We think the only risk is that it was possible to steal the username and passwords for the client area. We think that getting these details from the memory would be very complicated.

3. We published an article here.

SlickVPN

All of the gateway servers were updated to a non-exploitable version of OpenSSL as soon as we heard about the issue, within hours of the initial public notice. We do not believe any of our key information could have been exploited in such a short amount of time, but we’re still planning to re-issue keys with the next client version, which should be updated by this weekend. We are also issuing new .ovpn files on our website. Once the updated client has been issued, we will be creating a blog post informing our clients about the changes.

OctaneVPN

1. In summary, our website was running on an older server with OpenSSL libraries that pre-dated the introduction of the Heartbleed bug into OpenSSL, so we feel our customer confidential information was not at risk due to Heartbleed. Among our VPN network gateways, many were on a vulnerable version of OpenSSL or a vulnerable build of OpenVPN server. Those that were vulnerable were updated and restarted within hours of the public announcement. Due to the short time between public announcement and our updates, we feel the risk of key disclosure was very small, but as a precaution the next release of Octane OpenVPN client will update the client keys.

In addition, this vulnerability in a key internet platform spurred us to consider a number of other scenarios which has resulted in us adding some cool new features and options in our OctaneVPN client which will be released soon.

2. Straight up, this was a serious bug in a major internet platform. The risk and vulnerability is same for all websites and services that relied on OpenSSL for encryption. In general, based on research others have posted, it appears the worst case would be that a private encryption key could be obtained by an untrusted third party. In addition, it appears this would leave no traces.

Assuming others were not exploiting the Heartbleed vulnerability before its public announcement, we feel the risk of a private key release was very small due to the short time window between public announcement and us applying patches to our gateway servers. There is no evidence or unusual patterns that would lead us to suspect our gateways were targeted. Our website was not vulnerable to Heartbleed since it was running an older OpenSSL version prior to when the Heartbleed bug first entered the OpenSSL code.

Remember, most sensitive web traffic is already encrypted by the end website/browser via SSL before it is encrypted again by a VPN network, so an attacker would need both a VPN private key and also the end website’s private key (say Amazon.com or gmail.com keys) to even start to have a chance. The possibility of obtaining one key through Heartbleed is remote, but doing it for two keys and the correct two keys for a given data packet before those sites were patched or new keys issued is that much harder.

3. How we communicated the above to our users.

a) We developed a dedicated web page
b) We have worked with individual customers through our support channel to answer specific questions
c) Our OctaneVPN client will notify customers automatically as new releases are available
d) A comprehensive email will be pushed to customers once the new client features are placed in production

IPVanish

1. The Heartbleed bug potentially exposed data being passed over the OpenSSL encryption protocol using TLS extension 15. IPVanish did not and continues not to support the TLS extension 15, meaning all IPVanish users were and are safe from this bug.

2. In addition to our point above, our entire Network Operations team conducted a deep dive to verify and confirm that no steps were needed in response to Heartbleed. We also continue to monitor the situation and will take the necessary steps if and when necessary.

3. We proactively communicated to our users via our homepage, blog, social media handles (including Twitter, Facebook and Google+), and affiliate network, that all IPVanish users have been and continue to be safe from Heartbleed. We additionally notified users that even though IPVanish itself never had a breach of security, we recommend they update their passwords if they use the same credentials across different services.

LiquidVPN

1. The first step was taken almost immediately. Our intrusion prevention system was updated with the Heartbleed signature within 2 hours of the announcement. We performed an audit and identified the vulnerable systems. The last vulnerable VPN node was patched at 9:00 AM on 4/7/2014.

The affected servers had new keys created from an unaffected CA. We used to use two CA’s. 1 for our shared only server clusters and the 2nd one for our shared, dynamic and modulating server clusters. Our Shared IP CA had their certificates revoked and is no longer used anywhere.

We already had a plan in progress to do an overhaul of our OpenVPN configurations that will include a standardized configuration across the three different VPN server builds we use. It includes an update to our network security, lowers our key re-negotiation time from 60 minutes to 30 minutes or less and uses a dedicated offline server purchased recently to serve as our air-gapped CA. When this rolls out we will issue new certificates across the network for the final time.

Our webserver was patched later that morning. We requested a new SSL certificate on 4/8/2014 and it was applied on 4/9/2014. We use Viscosity by Sparklabs as our VPN client. As soon as they released their OpenSSL patch it was pushed out to the clients.

2. This was a major vulnerability. No matter how much some providers downplayed it. For LiquidVPN an attacker could have signed up to our service and got their hands on our shared TLS-Auth key. With that in hand they could decipher portions of user VPN session data but every 60 minutes keys are re-negotiated so their access would be limited.

Website usernames and passwords could be compromised. Users were susceptible to man in the middle attacks. VPN usernames/passwords could be stolen.

3. We wanted to take a very proactive and transparent approach to this problem. However we had to secure users session data first. So we issued several updates beginning on April 7th. There is a handful of twitter posts they can be found @liquidvpn.

Our basic announcements (there were several) can be found on the website. The network status section has more information than the announcements. Finally after everything was secured and our updates were complete we published a blog post.

AirVPN

As soon as the vulnerability became known to us, between late night of April the 7th and early morning of April the 8th in Italy, we immediately started to get documentation. We began to work on the system minutes after we fully understood the problem and how the buffer over-read could be provoked and exploited.

Luckily our setup which involves Perfect Forward Secrecy both with OpenVPN and on the web server and the fact that our VPN servers do not keep any database or other data pertaining to users made the vulnerability not very risky for our VPN users.

Most of our VPN servers already were running non-vulnerable OpenSSL branches, as well as the various backend servers (a vital part of our infrastructure). On top of that VPN servers, web server and clients never contact directly backend servers, so we found ourselves in a very favorable situation. Our frontend web servers on the contrary were vulnerable.

We proceeded to make sure that OpenSSL version on the VPN servers was not vulnerable, patch OpenSSL in our web sites and revoke the SSL certificate, reboot all the web servers to make sure that no vulnerable in-memory OpenSSL was still loaded, install new key and new SSL certificate on every frontend web server, change internal use keys and certificates, change every administrative password on every server, patch OpenSSL on the couple of VPN servers which ran OpenSSL 1.0.1f and reboot them.

We performed attacks against all of our own servers to make sure that the vulnerability was not there. For this we must thank very much external, trusted reviewers who with dedication and passion continuously search for vulnerabilities in our servers and report to us the results – you know who you are, thanks again! All of the above was completed between 11.00 AM and 11.00 PM April the 8th CEST.

However, we soon realized that we had to keep into account that the vulnerability is client-side too, so the fact that our servers were “secured” could not be considered sufficient. Therefore we had to face the non-trivial problem to reach and inform our users, which was solved with a “dramatic” decision about a radical upgrade to the system which would have been performed after only a few days.

The upgrade would have forced users to get informed because from a certain point in time they could not connect anymore to VPN servers until they upgraded. Under a marketing point of view it appeared as an extremely risky decision, but now that two weeks have passed by we can say that this decision was wise, and anyway it was the right thing to do regardless of any marketing consideration. And it was also a good chance to switch to bigger keys and perform some radical optimizations that we could not perform without disconnecting users for several minutes.

About information to the public, we started with a public announcement on April the 8th, as soon as we had clear ideas on what users needed to do. This was linked also through Twitter and Facebook. The post was updated in real time while we were working on the system.

The final steps were to renew the users keys. We needed first to find an effective way to “encourage” users to upgrade their systems. We decided to switch to 4096 bit RSA and DH keys, with new certificates, in a precise moment in the future (after just few days), to maximize the probability that when a user was forced to regenerate configurations, keys and certificates, he/she would have been brought more easily to upgrade any possible vulnerable part of his/her system. This was announced here.

And we sent via PM and e-mail (to those users who entered a valid e-mail address in their account data) a link to the announcement. At the same time we powered up the customer service for any clarification and to face any possible, massive wave of support requests. Since we do not outsource the customer service we did not need to impart lessons to customer care personnel in order to make them understand the problem, saving us many hours and allowing us to be confident that customers were correctly supported in case of need. Additionally we could count on our competent, supporting and very active community in our forums.

VPN.S

1. We have scanned all services and devices, our web servers and OpenVPN server installations do not use the vulnerable version of OpenSSL affected by Heartbleed.

The tools we used:
OpenVPN: https://github.com/falstaff84/heartbleed_test_openvpn
Webserver installations:https://sslabs.com

Manual checks were done on all other equipment such as Cisco routers. We have opened a internal review on the possibility of switching our SSL solution to PolarSSL.

2. Risk is only associated with users sharing passwords between VPNsecure accounts on services that were affected. We have advised users to change the password on the account which automatically regenerates the openvpn keys.

3. Facebook notifications were sent out, along with a news article and email.

VPN.ac

1. We’ve been very quick addressing the issue, and we started patching everything immediately after the public vulnerability disclosure (Twitter announcement).

- First we added a firewall rule to temporarily block and log all Heartbleed probes against our servers, allowing us to run the upgrades and issue new encryption keys while not being exposed
- Website’s SSL certificate has been changed and we asked the issuer of the old certificate to revoke it; it was revoked one day later
- The upgrade process of all affected servers running the vulnerable OpenSSL libraries was completed and all services restarted in the next few hours
- After finishing the updates, we generated new encryption keys for our OpenVPN service and pushed them on all servers
- Our Client Software has been updated on April 8 to include the non-vulnerable OpenVPN binaries

2. We don’t believe that the risks our users faced were of high importance until then, but once the vulnerability became public – taking all necessary measures to mitigate the risks and protect our infrastructure was obviously the best thing a responsible company would do.

3. We announced on Twitter minutes after the vulnerability public disclosure that we’re already updating the servers. Once everything was secure on April 8, we issued a detailed statement on our website and it was sent by email to all our customers.

Unspyable

1. Our servers operate under versions of Linux that were not affected by this. Our OpenVPN servers use a custom build of OpenVPN that use non affected versions of OpenSSL. We use TLS which also minimizes the risk

2. The risks were minimal, since on the server side nothing was vulnerable.

3. Other than advising customers to upgrade their OpenVPN there was nothing else to be done.

Seed4.me

1. Our experts evaluated possible risks, replaced the certificate and published a blog post.

2. Fortunately we are not severely affected. Possible men-in-the-middle attacks, the same as all other websites on the web. VPN services are not affected and we could not expose any private user information. More details are in the blog post.

3. We published a blog post, notified all our followers in Facebook and Twitter, asking to change password for other affected services. There is no need to change passwords for Seed4.Me accounts.

VyprVPN

1. As soon as news of the Heartbleed bug became public, we gathered our technical team together to determine the potential risks to our customers. We determined VyprVPN and the Golden Frog website have not ever used SSL libraries vulnerable to the TLS heartbeat exploit. For our secure online storage service, Dump Trunk, SSL libraries were patched as soon as possible and new ssl keys for the service were generated and deployed successfully. Due to the seriousness of the Heartbleed bug, we did recommend customers change their password as part of a sound security strategy.

2. Fortunately users were not at risk. Our apps use OpenSSL 1.0.1e, which is vulnerable to the Heartbleed Bug, for OpenVPN connections. However, even though the apps use a vulnerable version of OpenSSL, customer information was not at risk. To be compromised, the apps would need to connect to servers that send malicious heartbeat packets. Our apps only connect to VyprVPN servers, which do not send malicious packets. Even if the VyprVPN apps were somehow tricked into establishing a connection with a malicious server, the apps do not possess any information they are not already sending to the server. There is nothing a malicious server could gather from the client that it wouldn’t receive anyway.

3. We published a blog post and linked to it via our social media channels. We also immediately sent an email to all customers. Our support team was kept informed of potential risks and answered customer questions that came in from customers.

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

Just recently the tactic branched out into describing most leading pirate sites as malware havens, a claim that some described as exaggerated. However, during the past few hours a pretty big and related drama hit semi-private torrent site Demonoid.

After being off-air for 20 months after hosting trouble in Ukraine, the site relaunched this March. Former members of the site were pleased to find that their old logins worked and ever since the site has been trying to get back to its former glory. Yesterday, however, problems with third party adds provoked a harsh response from Google, one that continues today.

Those searching for Demonoid are currently warned in search listings that “This site may harm your computer” and even those who choose to ignore the warnings aren’t allowed to access the site via Google. Instead they are diverted to the following page:

Google’s advisory reports that after checking 59 pages on the site during the past 90 days, 7 pages resulted in “malicious software being downloaded and installed without user consent”, something likely to worry most users.

Google goes on to report that the malicious software in question was hosted on another domain – adv-inv-net.com – and further investigation reveals that the site is the source of a huge number of problems.

According to malware analysis the Romanian-hosted domain carries 177 exploits and 2 trojans, which together have led to the infection of not only Demonoid, but more than 2,000 other sites.

Aware that Demonoid along with thousands of other sites had been blacklisted by most search engines and web browsers, Demonoid’s operators announced that all advertisements would be removed from the site until the problem could be identified.

“We run content from a lot of ad networks in our ad banners, and a lot of banners from each,” the management team said in an announcement.

“One of those banners started serving malware, so we disabled all ads until we are 100% sure of the culprit and get it removed. We are also taking the proper steps to get us out of all the blacklists.”

This latest advertising controversy comes just a week after the publication of a report which claimed that 90% of the Internet’s top 30 “pirate” sites contain malware, “potentially unwanted programs”, or items designed to deceive.

While seemingly not Demonoid’s fault in this instance, one has to question if these kinds of malware events will become more prevalent in the months to come. With entertainment industry companies scaring away advertisers, options for torrent and streaming site operators to do business with ‘up-front’ ad networks are likely to narrow, forcing them further into the arms of those who carry the kind of junk experienced in the past 24 hours.

Photo: Michael Theis

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

NPD’s Senior Vice President, Industry Analysis, Russ Crupnick informs us that mobile music piracy through apps has outgrown traditional P2P file-sharing and direct downloads.

“In terms of the number of internet users doing a variety of music sharing activities, downloading from mobile apps is the most popular,” Crupnick tells TF.

The data comes from unpublished research, which was the first to include statistics on the usage of mobile apps to download music. Quite surprisingly, mobile piracy comes out on top right away.

It is estimated that in the United States 27 million people downloaded at least one music track via their mobile over the past year, mostly without permission. This trumps all other forms of online piracy. By comparison, 21 million people used traditional P2P sites such as The Pirate Bay to download music.

For other media types the results are different, but the findings signal an interesting trend.

According to NPD mobile apps are, as one would expect, most popular with younger consumers. There are a variety of reasons for the mobile piracy explosion, but the research firm believes that increased usage of smartphones and apps among Millennials is a major driver.

“My guess is there is an underground buzz network about music apps that is fueled by teens and Millennials,” Crupnick says.

NPD believes that it’s important for copyright holders and app platforms to work together to tackle this problem. While some people may know that these apps are unauthorized, the fact that they appear in iTunes or Google Play may give them an air of legitimacy.

“Lots of things on the web are free or ad-supported, including some entertainment content. I’m sure some users are quite aware that there is music that is not legally distributed on these apps, but others may not be as educated,” Crupnick tells us.

“If it’s on an app store, it must be ‘OK’. This is where the music industry and technology companies have an opportunity and maybe an obligation to work together to make sure consumers understand, and artists get compensated,” he adds.

These last comments appear to signal a new working territory for the music industry’s anti-piracy initiatives. Until now, there hasn’t been a major campaign against “infringing” apps, but this is bound to change in the near future.

Whether a crackdown on apps will be enough to counter the current mobile piracy trend has yet to be seen. In addition to pirate apps, several unauthorized MP3 indexes have also developed mobile versions, which will prove much harder to deal with.

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

“I don’t care what the international community says at all. Everyone will see the power of the Turkish Republic,” Erdogan said on Thursday.

Angry that Twitter did not respond to requests by Turkish courts to remove material that showed him in a bad light, Erdogan swung the banhammer and by Friday everything was in place. Turkish visitors to Twitter were greeted with notices displayed by their ISPs indicating that Twitter had been blocked by court order.

“Because there was no other choice, access to Twitter was blocked in line with court decisions to avoid the possible future victimisation of citizens,” Turkish telecoms watchdog BTK said on Friday.

What followed was anger from citizens, then delicious payback against yet another government trying – and ultimately failing – to artificially restrict access to information on the Internet.

Rather than bow to Erdogan’s wishes, Turkish citizens reacted in much the same that file-sharers around the world have done when sites such as The Pirate Bay were blocked by their ISPs. They took to the open web to spread the word on how to circumvent web censorship but in a fresh twist, they also took to the streets

The wonderful image below, ironically posted to Twitter itself, shows a poster on a Turkish street explaining how to change DNS settings to obliterate the Twitter ban.

Another photograph, again posted to Twitter, shows graffiti on a housing block informing people of the IP addresses used by Google’s DNS service rather than the ‘infected’ ones offered by local ISPs.

But while these images will be a delight to anti-censorship advocates everywhere, it was online that the real battle was taking place. Here at TF we noticed an unusual level of interest from Turkish visitors in our latest VPN article and then later in the day the effect on VPN takeup was confirmed by the company behind Hotspot Shield.

AnchorFree CEO David Gorodyansky told WSJ that 270,000 Turkish users installed their software in one 12 hour period Friday versus around 10,000 on a normal day, a huge increase by any standards.

TorrentFreak spoke with Andrew Lee at Private Internet Access who explained that while his company does not track the identities or locations of its customers, there had definitely been an uptick in signups following the introduction of Twitter censorship in Turkey.

“More and more, we are seeing that censorship is a form of control that the weak use in an attempt to hang onto power. In addition to Turkey, we can also see this happening in China, the United Kingdom and other various countries,” Lee explained.

“Fortunately, the people of this world, including Turkey, are strong, and democracy will continue to stand. As such, the attempt to censor Twitter in Turkey has all but failed.”

This article began with the suggestion that censorship of the type imposed by Turkey is something to be embraced. Not welcomed, of course, but treated as an opportunity to gain knowledge on how the Internet works and how web blockades can be circumvented.

Those who think they can control the Internet and people’s right to communicate should be made to think again and in Turkey this week that point has been admirably made.

According to analysis site Zete.com, tweets in Turkey before the ban numbered 10 million a day – they now sit at 24 million.

Update: According to a local report, Turkey has now appears to have blocked Google’s DNS, although other sources say that this is an actual network issue.

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

Published on Glenn Greenwald’s The Intercept, the new papers reveal internal NSA discussions over what can and cannot be monitored in various circumstances.

In Q&A‘s between NSA staff, Threat Operations Center Oversight and Compliance (NOC), and the NSA’s Office of General Council (OGC), torrent sites are mentioned on a number of occasions, with The Pirate Bay sitting front and center.

Tracking The Pirate Bay and its users

The first question concerns the querying of non US-based IP addresses which have been obtained from home soil.

“If we run across foreign malicious actors at home (spam email, router/IDS logs, torrent sites, etc) can we bring those IPs here and use the SIGINT [intelligence-gathering by interception] system to monitor these guys?” the member of staff asked.

“It might be okay,” NOC and OGC responded, “but wait for confirmation.”

The second instance came from a staff member asking questions over the monitoring of servers overseas, alongside the possibility that U.S. citizens may be using them.

“Is it okay to query against a foreign server known to be malicious even if there is a possibility that a US person could be using it as well? Example, thepiratebay.org,” the NSA employee wrote.

No problem, came the reply, but exercise caution.

“Okay to go after foreign servers which US people use also (with no defeats). But try to minimize to ‘post’ only, for example, to filter out non-pertinent information,” NOC and OGC wrote back.

From the documents it’s clear that the NSA sees both The Pirate Bay and Wikileaks as organizations that threaten U.S. security through their distribution of U.S. secrets. What follows is a question which seems to suggests that once a torrent has been released on The Pirate Bay, it’s possible to analyze traffic sent before the release was made in order to trace the leaker.

“[If a] list of .mil passwords [were] released to thepiratebay.org…can we go back into XKS-SIGINT (using a custom created fingerprint) to search for all traffic containing that password in foreign traffic just before the release? the NSA worker asked.

Tracking people using proxies to hide their activities

While many consider proxies as useful tools to mask their online activities, it has to be presumed that organizations such as the NSA have the ability to track individuals using even multiple instances. The next set of questions skip over the mechanics of how that might be possible (with the clear implication that it is) and jump straight to what is permissible.

[When an actor is]….posting to thepiratebay.org (a foreign web-server)….through multiple proxied hops, are we allowed to back-trace that communication even if it hops through US based proxies?” an NSA worker asked.

“In other words, back-trace the post from thepiratebay.org to a Chinese base proxy which came through a US based proxy, which came through another US based proxy, which came through a Russian based proxy etc”

“Assuming you mean via SIGINT metadata,” came the NOC response, “then SPCMA-trained [Supplemental Procedures Governing Communications Metadata Analysis] analysts would be able to use SPCMA-enabled tools to chain through U.S. based proxies. It is not authorized otherwise.”

While on the one hand these discussions suggest that some kind of effort is being made to protect US citizens from NSA spying, on the other it’s fairly obvious that they are being swept up en masse whether they like it or not.

Furthermore, the odds of being caught up in that dragnet only increase should U.S. citizens dare to become involved in organizations like Wikileaks or use torrent sites including The Pirate Bay. Worryingly, the threshold for becoming categorized as an associate of a “malicious foreign actor” appears to be lower than ever.

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

As evidenced by Google’s Transparency Report the companies behind movies, TV shows and music are desperately trying to do something about that. Many millions of DMCA takedown notices are sent every single week in the hope that by making content at least marginally harder to find, consumers might choose to purchase rather than pirate.

What goes on behind the closed doors of the anti-piracy outfits involved is largely a secret, but for one lucky individual the curtain could soon be lifted.

Warner Bros., a company that generated revenues of $12 billion in 2012, is looking for someone to join their Content Protection and Analytics department. The unit’s stated objective is to protect Warner’s “…film, TV and games content against piracy throughout the entire value chain, with a primary focus on internet piracy in all its forms.”

The entertainment giant is looking for a Systems Manager, a degree-level IT professional with software development experience and a knowledge of SQL, PHP, Kapow, javascript and python. In addition to managing a small team the successful candidate will optimize “WB SHIELD”, Warner’s anti-piracy system focused on discovering and taking down unauthorized content.

To date, Warner Bros. Entertainment has sent around 1.9 million takedowns to Google, although many were handled by outside vendors. Google’s reports accredit around 900,000 directly to Warner, a not inconsiderable amount for a single company.

Other parts of the job include managing SHIELD failures and contributing to the building and maintenance of the company’s infringement scanning and take-down robots.

While Warner sends plenty of notices for content on BitTorrent networks, it’s interesting that the company is also looking to improve its capabilities elsewhere. The person landing the job will be required to work against protection mechanisms being employed by pirates by “developing solutions for dealing with link encryption, captchas and FLASH.”

It’s often suggested that anti-piracy companies tend to focus their protection strategies on “hot” content, meaning that older titles receive less attention. That train of thought is supported somewhat by the requirement that Warner’s new anti-piracy employee will be responsible for ensuring that the company’s “priority film, TV and game titles are covered within SHIELD.”

Finally, Warner’s new employee will be required to conduct analysis of rogue sites and hosting platforms and coordinate that work with other members of the company’s anti-piracy team.

Overall this sounds like a job ideally matched to a tech-savvy former pirate, but whether the company will be keen to employ a poacher-turned-gamekeeper is another question. If they did, however, they definitely would not be the first.

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

This massive network use has received plenty of interest from Internet providers over the years, but AT&T is planning to take it to the next level.

A new patent awarded to the Intellectual Property division of the Texas-based company describes a system that can accurately measure the flow of both legitimate and infringing file-sharing traffic.

Titled “Method and apparatus for automated end to end content tracking in peer-to-peer environments,” the patent covers an advanced monitoring system that can detect how often a certain title is downloaded. AT&T says this information can then be used to address network congestion or counter piracy.

The flow-chart below shows the various steps involved in the detection and tracking process.

The system described by AT&T focuses specifically on torrents, which are gathered from search engines and other websites through RSS feeds. Discovered content is collected in a database and the system then downloads the torrent and records information on the people who are downloading.

In the patent AT&T notes that peer-to-peer traffic accounts for a large percentage of traffic generated on the Internet, some of which results in a loss of revenue for copyright holders.

“For example, some content may be legitimately purchased and downloaded by users via P2P. However, some content may be pirated and illegally copied and distributed P2P violating copyright laws and reducing revenue for the content producers and distributors,” the company explains.

AT&T’s system will be able to detect what is most downloaded on P2P-networks, suggesting that this information can be used to track and counter piracy.

“The present disclosure automatically tracks content that is downloaded in a peer-to-peer environment. In doing so, the present disclosure automatically identifies the most popular content titles to monitor and tracks and identifies a number of unique peers for each of the content titles.”

In addition, there is a content analysis component that will verify whether the downloaded files are indeed what the title suggests. This will be useful to filter out spam files and viruses that are mislabeled as popular videos or music.

“Based upon the verification, the list may be modified if the content titles actually being downloaded do not match the content titles in the list. For example, the content titles in the list may be looking for a recently released movie; however, the actually downloaded content titles may be a television show that had an identical title or may be a peer attempting to disseminate a virus under a disguise of the content title and so forth.”

The patent doesn’t go into detail on the intended purpose of the tracking, but AT&T specifically mentions that it can be used to track infringing downloads and address network congestion.

“The present disclosure may be used to determine which content titles are being illegally distributed and by whom. In another example, the present disclosure may be used to determine which content title downloads are creating the most network congestion. This information may in turn be used for capacity planning and the like,” the patent reads.

While there are many outfits that track BitTorrent and other file-sharing traffic, until now we are not aware of any ISPs that have shown interest in this type of monitoring. AT&T is certainly the first company to be granted a patent for such a specific P2P monitoring system.

It’s worth noting that AT&T participates in the six-strikes copyright alert system where P2P users are also monitored. The main difference is that under that program the monitoring is carried out by a the third-party company which only tracks a list of titles supplied by the MPAA and RIAA.

Whether the provider has intentions to actively scan for and throttle pirated content being shared using BitTorrent is unknown. With the patented system it could certainly do so, and if it targets infringing traffic only it does not violate FCC’s net neutrality rules.

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.

In this interesting video we see the basics of how someone with access to a network can monitor the activities of all users by using the free open source analysis software WireShark.

The tool looks complicated to begin with but with a little perseverance we can begin to understand how our torrent clients – and indeed any network enabled software – try to communicate with the outside world.

Source: TorrentFreak, for the latest info on copyright, file-sharing and anonymous VPN services.