Security: VPN vs SSH vs Proxy

These attacks-with-perfectly-legitimate-implementations will affect both SSL/TLS and SSH equally since they don't actually exploit the algorithm being used.

Basically, some sort of device or application [let's call it snooper] sits in between you and the secure server you're connecting to [let's call it secureBox]. When you try and establish a secure connection to secureBox, snooper intercepts the request and then establishes its own secure connection between it and secureBox. Your local application [eg. puTTY, web browser, etc] thinks it's made a secure connection to secureBox but it's actually only made a secure connection to snooper. Overall, the connection behaves the same but snooper can see all of the traffic going through it.

To do this, though, snooper needs to feed you its own encryption key so it can decrypt the data you're sending to it. So, essentially, one key is used for the session between you and snooper, and another key is used between snooper and secureBox.

How it should look normally:

Code:

=== - encrypted connection
.key - key used to encrypt connection

Code:

              :(
               |
           [snooper]
[you]=== secureBox.key ===[secureBox]

This is how it looks when snooper gets in between:

Code:

                           >:)
                            |
[you]=== snooper.key ===[snooper]=== secureBox.key ===[secureBox]

This is why applications like PuTTY, and your standard web browser, will alert you in some way if it suspects someone is doing this. PuTTY will alert you if the key changes from what it's expecting but you must have connected to the server successfully previously for this to occur. PuTTY will show you the server's key when you first connect, though, so you should be confirming its validity with the server administrator.

Your web browser, on the other hand, will display an alert advising that the certificate presented does not appear to match the web site you're trying to access. In an enterprise environment [which is where devices like these are deployed], the device's certificate will already be trusted in your web browser so you won't get this notification. You can still check the certificate details, though, to see who issued it and who it is valid for.

The Wireshark procedure listed involves obtaining private keys. This is a Very Bad Thing and means you cannot trust the server at all, even if you can verify that is who you're connected to, since an attacker can now eavesdrop passively without fiddling with your session.

Changing the type of encryption used won't help in either situation you since the issue is not a flaw in the algorithm being used but an exploitation of the trust relationship between you and the server.

Hope this helps

 

Maybe VPN is better regarding third party applications issues with web browsing. But VPN has a problem you don't see with SSH/proxy.

Sometimes you don't want to use your VPN for some websites or some applications and use it in the same times for others. There is no reasons we totally trust our VPN providers.
For example I can want to download something anonymously on P2P and in the same times talk on IM or make purchases, connect to my personal blog or facebook etc. And some of these connections aren't encrypted.

Even with web browsing, I can want to stay anonymous only for some websites. It's not only a question of trust. Some website are easy to use with a direct connection (some refuses IP ranges of known vpn providers, some others are faster to browse etc.)

After using many VPNs I now choose SSH for needs + Foxyproxy + Noscript which seems to be more adapted to my needs.

 

Steve, I've looked again at your directions for leak-proofing a Windows machine. I think calling it "dead to the world" is not entirely correct. It's certainly leak-proof while the VPN is running, but when/if the VPN cuts out, I would call it "half dead" or leak-resistant at best. Any application that doesn't do local DNS requests will bypass this technique if the VPN cuts out.

This includes torrent apps, which a lot of people here are most concerned about. Once you're connected to certain IP addresses through your VPN, once the VPN cuts out, your computer will connect to those same IP addresses without the VPN. Another example of an app bypassing this technique is Tor. Tor will connect straight out through this because it doesn't do local DNS requests. On a positive note, this technique will probably work for a browser virtually every time.

I've come to the conclusion that a good outbound software firewall is the only viable way to totally leak-proof a VPN (because of the lost connection issue). It's the same as with application-level programs like Tor. A firewall is the best solution there too. However, with Tor, firewall configuration is easier than with a VPN, from my experience.

I'll probably start a new topic on this at some point because it's too big to cover here. I think your technique is a useful adjunct to a firewall, but I don't believe it to be either necessary or sufficient. I do believe that a properly configured firewall is both necessary and sufficient. I personally would use your technique plus a firewall for purposes of redundancy. Also, while the technique you describe probably works for Xerobank and some other VPNs, it doesn't work for every VPN. But there's a simple modification described on the perfect-privacy forums that should make it universal. Any thoughts? I think this is an important issue.

 

Question to all what about your MAC address? Does your Mac address get leaked out when using VPN or SSH? do you have to spoof your Mac address?

 

No, it doesn't. To the best of my knowledge, the MAC address of the modem and of the device connected to the modem (e.g. router) can be obtained by your real internet service provider (ISP). And all your ISP knows is that you're connected to a VPN provider, hence it's not a security issue. You can always spoof the MAC address of the device connected to the router for added security, although it's probably not necessary. Neither the VPN provider nor the target website can get your real MAC address. However, the TAP adapter that is created by OpenVPN also is assigned a MAC address. I believe this MAC address is known by the VPN provider, but not the target website. This isn't a security issue either, because the VPN provider already knows your real IP address, which always trumps a virtual MAC address. If you trust them not to keep logs, then it's obviously not a security issue.

Just to be clear, I was only referring to the directions for configuring a Windows machine. I wasn't referring to the Cryptorouter at all. To my knowledge, an external router should be leak-proof out of the box.