Re: VPN -- the next consumer "turnkey"?

On 23 Dec 2005 23:01:04 -0800, "Joe Santa"
<tmxkqzshwrtavy@xxxxxxxxxxxxxx> wrote:

>Jeff Liebermann wrote:
>> On 22 Dec 2005 00:25:44 -0800, "frankdowling1@xxxxxxxxx"
>> <frankdowling1@xxxxxxxxx> 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 jeffl@xxxxxxxxxxxxxxxxxxxxxx
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
.

Relevant Pages

  • Re: UnauthorizedAccessException when using MSDTC
    ... dispatcher2 is the user logged on the client pc. ... Event Source: Security ... Object Server: SC Manager ... Primary Domain: BLITZ ...
    (microsoft.public.data.ado)
  • Re: Routing and Remote Access - Authentication Failure
    ... because the real client computer can tunel through it's local NAT router, ... travel the Intrenet, join the VPN and access the server, when this feature ... Their security system decided that the server was trying to steel ...
    (microsoft.public.windows.server.networking)
  • Re: WCF security advice (and clarification) needed
    ... You, the client, resolve the foo.mycompany.com hostname within your ... TCP/IP) with that ticket as the security token. ... There are two parties participating in a security scenario, the server ... HTTP supports other authentication ...
    (microsoft.public.dotnet.framework.webservices)
  • RE: Problems with security requirements in Windows WorkGroups.
    ... "A remote side security requirement was not fulfilled during authentication. ... small chat application between a client and a server ... When I try to use the TCP channel I get the error (with NO inner exception ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: VPN -- the next consumer "turnkey"?
    ... > authentication purposes during the login sequence. ... the client submits its Hamachi IP and uses its private key ... The server verifies ...
    (alt.internet.wireless)