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

On Wed, 21 Dec 2005 19:28:10 GMT, "Eric" <(E-Mail Removed)> 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 (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

How does this fit into the mix ?

..http://www.hamachi.cc/


Jeff Liebermann wrote:
> On Wed, 21 Dec 2005 19:28:10 GMT, "Eric" <(E-Mail Removed)> 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 (E-Mail Removed)
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060 http://802.11junk.com
> Skype: JeffLiebermann AE6KS 831-336-2558

On 22 Dec 2005 00:25:44 -0800, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:

>How does this fit into the mix ?
>http://www.hamachi.cc/

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:
>> On Wed, 21 Dec 2005 19:28:10 GMT, "Eric" <(E-Mail Removed)> 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 (E-Mail Removed)
>> 150 Felker St #D http://www.LearnByDestroying.com
>> Santa Cruz CA 95060 http://802.11junk.com
>> Skype: JeffLiebermann AE6KS 831-336-2558
--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

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

Jeff Liebermann wrote:
> On 22 Dec 2005 00:25:44 -0800, "(E-Mail Removed)"
> <(E-Mail Removed)> wrote:
>
> >How does this fit into the mix ?
> >http://www.hamachi.cc/
>
> 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.

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

On 23 Dec 2005 23:01:04 -0800, "Joe Santa"
<(E-Mail Removed)> wrote:

>Jeff Liebermann wrote:
>> On 22 Dec 2005 00:25:44 -0800, "(E-Mail Removed)"
>> <(E-Mail Removed)> wrote:
>>
>> >How does this fit into the mix ?
>> >http://www.hamachi.cc/
>>
>> 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.

>Care to elaborate ?

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

>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' ?

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:
http://www.hamachi.cc/security
"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.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Fri, 23 Dec 2005 23:45:28 -0800, Jeff Liebermann
<(E-Mail Removed)> wrote:

>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?
(...)

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.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann wrote:

> 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?

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.
--
derek