A simple, solid and stable P2P Bidirectional NAT Traversal
te chnique for RealVNC users...
John Aldrich
JAldrich "at" covista.com
Wed Mar 2 17:19:00 2005
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