Will using public VPNs expose my user information to the VPN owners?

1

2

I am accessing the Google Play Store from a VPN software which will supposedly mask my IP to make it appear that I'm in the US (for country restrictions). My question is, will logging in to Google, or any website for that matter, while connected via VPN will expose my user information (email and password) to the VPN owners in some way or another? If so, are there any steps that I can do to prevent that while still use the VPN?

Propeller

Posted 2012-08-06T19:05:33.657

Reputation: 1 055

Answers

3

That depends on the connection type.

  • Any information sent encrypted cannot be read by any computer in the trace route, except – of course – the endpoint. It makes no difference which type of internet connection you use. That includes VPNs.

    So, if the website you're visiting uses HTTPS, the VPN provider will have no access to your personal information.

  • However, if the website requires information sent in plaintext, the VPN provider has to send that information unencrypted and – therefore – has to have access to it.

    If the website you're visiting uses HTTP, the VPN provider has access to your personal information.

There's nothing special about VPNs in this regard. Every non-encrypted connection allows every computer in the trace route to sniff it. Your connection to the VPN should always be encrypted, but that doesn't matter if the connection between the VPN and the website isn't.

Dennis

Posted 2012-08-06T19:05:33.657

Reputation: 42 934

So if I understood it correctly, as long as the website uses https protocol, I'm safe from snooping. Right? I'm not sure I understood this part "if the website requires information sent in plaintext". Are there instances when a secure website asks information to be sent in plaintext? – Propeller – 2012-08-06T19:35:31.450

[I]f the website requires information sent in plaintext refers to the second case. You can't send encrypted information over HTTP, for example. If your browser displays a https:// in the address bar, the information should get sent encrypted. What's important here is the protocol of the destination. For example, it's possible to embed a form with a HTTP action in a page retrieved over HTTPS. That, however, make no sense and is very unlikely to happen. – Dennis – 2012-08-06T19:39:20.353

Just make sure that the VPN provider doesn't require you to install a certification authority certificate in your web browser. If they do, they can perform a seamless Man in the Middle attack against you by pretending to be in the signing chain of the original request, but instead they negotiate the request on your behalf and can see both ends unencrypted. For this reason it is generally a bad idea to install custom software to use a public VPN; it may "sneak" such a certificate in. Instead, download bog standard VPN software such as OpenVPN and configure it yourself. – allquixotic – 2012-08-06T19:46:57.910

Good point, @allquixotic. There's also nothing special about VPNs in this regard. Don't ever install a self-signed certificate that you didn't sign yourself. – Dennis – 2012-08-06T19:51:10.540

Also, the whole idea of a public VPN scares me. If you really need a VPN, provision it yourself by paying for a virtual private server -- they are very affordable, especially if you go with a cloud provider that charges you by the hour... just turn it off when you're sleeping and you'll save a ton of money. – allquixotic – 2012-08-06T20:03:52.857

@allquixotic: Well, that simply shifts the trust from the VPN provider to the VPS provider. – Dennis – 2012-08-06T20:06:29.257

And it also shifts the trust from a free service provider to one that not only costs money, but is trusted by many large corporations and governments. I'm thinking of a particular VPS provider right now, though; of course you can buy a VPS from a disreputable provider that will steal your info. But I don't know of any truly reputable public free VPNs. I'd trust my financial data and business data with certain ones of the VPS providers however. – allquixotic – 2012-08-06T20:08:16.607

0

Many websites (and non-HTTP-based services such as games) that require some form of authentication, do not require or even allow encryption to be used. Common examples where no encryption is used for authentication:

  • IRC (some networks support SSL, but a very small minority of networks/users actually avail themselves of it)
  • Multiplayer Game servers over UDP, for example MMORPGs, first person shooters, etc.
  • Most "forum" websites that do not collect credit card information do not use any form of encryption (you can tell by the http rather than https in the address bar)
  • Superuser and the stack exchange websites in general

Even if a compromised account on one of these services isn't particularly harmful to you, you should still be really careful: if your email address and/or password used are similar to or identical to passwords you use at valuable websites (Amazon, your bank, your email, etc), then sending those valuable passwords in the clear is a huge risk.

Personally, I use a unique password and often a different email address for every service I use that is in any way tied to my finances, business, or personally identifiable information (social security number, date of birth, etc). For less meaningful websites such as forums, I sometimes do use the same password, but I only overlap passwords between equally-meaningless accounts, not between valuable and non-valuable ones.

Google Play in particular should use SSL, because Google has adopted a policy that SSL is enabled by default whenever you are connecting to Google with a service that involves your Google Account. That's a pretty obvious and justifiable decision: basically, the way people are tied into Google these days, access to a Google Account means you gain access to their email, their documents, their purchased applications, their shopping history, and you can even do things like buy apps and use them, or buy things through Google Checkout and have them shipped to you. So the stakes are high enough that you have to try pretty hard to access any Google-authenticated service over regular HTTP these days.

If you're sticking to the plain old web (everything over http or https and no online games or custom apps that don't use a web browser interface), you can very easily tell whether the connection is "snoopable", provided that you aren't being subjected to a certificate authority man in the middle attack: just ask your browser for more information about the https encrypted connection, and make sure that the certificate chain is one that you trust (it should consist of publicly-verifiable root CAs who you can verify by googling their names). The way to get more information about your https connection is web browser-dependent, but it generally involves clicking on a lock icon or clicking on the address bar.

allquixotic

Posted 2012-08-06T19:05:33.657

Reputation: 32 256

By the way, Superuser and other SE sites use SSL to send the password when logging in. The log in page contains an inline frame pointing with source https://openid.stackexchange.com. However, your email address is exposed if you visit your profile. – Dennis – 2012-08-06T20:02:55.067

But they still send authenticated cookies in the clear. Someone could impersonate you if they were able to see your network traffic at the IP level because you send your cookies with every GET / POST request. It absolutely has to be this way; how else would SE know that you're actually you? Anyway, it's not a huge deal as long as your SE account doesn't involve some kind of insane administrative privilege like a moderator status or Jeff Atwood or something. – allquixotic – 2012-08-06T20:05:41.140