VPN -- the next consumer "turnkey"?

Yes, I think it will be a standard feature. What was stopping it from becoming commonplace was: 1. Limitations in CPU horsepower and available memory. VPN encryption and processing is a rather large resource hog. However, recent advances in processor performance, dedicated encryption chips, and cheap DRAM have made VPN more accessible to the GUM (great unwashed masses). 2. Lack of a standardized and free client. Windoze XP supports both IPSec and PPTP out of the box. With a little effort, L2TP also. However, configuration is complex, and Microsloth offers no diagnostics worthy of the name. 3rd party VPN clients work just fine, but cost money. I expect some dramatic improvements in the quality and ease of installation for VPN clients to come from the file sharing crowd, as they seem to be pioneering the technology at this time.
Nope. VPN encryption and replay prevention does a nice job of securing a wireless LAN. The local hospitals have such a system, where there is no encryption key, but you need a VPN client or SSL browser to use the system.
There are a few places where it's benificial. 1. If you want to protect the initial connection to the VPN or SSL server URL or IP address. This is sent unencrypted.
2. If your access point has no provisions for preventing its use as a repeater. The local brats converted my neighborhood wireless LAN into their personal game network. None of the traffic hit the internet so the router was useless. They didn't even use TCP/IP as any protocol will go through a bridge. I eventually solved the problem by enabling "AP Protection" (which is really "client protection") and left encryption off.
3. Accidental connections are common. They don't really do any damage but they sure mess up my log files. Encryption will keep them out.
4. WPA Encryption is intimately entangled with authentication. If you need or want authentication outside the VPN, via perhaps a RADIUS server, then encryption might be a good idea to prevent sniffing and password recovery. Strictly speaking, VPN provides more than enough authentication so it's not really necessary unless you want both public and private access via a single access point. If you authentiate with the RADIUS server, you go to the internet but not the internal LAN. If you authenticate with the VPN, then you go to the internal LAN with a different gateway to the internet.
Reply to
Jeff Liebermann
Loading thread data ...

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
Reply to
Eric
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.
> > >Jeff Liebermann wrote: >> >> >> >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"? >> >> Yes, I think it will be a standard feature. What was stopping it from >> becoming commonplace was: >> 1. Limitations in CPU horsepower and available memory. VPN >> encryption and processing is a rather large resource hog. However, >> recent advances in processor performance, dedicated encryption chips, >> and cheap DRAM have made VPN more accessible to the GUM (great >> unwashed masses). >> 2. Lack of a standardized and free client. Windoze XP supports both >> IPSec and PPTP out of the box. With a little effort, L2TP also. >> However, configuration is complex, and Microsloth offers no >> diagnostics worthy of the name. 3rd party VPN clients work just fine, >> but cost money. I expect some dramatic improvements in the quality >> and ease of installation for VPN clients to come from the file sharing >> crowd, as they seem to be pioneering the technology at this time. >> >> >Q: Doing the VPN thing (software), is OTA encryption "really" needed? >> >> Nope. VPN encryption and replay prevention does a nice job of >> securing a wireless LAN. The local hospitals have such a system, >> where there is no encryption key, but you need a VPN client or SSL >> browser to use the system. >> >> >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?) >> >> There are a few places where it's benificial. >> 1. If you want to protect the initial connection to the VPN or SSL >> server URL or IP address. This is sent unencrypted. >> >> 2. If your access point has no provisions for preventing its use as a >> repeater. The local brats converted my neighborhood wireless LAN into >> their personal game network. None of the traffic hit the internet so >> the router was useless. They didn't even use TCP/IP as any protocol >> will go through a bridge. I eventually solved the problem by enabling >> "AP Protection" (which is really "client protection") and left >> encryption off. >> >> 3. Accidental connections are common. They don't really do any >> damage but they sure mess up my log files. Encryption will keep them >> out. >> >> 4. WPA Encryption is intimately entangled with authentication. If >> you need or want authentication outside the VPN, via perhaps a RADIUS >> server, then encryption might be a good idea to prevent sniffing and >> password recovery. Strictly speaking, VPN provides more than enough >> authentication so it's not really necessary unless you want both >> public and private access via a single access point. If you >> authentiate with the RADIUS server, you go to the internet but not the >> internal LAN. If you authenticate with the VPN, then you go to the >> internal LAN with a different gateway to the internet. >> >> -- >> Jeff Liebermann snipped-for-privacy@comix.santa-cruz.ca.us >> 150 Felker St #D
formatting link
Santa Cruz CA 95060
formatting link
Skype: JeffLiebermann AE6KS 831-336-2558
Reply to
Jeff Liebermann
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
Reply to
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
Reply to
Joe Santa
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:
formatting link
"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.
Reply to
Jeff Liebermann
(...)
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.
Reply to
Jeff Liebermann
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.
Reply to
Derek Broughton

Site Timeline

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.