A simple, solid and stable P2P Bidirectional NAT Traversal te chnique for RealVNC users...

[Alex Pankratov]

Khm .. I can't seem to find a description on how exactly GetEngaged
works, so I will tell how Hamachi operates and leave it to you to
compare it to Kaboodle.

Say we have two clients A and B, and the server S. First A talks to
S and S discovers A's location. Then B talks to S and S now knows
B's location. Then S tells A B's location and B - A's, and then
A contacts B and they establish secure tunnel for the rest of A-B
traffic.

Sounds trivial, but with Hamachi both A and B can be behind their
own NAT devices. Or only A may be, but B be initiating the tunnel
setup.

Alex

John Aldrich wrote:

> Ok. Interesting point about the third node... but I thought you needed a
> proxy server for Hamachi as well, no? 
> 
> In your first email to the list (that I have) you said:
> "Mediation server is NOT in the middle of the connection. All it
> does is allows clients locate their peers and learn their external
> (routable) IP/port numbers. The clients then hook up on their own
> and the rest of the traffic flows directly between them."
> 
> Does that mean that you do NOT use a "proxy" server in the middle?
> 	John
> 
> -----Original Message-----
> From: Alex Pankratov [mailto:ap "at" hamachi.cc]
> Sent: Wednesday, March 02, 2005 12:09 PM
> To: John Aldrich
> Cc: vnc-list "at" realvnc.com
> Subject: Re: A simple, solid and stable P2P Bidirectional NAT Traversal
> te chnique for RealVNC users...
> 
> 
> http://www.kaboodle.org/KaboodleProxy.html says -
> 
> 	".. to find and connect with each other, by enabling
> 	    connections through an echoServer"
> 
> which most likely means that they are relaying traffic through a
> third node. This is so last century :) Hamachi is p2p and this
> would probably be the biggest difference.
> 
> Alex
> 
> PS (rather big one)
> 
> I have to disagree that having sources open makes the client
> any more _trustworthy_ than getting it in a binary. It makes it
> that much easier to debug, to change or to admire internal beauty,
> but a complete code audit will cost you a lot.
> 
> IMO people tend to think that if an author opened the sources,
> there should be no evil there as presumably the code will get
> peer reviewed. And the very fact of a possible peer review would
> keep an author from planting nasty stuff into the code and thus
> make O/S code trustworthy. But ! ..
> 
> Only major and most active O/S projects really benefit from the
> peer review, for the rest .. well, it just doesn't happen for them.
> I know this, and whoever is planning to f*ck people over with their
> evil client software do too. So they may as well release it as an
> open-source and get away with it. Just another flavour of a social
> engineering.
> 
> Open source is just that - it is open, that's it. The trustworthness
> does NOT follow. Feel free to disagree :)
> 
> John Aldrich wrote:
> 
> 
>>Alex:
>>How is your app better than Kaboodle and their "KaboodleProxy"? They make
>>the client source available and they even sell the proxy so you can run it
>>on your own machine(s), which in my book, makes it a bit more trustworthy
>>than having to trust someone else's machine. Granted the proxy is sold in
>>binary-only form, but at least you can run it on your own machine and
> 
> sniff
> 
>>what's going on.
>>	John
>>
>>-----Original Message-----
>>From: Alex Pankratov [mailto:ap "at" hamachi.cc]
>>Sent: Tuesday, March 01, 2005 4:25 PM
>>To: vnc-list "at" realvnc.com
>>Subject: Re: A simple, solid and stable P2P Bidirectional NAT Traversal
>>technique for RealVNC users...
>>
>>
>>I am principle designer and developer of Hamachi. I got few hits
>>from this maillist, checked out the comments and since we don't
>>have much information on the website I thought I'd offer some
>>answers here.
>>
>>Since I just joined the list I don't have original emails, so
>>here's a summary with my comments in it -
>>
>> > Am I the only one who has at least a slight distrust of using
>> > a "mediation server" in the middle of a secure connection?
>>
>>Mediation server is NOT in the middle of the connection. All it
>>does is allows clients locate their peers and learn their external
>>(routable) IP/port numbers. The clients then hook up on their own
>>and the rest of the traffic flows directly between them.
>>
>>See my next comment regarding security of the connection.
>>
>> > Maybe I just don't get it, or I do and am overly paranoid, but
>> > this seems to invite snooping, man in the middle attacks, etc...
>> > What level of trust do I need to place on servers I have no
>> > control over?
>>
>>Have a look at Security page on H website. This should take care
>>of your m-n-m worries. I come from a network security background
>>and take security architecture very seriously. If you can find
>>an exploitable flaw in it, I'd be very happy to hear about it.
>>
>>I'll assume that by 'snooping' you mean our client software doing
>>something nasty on your machine and pushing the results back to
>>the servers. Well, you will have to have the same amount of trust
>>in H you have in any other application distributed in binary form.
>>This includes, btw, pre-build open-source packages. In fact, you
>>cannot even trust applications that you compile yourself unless
>>you go and inspect entire codebase line by line. So the 'level'
>>is clearly subjective and based on your risk tolerance.
>>
>> > I have to wonder what the motivation for a company offering a
>> > service like this for free...
>>
>>Few reasons. First - it doesn't cost much to maintain. We don't
>>relay traffic, so bandwidth requirements are fairly low. Second -
>>there is a demand for this kind of application and offering basic
>>services for free is common approach for building a customer base.
>>
>> > Agreed, this type of a program makes you sit back and wonder, why?
>>
>>Well, you are most certainly entitled to this. However, I would
>>suggest to take your tinfoil hat off :) and have another look at
>>the application.
>>
>> > If programs like these are freewheeling around, what is even the
>> > point of having a firewall, also what is there to prevent them
>> > giving total access to outsiders, even without knowing?
>>
>>Trusted outsiders. This makes the world of difference.
>>
>> > If they had offered the source, so that we can look at it.
>> > and so we could setup our own servers as "mediators", then maybe...
>> > Otherwise I'd feel extremely uneasy about the whole thing...
>>
>>I am a big propent of Open Source - you can look me up on sf.net and
>>freshmeat, but in this particular case opening the source up gives
>>us very little benefit, but does take away quite a bit of an avantage
>>away.
>>
>>However we plan to do something better than opening the sources -
>>we are going to open cli-srv protocol after the first production
>>release. If you don't trust our client implementation for some
>>reason - feel free to build your own.
>>
>>In case if you wonder how it is better, opening protocol spec means
>>making a commitment to maintaining it, while opening sources merely
>>says 'here, look how _current_ version is implemented'.
>>_______________________________________________
>>VNC-List mailing list
>>VNC-List "at" realvnc.com
>>To remove yourself from the list visit:
>>http://www.realvnc.com/mailman/listinfo/vnc-list
> 
> _______________________________________________
> VNC-List mailing list
> VNC-List "at" realvnc.com
> To remove yourself from the list visit:
> http://www.realvnc.com/mailman/listinfo/vnc-list