A simple, solid and stable P2P Bidirectional NAT Traversal
t e chnique for RealVNC users...
B. Scott Smith
scott "at" smithdomain.com
Wed Mar 2 18:11:01 2005
Well, I've got to say. I just don't get it.
I can understand how a "mediation server" can help connect A to B if
EITHER A OR B is behind a firewall. But I still don't see how it can
work if BOTH A AND B are behind firewalls. If neither firewall allows
incoming TCP connections (the standard config for all hardware
firewalls), I just don't see it would ever work....
John Aldrich wrote:
>Interesting. Sounds like it *is* different from Kaboodle. Kaboodle's
>GetEngaged service is more like "Gotomypc" where you have a central server
>somewhere... Of course the server could be on your own LAN or somewhere else
>accessible. Both are very interesting to me.
>
>-----Original Message-----
>From: Alex Pankratov [mailto:ap "at" hamachi.cc]
>Sent: Wednesday, March 02, 2005 12:26 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...
>
>
>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
>>
>>
>_______________________________________________
>VNC-List mailing list
>VNC-List "at" realvnc.com
>To remove yourself from the list visit:
>http://www.realvnc.com/mailman/listinfo/vnc-list