Can a secure VPN connection be trusted if made over unsecure wifi?

[taltamir]

If I am at a hotel or an airport and connect via an unsecured wifi, can I protect my data via encryption?
I am NOT trying to prevent the provider analyzing the packets, nor protect against keylogger viruses, nor against being hit with a phishing attack by a shady website.
Only thing I am trying to prevent here is a random individual in the next room with the right software sniffing packets and getting my secure info. Say, if I connect to my bank or make a credit card purchase, etc.

Would this:
https://www.torproject.org/about/overview.html.en
Or this:
https://www.goldenfrog.com/vyprvpn/vpn-service-provider

Help with that?

 

[llee]

I see the point of using a VPN as allowing one to encrypt your data in an unsecured location. The services that you listed are essentially consumer friendly alternatives to setting up your own VPN.

 

[pandemonium]

If your data is encrypted, it's encrypted regardless of being on an open or secure connection. The secure connection will simply add another layer of protection.

 

[taltamir]

I see the point of using a VPN as allowing one to encrypt your data in an unsecured location. The services that you listed are essentially consumer friendly alternatives to setting up your own VPN.

thank you for the info.

If your data is encrypted, it's encrypted regardless of being on an open or secure connection. The secure connection will simply add another layer of protection.

but can't the encryption key for my bank or gmail be intercepted on an unsecure connection?

For example, my bank uses RSA key exchange mechanism, wouldn't the act of exchanging a key over an unsecure network compromise said key?

 

[seepy83]

For example, my bank uses RSA key exchange mechanism, wouldn't the act of exchanging a key over an unsecure network compromise said key?

When the key exchange happens, your password is encrypted to the recipient's (bank's) Public Key. The only way to decrypt it is to use the Private Key that is (hopefully) only known by the recipient.

Edit: For good measure, I need to say it - Don't connect to unsecure wifi because you're just asking for trouble. Someone talented enough could potentially stage a Man In The Middle attack and compromise your passwords. Only connect to trusted wifi. Buy a 3g/4g card, or tether to your smartphone so you don't need to share an unsecure connection with other people.

 

[dawks]

When the key exchange happens, your password is encrypted to the recipient's (bank's) Public Key. The only way to decrypt it is to use the Private Key that is (hopefully) only known by the recipient.

Edit: For good measure, I need to say it - Don't connect to unsecure wifi because you're just asking for trouble. Someone talented enough could potentially stage a Man In The Middle attack and compromise your passwords. Only connect to trusted wifi. Buy a 3g/4g card, or tether to your smartphone so you don't need to share an unsecure connection with other people.

This.

If you're establishing the VPN connection over the unsecured WiFi, its entirely possible for someone to hijack the connection. A way to add more strength to a VPN connection is by using certificates, and taking the time to verify the certificate is valid and issued to the server you're trying to connect to. Certs allow identification for both ends. Adding another factor for authentication such as a 1-time token can help ensure the attacker can't regain access at a later time as well. But its never 100% fool proof if you can't ensure the line is not compromised.

 

[taltamir]

When the key exchange happens, your password is encrypted to the recipient's (bank's) Public Key. The only way to decrypt it is to use the Private Key that is (hopefully) only known by the recipient.

wouldn't such a key be, by definition, known to all (or at least all who are listening)?

and how would you even begin to stage a man in the middle attack on an encrypted VPN connection? you would have to know what is being transmitted, and you cannot intercept the keys since they have been preshared by the software... Err, the keys ARE preshared by the software (which I should do over a secure connection), right?

Can I set up my own private encrypted VPN with my computer and make the encryption keys for said connection ahead of time over the LAN?

 

[seepy83]

wouldn't such a key be, by definition, known to all (or at least all who are listening)?

The Public Key is (or, rather, can be) known by everyone...hence the name public. The Private Key is only known by the person or entity that is receiving the encrypted data. Data encrypted by the Public Key can only be decrypted using the Private Key. This is the cornerstone of how PKI works.

I don't have time to comment on the rest of your post right now...maybe someone else can chime in...

 

[dawks]

wouldn't such a key be, by definition, known to all (or at least all who are listening)?

and how would you even begin to stage a man in the middle attack on an encrypted VPN connection? you would have to know what is being transmitted, and you cannot intercept the keys since they have been preshared by the software... Err, the keys ARE preshared by the software (which I should do over a secure connection), right?

Can I set up my own private encrypted VPN with my computer and make the encryption keys for said connection ahead of time over the LAN?

The main time you're exposed to attack is during the setup of the VPN. You're right in that once the connection is established, its pretty secure at that point (provided you're using strong software with no known vulnerabilities).

But the real problem is during creation of the VPN Tunnel. I'm not claiming to be a full expert on this.... If someone is on that Wifi, listening to everything going across, they can sneak in and do a few things. One would actually involve intercepting the packets from you, the client and the server, then the attacker can insert themselves inside the tunnel and hence man-in-the-middle. They have to do this while the connection is being setup, so then they know the encryption being used. I think you'd need to do arp-spoofing/poisoning for this.

I guess the main thing to take away from it, is when setup properly, breaking a VPN over open Wifi IS possible, but very difficult. Secure Wifi (WP2) makes an attack less likely, but there is still the risk that someone (access point owner for example) could have something physically attached to the network that could attempt to exploit a VPN tunnel.

In short, unless you own the network, you can never be 100% secure.

 

[Nothinman]

If I'm not mistaken, a MITM attack on HTTPS, SSH, etc would present itself as an invalid cert, new ssh public key, etc since they're essentially becoming a proxy between you and the host. So there should be some warning unless the attacker can also manage to get your client to blindly accept the bad/new cert/key.

In short, unless you own the network, you can never be 100% secure.

And that includes the Internet. Open wifi is just easier for attackers to tap into, they could still physically plug into any of a dozen ISP networks between you and your bank if they really wanted.

 

[taltamir]

If I'm not mistaken, a MITM attack on HTTPS, SSH, etc would present itself as an invalid cert, new ssh public key, etc since they're essentially becoming a proxy between you and the host. So there should be some warning unless the attacker can also manage to get your client to blindly accept the bad/new cert/key.

And that includes the Internet. Open wifi is just easier for attackers to tap into, they could still physically plug into any of a dozen ISP networks between you and your bank if they really wanted.

thanks for the info nothinman.
Is there a way to set it up so that there is no key exchange on handshake?
Say, have my home PC write a key to a USB stick, then place said stick in the my laptop, use that to form an encrypted VPN where the handshake never actually transfers the key?

a man in the middle will only see undecipherable gibberish unless he infects one of my computers with a virus that steals the key.

Am I completely off my rocker or would that method work to making an open wifi as secure as my home connection (where the PC to which I VPN is located)

 

[Nothinman]

thanks for the info nothinman.
Is there a way to set it up so that there is no key exchange on handshake?
Say, have my home PC write a key to a USB stick, then place said stick in the my laptop, use that to form an encrypted VPN where the handshake never actually transfers the key?

a man in the middle will only see undecipherable gibberish unless he infects one of my computers with a virus that steals the key.

Am I completely off my rocker or would that method work to making an open wifi as secure as my home connection (where the PC to which I VPN is located)

I'm really rough on my public key encryption and such, but there's always some key exchange going on because even with a pre-shared key, certificate, etc for authentication the keys are regenerated periodically. The same key isn't used for the entire session so that it's that much harder to break.

 

[taltamir]

Wouldn't those subsequent key exchanges occur over an encrypted connection though?

what about something like this http://en.wikipedia.org/wiki/SecurID

 

[Sureshot324]

Some of the places i've worked have their wifi completely unsecured, (no wpa or wep) but the ONLY thing you can connect to on wifi is the VPN. This is because even wpa2 can be hacked, but a good VPN is next to impossible to hack.

 

[Nothinman]

Wouldn't those subsequent key exchanges occur over an encrypted connection though?

what about something like this http://en.wikipedia.org/wiki/SecurID

Yes and the rekeying serves two purposes. To make it more difficult to brute force the keys by limiting the amount of data you encrypt with any 1 key and to change the key in case one was lost, guessed, etc.

RSA tokens aren't cheap and they aren't infallible either, in fact RSA was broken into just this year and I don't think they ever said what information was taken. If it was the seeds for a set of tokens, the person with that information could theoretically have an app that generates the same numbers as those tokens. And if the WSJ article is right, RSA offered nothing in the way or reassurance that their products or their client's networks are still secure.

 

[imagoon]

The keys that you are worried about transmitting are open any way. PKI works on the math that there are key pairs that can be used to encrypt and decrypt data. In PKI (certificates are often the "keys" for today) the public key can encrypt data that then only the private key (should) decrypt and vis versa (private key encrypted data can be decrypted with the public key.) This allows you to have a public key, encrypt the data and only allow the person or entity you want to decrypt it because the private key should never be released and be secret. Part of the public aspect should be the ability to verify the public key either via a key store (IE verisign etc) or by the person giving it to you. So for a VPN tunnel to say your home network you would:

Generate a key pair for your devices (vpn.) The private key is in the device while you copy the public key yo your laptop (or give it to friends if you wanted to share.) You then generate your own key pair. You give the VPN your public key and you keep your private key (in this case on your laptop.)

Main part here is at this point both 'parties' have a the public key of the other and it has been 'verified' because you gave each other the key. Banks etc would use Verisign etc to let you verify the key. This lets you:

Try to connect to the VPN: Your client uses the VPN public key to a) verify the key, if the keys don't match there is a MITM potentially. The vpn client will encrypt some data with your private key, sign it or encrypt it with the VPN public key and send it back. The VPN should get the data, decrypt it with its private key and decrypt it again using your public key then reply back doing the reverse. This data exchange verifies that everyone has the keys they need and verifies identity. After that the tunnels typically are single encrypted each direction.

The part to note is the authentication occured with both public and private parts that can't be "sniffed" and in theory can't be guessed.

Not sure if that makes sense, really cool idea and takes a bit to get it down. This is the bases of certificate based encryption.

 

[dawks]

Some of the places i've worked have their wifi completely unsecured, (no wpa or wep) but the ONLY thing you can connect to on wifi is the VPN. This is because even wpa2 can be hacked, but a good VPN is next to impossible to hack.

The only known vulnerability with WPA2 right now, is a brute force password attack. Provided you use a strong password, WPA2 is very secure.

The best someone can do is capture some packets, then just try slamming away with passwords and hope they get some cleartext out of it.

Check out this neat tool, which is not a password strength meter, but only gives you an idea of how long it might take to brute force a password. If you use upper and lower case letters, numbers and symbols, given enough length, you can get a very secure password. https://www.grc.com/haystack.htm

The password I'm using has 38,136,800,256,227,897,272,064,940,472,866,626,495 possibilities for example.

I'd recommend reading the whole page. Steve has an interesting point in that a password doesn't particularly need a whole lot of entropy to be secure. More important is length (provided you use a large enough character library).

 

[XX55XX]

The only known vulnerability with WPA2 right now, is a brute force password attack. Provided you use a strong password, WPA2 is very secure.

The best someone can do is capture some packets, then just try slamming away with passwords and hope they get some cleartext out of it.

Check out this neat tool, which is not a password strength meter, but only gives you an idea of how long it might take to brute force a password. If you use upper and lower case letters, numbers and symbols, given enough length, you can get a very secure password. https://www.grc.com/haystack.htm

The password I'm using has 38,136,800,256,227,897,272,064,940,472,866,626,495 possibilities for example.

I'd recommend reading the whole page. Steve has an interesting point in that a password doesn't particularly need a whole lot of entropy to be secure. More important is length (provided you use a large enough character library).

Hmm. The password I use to secure my main TrueCrypt cache has 11,817,
599,480,465,213,050,980 possibilities. Is that bad?

 

[dawks]

wouldn't such a key be, by definition, known to all (or at least all who are listening)?

and how would you even begin to stage a man in the middle attack on an encrypted VPN connection? you would have to know what is being transmitted, and you cannot intercept the keys since they have been preshared by the software... Err, the keys ARE preshared by the software (which I should do over a secure connection), right?

Can I set up my own private encrypted VPN with my computer and make the encryption keys for said connection ahead of time over the LAN?

While not technically the same, here is a tool for stripping HTTPS and intercepting the 'encrypted' data. The concept for hijacking a VPN tunnel is much the same. http://www.thoughtcrime.org/software/sslstrip/

Hmm. The password I use to secure my main TrueCrypt cache has 11,817,
599,480,465,213,050,980 possibilities. Is that bad?

You're Doomed!!

 

[XX55XX]

Guess I'm going to replace all of my 12-letter passwords with 15-letter ones now.

 

[Mark R]

While not technically the same, here is a tool for stripping HTTPS and intercepting the 'encrypted' data. The concept for hijacking a VPN tunnel is much the same. http://www.thoughtcrime.org/software/sslstrip/

Not really. The SSLStrip software acts as a web proxy, that changes https URLs into http URLs, and hopes that the user doesn't notice that their online banking is being performed over a regular http connection (which is then intercepted), rather than a secure connection.

Most VPN software will insist on an encrypted connection (i.e. it won't run if it can't secure the connection) so is resistant to this type of attack.