VPN -- the next consumer "turnkey"?

It seems VPN is making it's way into more and more of the consumer wireless products. Wondering if eventually all the consumer junk will just incorporate VPN and it'll be a standard "turnkey"?

Q: Doing the VPN thing (software), is OTA encryption "really" needed? If my thought process is right, it seems not using OTA encryption at all might be be an advantage if you are doing VPN, anyway. (Or, even just using WEP -- not to really add any "security", but simply just to make the wireless network "appear" less attractive?)

Cheers, Eric

How does this fit into the mix ?

.

Jeff Liebermann wrote:

That's one of the VPN filesharing systems I was refering to. However, it was NOT intended to provide secure access and therefore has a fundamental flaw in that it requires the connection be established through their directory server. Such directory servers are acceptable for instant messaging and VoIP, but have some rather nasty security implications. However, if I ignore this issue, the basic function, setup, operation, and reliability is a major improvement over the typical VPN client.

However, it's a waste of time if the wireless access point has a built in VPN server. For example, the various alternative firmware releases for the WRT54G have a built in PPTP server. Custom compiles offer an IPSec server. I use the PPTP VPN feature to connect to my wireless router and from there to the rest of my network. I use totally insecure Windoze file sharing with impunity because the VPN provides the necessary security. PPTP setup is trival at the client end and comes with every Windoze distribution. Works just fine for me.

However, it doesn't do anything for wireless hot spot security. A hot spot owner could demand that customer install a client or setup a PPTP VPN to their wireless router, but that would probably cause more trouble than it's worth. I've seen temporary clients delivered via JAVA that work but are slow. Google has taken a step in the right direction by demanding that their wireless hot spot users use their VPN client. VPN's are no big deal if terminated at a trusted ISP or

3rd party provider, but most hot spots don't have the facilities or want to pay for the service.

I don't know if one solution will prevail for VPN's. However, I can predict that if Microsloth jumps into the VPN client game, the defacto standard will revolve around whatever they deliver. Meanwhile, gamers, file sharing users, hot spots, businesses, and home users will each develop their own VPN solutions, customized to only deal with their individual problems.

Hi Jeff,

Thanks for the informative reply!

(I do read everything, even if it does take several days to reply.)

RE: local brats using your WLAN as their "bridge". Now thats interesting! Never even thought about, putting a whole new network (Netbeui, IPX, ect) through an already existing pipe. Yep, I'd be annoyed too. Gotta give them a few points for creativity, I guess though. LOL

Cheers!

-Eric

Care to elaborate ?

Centrally managed security frameworks can easily accomodate the requirement of no prior client-server trust. Hamachi is just one example of such framework. Can you perhaps list these unaviodable 'nasty security implications' ?

Thanks

No, not really. I'm not a security expert. There are others that are more qualified to pass judgement on security models.

Sure. Please note that I didn't use the term "unavoidable". You added that. Also note that I said "implications" which means that the model is defective, not the implimentation.

See:

"A Hamachi system is comprised of backend servers and end-node peer clients. Server nodes track client's locations and provide mediation services required for establishing direct peer-to-peer tunnels between client nodes."

I don't like the idea of requiring Hamachi to establish the connection. I can do the same thing using static IP's or dynamic dns services without providing Hamachi with a list of client IP's. If all I need is a secure connection from a remote office or a mobile client, I don't need Hamachi's central management server. If the system could establish a connection directly, by specifying an IP address or URL, I would not complain. But, there's no such provision.

Please note that this could easily be fixed. However, since Hamachi was really designed as a peer-to-peer network for file exchange, where a central server location server and a distributed directory are its main features. Whether this can successfully mutate into a secure client VPN system will largely depend on the abilities and immagination of the developers.

As for a "centrally managed security framework", I note that: "The client also generates an RSA key pair, which is used for authentication purposes during the login sequence. The public key is passed to the server once - during the first connection when creating new account.

To login, the client submits its Hamachi IP and uses its private key to sign server's challange as described below. The server verifies the signature and this authenticates the client."

What the hell is the Hamachi central server doing passing the users private security key around when this should never be done even between clients? If this is to authenticate the client, they could use a hash code between the public key and the private key, instead of the actual private key to authenticate. How do I know that they're not collecting RSA private keys?

I'm also not thrilled with the concept of having the certificate authority and authentication server, also provide the keys. This really should be handled by a third party to insure trust. In the case of peer to peer file sharing, it probably doesn't matter. If I want to use their system for corporate security, no way.

(...)

Argh, I got it backwards. (Late night, tired, marginal competence, etc). The client creates both keys and the Hamachi server collects only the public key, not the private key. That's acceptable and will work. I still don't like the idea of Hamachi acting as a certificate authority, but that can later be delegated to a 3rd party. My apologies.

However, it used for a commercial VPN security solution, it would have the same single point of failure that using Verisign for a certificate authority. If the certificate authority server is unavailable, so is the connection along with the "web of trust" model.

That's not how I read that Jeff. Hamachi's server sends a "challange" [sic

- I lose faith in websites with bad spelling], the user "signs" it - it seems to me they really mean encrypts it - and then sends it back. Hamachi will then decrypt it with the user's public key. No actual sending of a private key.