Talk:LogMeIn Hamachi
POV
Since there has been no comments on the POV as of late, I will assume that the article is now of a neutral point of view and remove the POV tag. If anyone feels that there is still unacceptable bias, please replace the POV tag and we can resume discussion. --Thylark 21:06, 22 May 2006 (UTC)
I reworked the section that talks about Hamachi not being open source and therefore being impossible to check if it delivers declared security properties. It is a very tricky subject, which is frequently misunderstood. See my edit for details. (I *am* involved with Hamachi, but I tried to keep it neutural the best I could).
Alex Pankratov 18:21, 16 May 2006 (UTC)
I made several change in attempts to make the article more neutral. I removed direct links to the application, phrasing which were unnecessarily positive and expanded (slightly) the section over security concerns. Aside from a general concern over the lack of access to the source code, I was not able to find any other significant criticisms during a quick search of the internet. --Ccscott 15:48, 10 May 2006 (UTC)
This article seems to be too positive toward Hamachi (eg. debatable security) to me and reads almost like an ad for it. I see a few other people also have similar concerns in the discussions below. We should at least put in some of the concerns and criticisms to balance it out. LeiZhu 07:13, 11 April 2006 (UTC)
I have been using Hamachi for several months, starting
(I think) back in April of 2005. It worked great! I
had a XP box with a static IP address behind a firewall
at work, and I had no problems connecting to it and
moving files, etc.
Then suddenly things started to fail, both on home machines, and on the machine at work. I looked on the Net for some discussions about Hamachi, how well it works, problems, etc. and have come up dry.
So I hope folks might discuss Hamachi here, issues with the technology, the company, their ability to fix bugs/issues, their ability to add features, etc.
Especially of someone knows more about them than I do, which just isn't too much.
--
who is making money from Hamachi
Does anyone knows who the makers of Hamachi are and how they make money of it? Is the program safe and without spyware and other dirt?
kbm
the problem i encountered is internet explorer failure
As an addition to the posts here I would like to point out that Hamachi is running in Beta releases at the moment(17/05/2006). As such it is not expected to be fully stable. It may also be understood that the product is not fully developed and on actual release (version 1.0) may very well be a chargeable service or have chargeable services attached to it in some way. regarding the can we trust them question.. well can you trust Google to not use your search statistics, email.. etc? Can you trust your ISP? What are you trusting them with? I use Hamachi, have done so for quite a while and I expect to for some time. It has the fastest and easiest VPN deployment available yet. That is why it is being used. If you want better security use OpenVPN or something like that.
Cheers Fred Wood.
just to know
u can find hamachi at hamachi.cc so
how can keep 2 natted box on the same vpn??
Making money (re: kbm's post)
Hamachi is a technology in the first place and a freeware VPN client in a second. Technology licensing covers costs of running free services at hamachi.cc. In addition to this we'll be offering premium (paid) services soobn, which will also help with further offset development and hosting expenses. Under no circuimstances we will be bundling any sort of -ware with Hamachi, simply because it just not a right thing to do.
Cheers, Alex, Hamachi DevTeam
At least one patent application seems to have been filed for Hamachi
The main Wikipedia page for Hamachi states: "Since Hamachi is not open source software and no patents seemed to have been filed, the source code is not available for review so its actual function is secret."
A filed patent application, however, appears to relate to Hamachi. See patent application number 20020124090 (go to www.uspto.gov, click on "Search" under "Patents" near the top left of the page; on the search page, select "Publication Number Search" under "Published Patent Applications," and then enter 20020124090 to find the application).
The patent application lists three inventors: "Poier, Skye M."; "Meharg, Gresham"; and "Pankratov, Alexandre." That last person, Alex Pankratov, appears to be the person that posts on Hamachi's support forums at www.hamachi.cc. He also appears to be the person who posted a comment on this page (i.e., Hamachi's discussion page on Wikipedia). Finally, he's also the person that Steve Gibson (of the www.grc.com fame) referred to as a Hamachi developer in his "Security Now" podcast, episode 18. - —The preceding unsigned comment was added by 70.113.49.38 (talk • contribs) 05:05, 19 December 2005 (UTC).
Re: patent
70.113.49.38, that's in fact my name on the patent application you are reffering to. It is however completely unrelated to Hamachi as it deals with centrally-managed VPNs and covers the method for making IPsec work through a single NAT. Hamachi has a central server, but it is not centrally-managed. It is not IPsec-based either.
Alex —The preceding unsigned comment was added by Apankrat (talk • contribs) 00:05, 20 December 2005 (UTC).
Who is behind Hamachi? How much may one trust them and Hamchi?
Although the description of Hamachi sounds interesting (and Steve Gibson was practically wetting himself talking about on his "Security Now!" podcast), a lot of questions remain unanswered. Without answers, I personally cannot recommend it to any of my client, and in fact would do the opposite. Hopefully, the people behind Hamachi can shed light on some of them.
At the outset, I should say that I find Hamachi intriguing, and have nothing against the program or its developers, etc. Yet, when it comes to security, especially with VPN software to which the user opens the kimono, so to speak, one should take a no-nonsense approach. Thus, my questions here. Please note that I am not suggesting that there's any wrongdoing at all. Just wondering what the answers are.
1. Who is behind Hamachi? The web site is practically devoid of any details. No discussion of who the people are, so I can't figure out a good reason why we should trust them.
2. Hamachi doesn't seem to come from a polished source. For example, there's no privacy policy. Given that the site seems to have a Cocos Islands designator (.cc) -- itself odd for a Canadian company -- I have a lot of concern about what happens to the potentially large amount of information that Hamachi can collect from users and their computers. What exactly does Hamachi collect, and how does it handle that information and what uses does it make of it? Steve Gibson did not seem that interested in those details -- another oddity, coming from him.
3. If you examine the network traffic that Hamachi causes, you'll note some interesting things. A Hamachi client communicates initially with a central server -- the mediation server, in Hamachi-lore -- although all of the communication appears encrypted. So, one has no way of knowing what information Hamachi sends to the mediation server.
4. Furthermore, according to Hamachi folks themselves, once the peer-to-peer communication between clients begins, the mediation server takes no part in the communication -- nothing goes through the mediation server anymore. Yet, the Hamachi clients continue to communicate with the mediation server -- every 90 seconds, to be precise. Again, it's not clear what the contents and purposes of the communication are.
5. When using Hamachi, one chooses a password. Given that the Hamachi server potentially or actually knows this password (thanks to the encrypted communication that takes place with the server), Hamachi can eavesdrop on all communications. The Hamachi folks point to a page on their web site that purports to show their security and claim that they do not act as man-in-the-middle. Again, given the lack of transparency and even a privacy policy, what's one to make of those claims? The program is not open source, so one has no apparent way of determining exactly what it does.
6. What happens if the information Hamachi has falls into the wrong hands?
One can go on, but you get the idea. I don't know whether Steve Gibson considered these issues, tried to resolve them, etc. But if he has not, it seems irresponsible to recommend Hamachi to many unsophisticated users (who put their trust in him and his reputation).
Hopefully, either Steve or the folks behind Hamachi will step forward to clear the air. —The preceding unsigned comment was added by 67.9.184.182 (talk • contribs) 19:19, 16 August 2005 (UTC).
The issue of trust
Regarding #1, #2
.cc is a common replacemnt for .com domains when respective .com name is taken or unavailable. .cc space is managed by VeriSign's subsiduary and has very little relation to actual Cocos Islands. Have a look around on the web and you will see .cc being used fairly extensively. For example, have a look at intel.cc or trillian.cc
The company information including missing legal fluff will be added to the website a bit later on (around 1.0 release of Windows client). We are small development shop and have to prioritize things. So far the focus was on an actual product development, but as we grow we will be taking care of other things as well.
Since you bring up the subject of trust, you may want to look http://hamachi.cc/security page. If you are not skilled in applied cryptography, please find someone who is, so that you don't have to rely strictly on my words.
The reason I am forwarding you to Security page is this - Hamachi security architecture is specifically designed to minimize the amount of trust Hamachi user must have in our servers. We basically do not know anything about the user except for his IP address, the list of his networks and its public key. We cannot force the user to accept an unwanted connection, nor can we evesdrop on legit ones.
It is hard to explain in layman's words what exactly guarantees this. But you may for example ask Mr. Gibson if you trust his opinion as he audited Hamachi security framework extensively.
Regarding #3
Would you prefer to have all client-server traffic go in clear ? This can be arranged, but this will immediately open you up to a heap of potential attacks. It will also not make things any more clearer as the protocol is binary.
Regarding #4
You are quoting incorrectly. No peer-to-peer data traffic flows through our servers, not 'nothing goes through servers anymore'. The packets you are observing are session keep-alives. They confirm that your client is still actively servicing its control connection. Alternative is to rely on TCP keepalives, but this is hardly practical because they have much long period (hours) and cannot be reliably used for detecting clients that terminate connection without sending TCP/FIN.
Regarding #5
The password that you choose is a maintanence password that you can use to recover the ownership over networks should you lose your private authentication key for some reason. This password is NOT used for securing your communications. Hamachi actually explains the purpose of the password when it prompts for it.
Also making program an open-source does not make it any more trustworthy. It is still perfectly possible to supply binaries that are assembled from different sources. It's a variation of social engineering attack, far more obscure and very hard to detect.
The only sure way to establish a trust in binaries is to review all sources by hand (line-by-line) and then build them on a trusted platform. This is very impractical, because complete source review is extremely tedious and very expensive task. While it is fairly easy to confirm that the source DOES something, but it is very hard to verify that it does NOT do something else.
Practical approach for establishing a trust in binaries is based on open specifications (as opposed to open source). Developer declares that it abides to a certain spec and then his binary is verified to comply with the spec black-box style. This is THE way to deal with binary distributions. That's why people entrust Cisco VPN client and Microsoft Windows with their security. Not because their source is available, but because they can be verified to work as claimed.
This is also the reason Hamachi security framework is open. In fact it was the first thing that went on the website, even before the Downloads page was there.
Regarding #6
Nothing happens. See my above remark about the minimum amount of trust the user is placing in our server. The worst that could happen is the users will not be able to connect to each other anymore. That's it.
--
Stepping back a little, your main concern seems to be that you have little idea of who we are and if you can trust us not to put evil stuff in .exe. This is reasonable and I completely understand where you are coming from.
However regardless of the approach one takes, your trust will still in the end be based on our (my) word. One can perceive this word to be more valuable if there's privacy policy on the website, another - if we were a big company, third - if we had .com ___domain, fourth - if we had a good reputation ..
Hamachi does 'no evil'. That's my word, the design principle, a company motto and implementation strategy. Whether you believe it is up to you.
The issue of trust, etc.
Well, I don't want to speak for anyone else who has posted here. But I personally see a lot of holes in what Apankrat says. He's stated similar things on the forums on the Hamachi.cc site, and I have found them equally unconvincing there. As such, and given that he seems reluctant to change anything other than add "legal fluff" to the site, no one I work with is going to use Hamachi -- not on my watch.
To me, the crux of the discussion regarding trust and security boils down to this point:
Hamachi -- not the user -- has the burden of proof.
Apankrat acts in a way that makes me think he thinks the opposite. In other words, he seems think that the users should trust Hamachi until it's proven untrustworthy. For the reasons below, I find his arguments unpersuasive and his position untenable when it comes to anyone who takes seriously network security and integrity.
From where I'm sitting, Apankrat seems to miss the point that Hamachi needs to convince users (I'm talking about Fortune 500 users) that it deserves their trust. Fancy wordsmithing about how open source wouldn't fix the problem ain't gonna cut it. Complying with specs? They've seen and heard it before. Even if one could determine whether IE meets its specs (Apankrat makes testing software sound so easy), it's the things outside of the specs that worry companies -- the same ones who are apparently expected to trust their network security to a virtually undocumented application.
With scarcely any information about the details of the program's code, users have no way of knowing how robust the program is, nor how foolproof Hamachi's server and its security are. Here's a minor example: Without details of why the Hamachi client needs continued "keep-alive" communication with the Hamachi server, what's a user to make of that communication? Apankrat seems to say, "Take my word for it."
Bottom line: If you mean what you say about Hamachi not being "evil," make the source code available, and I'm sure you'll find volunteers who will look at it. Hiding behind "Oh, it's too complex" won't do the trick for software that will have access to the crown jewels -- not coming from a virtually unknown company. If you're worried about proprietary information, there are measures you can take to cure that problem.
The security page at Hamachi.cc just lays out a spec. With encrypted communication, how would anyone confirm that it does what it says? Apankrat's statement "Would you prefer to have all client-server traffic go in clear ?" either misses the point or is too clever for its own sake. The user simply has no way of knowing what Hamachi sends. Sure, it seems to send the intended user's communication (I take that point without knowing), but what else does it do?? At least give the user the option of seeing what the program sends before it's encrypted and sent out (say, in a debug mode). At least to my reading of the posts on this page, no one is suggesting that encryption is bad. It's just that encryption by a virtually undocumented, closed-source, software from a virtually unknown company, with full access to the user's information,
Apankrat's comment about "legal fluff" also gives me much pause and concern. It seems to show either an apathetic or condescending attitude towards some very basic assurances. A privacy policy is the minimum a company that will have total access to the information on the user's computer can do to establish trust with the user.
If you read the forums on Hamachi.cc, I think you'll see the same apparent lack of clear communication and openness with users. For example, several users complained that Windows XP's Remote Desktop (RD) tool does not work with Hamachi. After several posts with inconsistent explanations and instructions from Apankrat, the problem did not seem to go away. Trying to run the program as a service also didn't seem to help (and couldn't be done in a reliable way). If I remember correctly, Apankrat claimed at one point that the feature wasn't even on the users' top 10 wish list (hard to believe from the perspective of what the tool is -- a VPN).
Then, suddenly, Hamachi 1.0 beta worked with RD! As for running the program as a service? Oh, that feature will apparently be available in the premium, paid version of the program. Could it be that Apankrat or whoever else working on the problem didn't understand it or didn't take the time to communicate with the user community? I suppose so. But whatever the cause, I don't gauge Hamachi as ready for prime-time.
At the end, I want to emphasize that I have no idea who Apankrat is or what his/her motivations are, so I'm not assuming that they're anything less than honorable. Equally, I emphasize that I attribute no "evil" motive to him/her or Hamachi, simply because I'm not given enough information to make an assessment. That exact point, however, lies at the root of my lack of trust in it.
I guess at the end of the day I'm from the "trust and verify," rather than the "be happy, don't worry" school of security. Others will obviously have to decide for themselves.
etc
If you read the forums on Hamachi.cc, I think you'll see the same apparent lack of clear communication and openness with users.
If you read your own posts, you will see an apparent bias against Hamachi in general. You consistently quote of the context, make assumptions and go on exploring them, ask 'sharp' questions that make no technical sense and don't bother to read or understand (or pretend not to) replies to earlier comments. In fact your posts read more like anti-Hamachi rants, than anything else.
Alex Pankratov 23:06, 24 December 2005 (UTC)
Anybody know why they named it hamachi? Does it have to do with yellowtail?
Packet logging?
(It's disappointing that, instead of answering concerns, the response is personal attacks, as if the only people who don't automatically trust Hamachi are "anti-Hamachi", rather than exercising due caution. Oh well.)
I assume people have done the obvious packet sniffing, to see what the software is actually doing. The comms to their "mediation server" may be encrypted, but the effect it has on the NAT servers can be analyzed on both ends. Are there any links or references to this that are appropriate to the article?
- well ... I think you got the right point!
- I cannot believe that the article says: "It is hypothesized that Hamachi establishes the connection between two NATed hosts by directing them to initiate network connections to each other at the exact same time." - oh God, is there something easier than take two NAT boxes, two clients behind them, and test if this is true???
- I would give a great POV to this article, or, better, I would say that this is clear advertisement ... and the discussion, or the free associations and fogging (is it the right word?) of Alex Pankratov, does not convice me to think something else ...
- btw, do I have apparent bias against Hamachi? - well, I am hearing about this software for the second time (the first was today when I was asked by an user to allow this on firewall), and yes, now I have bias against Hamachi because of the article contents and Alex's reactions ... --Kavol 23:04, 14 March 2006 (UTC)
- Kavol, for what it's worth - I have no idea who wrote this article. The way I became aware of this page was through some hits in our weblogs. I made probably 3-4 anonymous edits, these came from 24.87.213.xxx IP. Astroturfing is not my idea of attracting the attention, and this sort of ties in with what I want to say regarding the "bias" comment.
- Don't base your opinion on wikipedia talk alone. Check our forums, check p2p-hackers, realvnc and cryptography maillist archives and have a look around the web. You will see that we've been open about the project from the very beginning and a lot of people evaluated and commented on it. I have no problem discussing any aspect of the project as long as it is in fact a discussion, and not a monologue as it was the case with some comments on this page.
- Alex Pankratov 07:21, 15 March 2006 (UTC)
- I do not want to sound so offensive, but ... Let's take one thing as example - okay, I visited the site, searched the forums and see that there is really no privacy policy statement. You say that there are more things that can increase users trust and this is just one of them. Some can be fulfilled easily, some not (e.g. being big company). If you say that we can take your word, then what is the problem to write it down and publish it officially? It won't harm you since you would be stating the obvious, it won't take more time than a few posts to Wikipaedia or to the forums, and it would help some of the users to gain more trust. So, why don't you do that? Why do you waste your time instead by repeating that there is no point in that? - users want it so there is a point in that. The same goes for the ___domain - why do not you contact mr. Takumi Katoh, or, if you already failed with him, why do not you use something like hamachi-vpn.com?
- As for the article here and the advertisement-like feeling ... I know that there are some users who would be better kept silent (in Czech, we call it "bear service" - maybe "shot in the eye" in English?) I do not blame you for this, I just tell my opinion. But it is a bit worse that could be, because I know that you know about (the existence of) the article and you did nothing to make it less subjective - in fact, http://en.wikipedia.org/w/index.php?title=Hamachi&diff=33759368&oldid=33586748 seems correct from the technical point of view, but sounds a lot better than the previous version from the marketing point of view ...
- p.s. sorry for any mistakes in English ;-) --Kavol 10:09, 19 March 2006 (UTC)
- The privacy policy page has been online for few months now. It's linked from every page of the website, except perhaps our forums. The URL is http://hamachi.cc/privacy
- Ooops, sorry, I have overlooked the link within the page footer. For me, the best place would be menu => About => Company => Privacy policy. As for any link from forums - I tried searching ... So, I apologise, but still, I do not understand your reaction to #5 of the above discussion ... Nevermind. --Kavol 18:23, 20 March 2006 (UTC)
- Domain-wise - my position is that us using .cc is a non-issue. If someone knows that .cc belongs to VerSign and he still perceives .cc to be less trustworthy compared to .com, he is just being unreasonable. We may switch to .com later on, but it will be for reasons other than .cc being 'bad'.
- Regarding the correction you linked to - see my comment for this change. H is still to this day is 'the only' VPN with NAT-to-NAT traversal and it 'is' one most strongest feature. It seems only fair to stress this point in an Overview, hence the change.
- You do not need to talk about port forwarding etc., I do not know much, but at least enough to be sure that a lot of things are possible if there is a will to do them. But it seems that we agree upon the consequences of such change while we disagree if it is fair (as you say) or subjective ... --Kavol 18:23, 20 March 2006 (UTC)
- Why .cc in the first place? As a Canadian company, why not .ca? I love Hamachi and use it whenever I have the opportunity, but it always struck me as odd that a Canadian company would start out with a .cc address. Guspaz 16:21, 15 May 2006 (UTC)
- PS Your English is totally fine
- Alex Pankratov 21:07, 19 March 2006 (UTC)
Schneiers snakeoil crypto checklist
I just added this
"As always with crypto-products, you have to check the claimed security yourself. Bruce Schneier lists some questions to ask in his newsletter."
to the article and would be more than interested in a detailed, argumented rebuttal of the applicable items on Bruces list. --Ministry of Truth 18:54, 8 June 2006 (UTC)
While this newsletter may contain good advice I really don't see how applicable this checklist is to this wikipedia entry. To my understanding Hamachi is really just an implementation of accepted crytographic algorithms that, without much user configuration, set up a VPN connection between two computers even across NAT routers. The developers make no claims of "new" cryptographic schemes or that Hamachi is any more unbreakable than other technologies. In fact, one option in the premium version is to actually turn off encryption to decrease CPU overhead for gaming applications where speed is critical. I will leave it to the developers to address your points if they so desire, but in my estimation, the type of encryption employed is not drastically different that other VPN implementations and not therefore not the main utility of this product. Rather, it is the ease in which private networks can be set up across NAT routers using a mediation server that makes this product useful.
--Thylark 20:00, 8 June 2006 (UTC)