Talk:Hamachi/Archive 1

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.

--

---

Given the time it seems to take to agree even on minor details, I would suggest we put the {{POV}} tag back in. I thought we could fix the article fast enough not to need it, but it looks like I was wrong. --Ministry of Truth 18:09, 16 June 2006 (UTC)

Given the comments of other WP users regarding your editing practices (User_talk:Falcorian#Ministry_of_Truth) I would like to see other people thoughts on this matter first. Thylark's opinion for one as he was the initiator of the last POV review.

Alex Pankratov 23:05, 16 June 2006 (UTC)

Adding it now, according to WP:NPOVD to indicate the ongoing discussion and likeliness of changes. Still ready to discuss, but probably not at the level set by your introducing remark ("Given the comments..."). --Ministry of Truth 23:25, 16 June 2006 (UTC)

My remark merely meant to show that we should go carefully about your approach of 'fix(ing) the article fast' and that we should indeed have a consensus about the changes being made, which was not the case with your initial set of changes.

Alex Pankratov 23:39, 16 June 2006 (UTC)

---

As slow current review process is, things are moving forward. I just wanted to acknowledge this and express my appreciation for the time and an effort everyone is putting into this.

Secondly, I want to add that most of the confusion as to how structure the article spawns from the fact that Hamachi is either approached as a completely closed-source system or as a blackbox 'that just works'. Neither approach is correct. First leads to a completely understandable, but otherwise misplaced negative bias, and second to a potentially misleading positive bias.

As many of you might've noticed, I am constantly bringing up the fact of open security architecture and I cannot stress enough how important this property of the system is. That is what takes Hamachi from the domain of voodoo magic software and puts it on a level with other security systems. Please make an effort to understand this crucial point before engaging in criticism that does not account for it. I am completely open to discussing this matter, assuming, as MoT puts it, the discussion is intellectually honest.

Alex Pankratov 03:49, 17 June 2006 (UTC)

---

I have reverted status upgrade from POV to TotallyDisputed made by Ministry Of Truth until valid reason(s) as specified by Wikipedia:Accuracy_dispute is/are provided. I do not object to the upgrade, we just need to have the list of facts the accuracy of which is disputed. Alex Pankratov 06:32, 19 June 2006 (UTC)

My impression is that hamachi is some sort of suspicious beta root kit that installs itself too close to your operating system bones, messes around with the computers network security, may screw something up there with next MS update and it is extreme difficult to uninstall it. Hard to figure what is up since that unreliable thing is closed source. Feels that it is either meant as trojan or usable (because of bugs in it) as trojan. But certainly i wont edit the article to say my opinion, so please, Alex, indeed, especially if you are involved, talk what is accurate! Why its such a crap and why you want to boast it here? —Preceding unsigned comment added by 62.65.221.19 (talk) 14:24, 30 December 2007 (UTC)

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

You'll find that there are actualy two versions of Hamachi. The limited freeware edition only allowed a low limit of users on a network, each network may have 15 free members and 200+ paying members. I think free members are also limited to the number of networks they can join.

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

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 soon, which will also help with further offset development and hosting expenses. Under no circumstances 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.

-- Alex Pankratov 03:35, 23 December 2005 (UTC)

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:01, 8 June 2006 (UTC)

What exactly do you have trouble understanding in

"The problem with bad security is that it looks just like good security. You can't tell the difference by looking at the finished product. Both make the same security claims; both have the same functionality. Both might even use the same algorithms: triple-DES, 1024-bit RSA, etc. Both might use the same protocols, implement the same standards, and have been endorsed by the same industry groups. Yet one is secure and the other is insecure.

Many cryptographers have likened this situation to the pharmaceutical industry before regulation. The parallels are many: vendors can make any claims they want, consumers don't have the expertise to judge the accuracy of those claims, and there's no real liability on the part of the vendors (read the license you agree to when you buy a software security product)."

"I want to believe" may be a good enough answer for you, but keeping misleading information in the Wikipedia is not a viable option. And with six different links to hamachi.cc, I seriously consider putting up the {{POV}}

tag again unless someone else steps up to add a spoonful of NPOV. --Ministry of Truth 21:03, 8 June 2006 (UTC)

Just took off the live POV tag from this talk page, as it now moved to the article page, where it will hopfully do some good before we manage to agree that it may go away again. Thylark, I am pondering your long, thoughtful reply. --Ministry of Truth 00:23, 17 June 2006 (UTC)

---

Perhaps you can elaborate how items on Bruce's checklist apply to Hamachi and which part of the article you think is a "misleading information". As I said in earlier posts, when reviewing Hamachi, do not limit yourself to Mr. Gibsons opinion. Have a look around. Hamachi has been around for over 1.5 years now, it was reviewed multiple times and was brought up and discussed on various specialized maillists, including cryptography not long ago. I also gave exact design rationale for its security architecture on p2p-hackers list about a year ago, and in a number of other places.

Regarding POV/NPOV - check article's history. This has already been dealt with.

Alex Pankratov 06:07, 9 June 2006 (UTC)

Bruce's Snake Oil is about security "inventions" that are either closed, obscured, designed from scratch, come with marketing hype or just don't make any sense to security professionals in general. None of this applies to Hamachi; specifically -

Warning Sign #1: Pseudo-mathematical gobbledygook - does not apply

Warning Sign #2: New mathematics - does not apply

Warning Sign #3: Proprietary cryptography - does not apply

Warning Sign #4: Extreme cluelessness - does not apply

Warning Sign #5: Ridiculous key lengths - does not apply

Warning Sign #6: One-time pads - does not apply

Warning Sign #7: Unsubstantiated claims - does not apply

Warning Sign #8: Security proofs - does not apply

Warning Sign #9: Cracking contests - does not apply

Not sure if that's what you wanted to hear, but it is just as simple as that. Hamachi is yet another VPN system, it does not re-invent the wheel of cryptography.

Alex Pankratov 06:22, 9 June 2006 (UTC)

This is getting circular. Unless we can get a trustworthy demonstration rather than ad hominem attacks on perfectly valid questions such as those raised here: The_issue_of_trust I'll continue to tone down the promotional character of the article and add some fair warning about unsubstantiated claims of security. And while it is an interesting rhetorical device to try to reverse the burden of proof, I conclude from your "... when reviewing Hamachi, do not limit yourself to Mr. Gibsons opinion." that you are aware of his disputed reputation, which is a good start, but you still owe the proof of Hamachis trustworthyness. --Ministry of Truth 08:08, 9 June 2006 (UTC)

"This is getting circular". It sure does. It would help to have the list of questions that your consider to be 'perfectly valid', but still unaddressed. Or perhaps you can at least outline what you consider a 'trustworthy demonstration'.

You seem to confuse security properties of the design with a trustworthiness of the implementation. These need to be considered separately and that was what the section of the article that you chopped off was talking about.

Alex Pankratov 16:14, 9 June 2006 (UTC)

Is there anything you have issues with in the redacted version (by Wikipedia criteria, I can understand that you as the vendor liked the sales-copy variant a lot better) ? --Ministry of Truth 16:52, 9 June 2006 (UTC)

Well, for one your comment "As always with products involving cryptography, you have to evaluate the claimed security yourself" is inaccurate. In majority of cases 'you' will not evaluate claims yourself, but rather rely on an opinion of other people that did and whom you trust.

Secondly, you link to Snake Oil article and judging by the lack of a reply to my comments above, I take that you see that Hamachi passes Snake Oil 'test'. As much as I respect Bruce Schneier's work, the link is largely irrelevant.

Thirdly, you reworked the part that dealt with establishing credibility of a security model and merged it with trust issues surrounding implementation details of this model. The quote from VPN article applies to every single closed source product out there, not necessarily security-related. It is a question of how one verfies that the product does what it does and does not do more. In this perspective I do think that the previous edit was more accurate and closer to the point.

Regarding 'sales-copy variant' - I don't feel particularly attached to any version; previous version did however appear to be more neutural. Just keep in mind that there are few million users of the system out there, most of which are consumers. This tends to affect what they modify in the article and also adds the pro-bias. This clearly needs to be kept under control. The article was cleaned up few times before, however far less intrusively compared to your edits.

Alex Pankratov 18:04, 9 June 2006 (UTC)

I have no problem understanding the parts of the newsletter you highlight but I maintain they are not especially relevant. As the developer posted above, there are no new encryptions schemes used in Hamachi and therefore they do not apply. The one section you highlight is true, and is really just common sense, but is already covered in detail in the existing paragraphs:

Since Hamachi is not open source software and no patents have been filed, the source code is not available for review so its actual function is secret.

This inability to audit the source code has raised concerns with some users over the actual security of data sent over the Hamachi connection. These concerns are however the same as with any other software distributed in a binary form. For the software to be completely trustworthy, it must either be assembled from an audited source code by an end-user or obtained from a trusted source that does this assembly on behalf of the user.

Although the source code itself is not public, a detailed description of the Hamachi security architecture is available [2]. This makes it possible to validate security properties of Hamachi protocol without having an access to the source code. The security architecture of Hamachi has been reviewed and endorsed by computer security expert Steve Gibson on Episode 18 of his podcast Security Now!. It has been also discussed on p2p-hackers and cryptography maillists. As always with crypto-products, you have to check the claimed security yourself. Bruce Schneier lists some questions to ask in his newsletter.

In fact these concerns apply to all software, not even just security-related applications. You cannot be sure of exactly what an application is doing unless you reviewed and compiled the code yourself. Even then, there is a significant possibility you overlooked something in the code. And releasing the source code is not an acceptable business decision for a software development company, whether they be Oracle, Microsoft, or Hamachi.

It is impossible to prove that any encryption program is secure; you can only prove that a security implementation is insecure. Therefore I do not know exactly what evidence the developer or anyone else can produce to convince you.

I have no problem with you clarifying any statements you think are misleading, or changing wording you find is too "promotional" to make it more neutral, but I do not think there is a general cryptography issue with Hamachi. You can point out the possibility that there might be a security oversight or a nefarious intention of the developer, but to my knowledge, no evidence exists to back up these claims, but please strengthen these theoretical concerns if you feel it necessary.

--Thylark 09:29, 9 June 2006 (UTC)

I just added security evaluation elements and took out some ad-copy-like language. Feel free to comment. I'd also like to clean up and tighten the protocol part of the "how it works" section and get rid of weasle words such as "It is hypothesized". Any ideas how to condense it a bit while adding some clarity ?--Ministry of Truth 10:27, 9 June 2006 (UTC)

I combined three paragraphs down into one omitting the sections describing detailed NAT theory which is present anyways in the NAT article. I still think it is a little scattered though and can use some more refinement. --Thylark 12:11, 9 June 2006 (UTC)

Great editing job, thanks a lot, Thylark ! What do you think about folding 1.1 Port translation and 1.2 Relayed tunneling into the main "how it works" section and put the security thing into a seperate main section ? --Ministry of Truth 13:41, 9 June 2006 (UTC)

It sounds reasonable to me. A division having the NAT traversal functions as one section and the cryptography aspects/security in a second seems logical. As it stands the "how it works" aspects are scattered through the whole article. --Thylark 22:36, 9 June 2006 (UTC)

Thylark, glad to hear you share my views on the edits to be made. Alex, while I'd rather have Schneier than Gibson, I can live without the Schneier quote as long as we can find a consensus on the security section. --Ministry of Truth 22:22, 11 June 2006 (UTC)

Reverting some of the changes made by Ministry of Truth

I am going to revert changes made by Ministry of Truth to the section of the article that talks about secruity and trustworthiness to this version.

For the rationale please see my comments as well as the lack of response from Ministry of Truth in discussion threads here and here.

Please comment. unsigned comment by Apankrat 19:58, 11 June 2006 according to changelog. --Ministry of Truth 22:22, 11 June 2006 (UTC)

We are very far from a consensus here and I vigourously oppose this revert unless you can demonstrate how all changes that would occur increase the quality of the article by WP standards.

I listed my reasons in the in above section, and applying your own logic here I'd like to see how your changes that I question increase the quality of the article by WP standards. So far you haven't replied to any of comments to your previous statements and editing rationale, some of which were wrong or misleading. You also severely misquoted Gibson's review, which makes me question the lack of bias in your editing motives. I will repeat my points here again -

Repetition of already refuted arguments does not make them any better, nor does it help the clarity of the discussion. Please refrain from doing that, instead let's concentrate on points still in need of improvement. Here's the part you're referring to, and my rebuttal:

Your partial quotation is misleading and now makes me question your motives for your edits. Clearly when looking at the whole statement Gibson still recommends the product. I respect and recognize your skeptical point of view is necessary to maintain balance of this article, but we are looking for a neutral point of view, as per Wikipedia guidelines. Please try to remain objective in the future. --Thylark 22:58, 9 June 2006 (UTC)

I was asking an open question in this section, Thylark, seeking advice. I completely agree that either more context to the "anxious" quote or one pro quote from the previous podcast and the correction would be needed to achieve NPOV. I suggest we link the transcripts rather than the mp3 files to provide better reference. --Ministry of Truth 22:22, 11 June 2006 (UTC)

If there is anything specific still in need of being addressed, let me know. --Ministry of Truth 07:48, 12 June 2006 (UTC)

1) Snake Oil reference is irrelevant in Hamachi context

2) Your comment "As always with products involving cryptography, you have to evaluate the claimed security yourself" is inaccurate.

3) You removed essential parts of security architecture discussion.

4) You merged security model discussion with implementation-specific trust issues, which are neither VPN nor Hamachi specific.

Alex Pankratov 01:59, 12 June 2006 (UTC)

1) As previously stated, I'm fine to drop the snake oil quote as long as we get a reaonable security section going,

I don't understand why removing irrelevant and misleading information is dependent on other pending changes. In its current form, the section unambiguously implies that Hamachi is a Snake Oil application, which is clearly not true.

Alex Pankratov 10:15, 12 June 2006 (UTC)

2) A statement to the effect that vendor claims need to be checked seems important to me, open for suggestion of different language.

Agreed. The issue here (as I see it) is that the explanation of how these checks are typically done will be fairly generic and not specific to the subject of the article. I can easily imagine other WP articles needing to discuss similar issues, so putting together separate article seems like an appropriate idea. Extending the idea further, the discussion also needs to cover how closed source applications are validated (via black-box/open-spec testing), how open source facilitates code validation and why open source does not automatically mean trustworthiness.

Alex Pankratov 10:15, 12 June 2006 (UTC)

3) Not true. Thylark did the edits I suggested. And his changelog entry "(Condensed == How it Works == description of NAT traversal)" does these edits perfect justice, they are anything but a "security architecture discussion". The link to the hamach.cci security discussion was left in as a relevant reference. I appreciate your rhetoric talent and am confident that you can make your point witout misrepresenting facts.

I was refering to the removal of 'It was also reviewed on p2p-hackers and cryptography maillists'. The fact of Hamachi being peer reviewed is essential to establishing the credibility of its design.

Alex Pankratov 10:15, 12 June 2006 (UTC)

4) See above:

I just added security evaluation elements and took out some ad-copy-like language. Feel free to comment. I'd also like to clean up and tighten the protocol part of the "how it works" section and get rid of weasle words such as "It is hypothesized". Any ideas how to condense it a bit while adding some clarity ?--Ministry of Truth 10:27, 9 June 2006 (UTC)

I combined three paragraphs down into one omitting the sections describing detailed NAT theory which is present anyways in the NAT article. I still think it is a little scattered though and can use some more refinement. --Thylark 12:11, 9 June 2006 (UTC)

Great editing job, thanks a lot, Thylark ! What do you think about folding 1.1 Port translation and 1.2 Relayed tunneling into the main "how it works" section and put the security thing into a seperate main section ? --Ministry of Truth 13:41, 9 June 2006 (UTC)

It sounds reasonable to me. A division having the NAT traversal functions as one section and the cryptography aspects/security in a second seems logical. As it stands the "how it works" aspects are scattered through the whole article. --Thylark 22:36, 9 June 2006 (UTC)"

I am not exactly sure what 'ad-copy-like' was refering to, but that was the edit that replaced discussion about trust issues surrounding closed source software with an out of place quote from VPN article. Any sort of content removal is a drastic action, the content was nowhere near being biased, misleading or of a promotional nature. I see this change as being completely groundless and unnecessary. Can you explain what it is that you did not like about the original version ?

Alex Pankratov 10:15, 12 June 2006 (UTC)

So a big yes for a distinct Security section. --Ministry of Truth 07:48, 12 June 2006 (UTC)

Yes, current edition of security description is unacceptable.

Alex Pankratov 10:15, 12 June 2006 (UTC)

Rebuttal of the revert "rationale" in the corresponding sections.

I agree that the security discussion still needs work and I am open to discuss it.

Ok, can we then perhaps start with you commenting on points I listed above ?

Alex Pankratov 01:59, 12 June 2006 (UTC)

I would really like to keep this a friendly debate.

Please do take time to answer questions and issues that myself and Thylark raised in previous sections. This would be a good start to a friendly debate.

Alex Pankratov 01:59, 12 June 2006 (UTC)

My purpose is to make the entry accurate and readable. Hamachi certainly is a great product for a user who wants a hassle-free way to build a tunnel through NATed networks. But we also need to provide the reader of this article with all knowledge required to help him assess the security of the product and should work on that together. --Ministry of Truth 22:22, 11 June 2006 (UTC)

I agree and I believe the previous version of the article already did that.

Alex Pankratov 01:59, 12 June 2006 (UTC)

Addressed points raised above, some more than once, gracefully overlooked the "can we then perhaps" part, hoping once more for a friendly and intellectually honest debate on the issues at hand. --Ministry of Truth 07:48, 12 June 2006 (UTC)

Clarified some points, hoping for clarification as to which part of the debate was not 'intellectually honest' so far.

Alex Pankratov 10:15, 12 June 2006 (UTC)

Security issues not yet addressed in the article

In particular, I was thinking about other problems completely left out of the article for now and would like to sollicit comment:

"As Hamachi explicitly targets less sophisticated users who value the ease of use and may have trouble with regular VPN configuration, all security tradeoffs should be made particularly clear to leave the reader of this article with all knowledge required to help him assess whether or not the product fits his needs.

The ease of use is obtained at the cost of a central mediation server, which includes an additional single point of failure not present in other VPN setups. This server also obtains (and could log) the IP address of current users, the time and duration of connections to other users and possibly additional information that could be encoded into the encrypted setup and keepalive packets sent from the clients to the mediation server. Right now the mediation server is located in the 64.34.106.0/24 netrange. There is no evidence that such backchannel information is included, but the absence of auditable source code makes it impossible to exclude the possibility and the license says: "... the End-User may not decompile, reverse engineer, disassemble, modify ... the client software"

As you may or may not know, centrally-managed VPN systems become very common in past 5 or so years. Every single VPN vendor as well as every major Telco and IT provider offers systems and services that are based on the same principles as Hamachi. The term is "managed security providers" or a variation of thereof. In case of Telcos the consumers of these services are the same less sophisticated home- and small-business owners that find Hamachi appealing. Client software of these services is also closed-sourced, it is distributed under a restrictive license and it connects to the central server over a proprietory protocol. Discussing security issues of server-controlled VPN solutions should not be limited to Hamachi or at the very least it should explain that these issues are not specific to Hamachi.

Alex Pankratov 10:59, 12 June 2006 (UTC)

Regarding backchanneling and license restrictions. While the license prohibits reverse-engineering of the software, it does not (and cannot) prohibit protocol analysis. Moreover the security spec is detailed enough to allow implementing fully functional protocol analyzer and auditing control session between the client and the server in real-time for an arbitraty long period of time. This in particular gives an access to keep-alive packets as well as all other control messages.

This still leaves a possibility of the client using some sort of subliminal or steg-based backchannel within the protocol. However once one has an access to the raw protocol stream, it will become evident that there's no enough bandwidth for the backchannel.

Not sure how this can be incorporated into the article, but the important point is that we (as a vendor) provide enough information to the public to enable any user to audit all client-server communications and therefore establish higher degree of trust in our system.

Alex Pankratov 10:59, 12 June 2006 (UTC)

PGP publishes its source-code for a reason as well. The closed-source problem, augmented by the central server issue is a Hamachi problem other products may share - that does not take away anything from the problem. We already provide your story of the security architecture, and work on expanding the best we can from there. The burden of proof is with the vendor that his product is safe, if you withhold information, in this case source, from review, the fact that this considerably complicates security assessment, bordering on impossible, can't reasonably play out in your favor. --Ministry of Truth 16:31, 13 June 2006 (UTC)

I disagree that not having an open source product is an equivalent to withholding the information. Applying the same logic one can conjecture that not having a shell access to a build machine for PuTTY installers is withholding vital security review information. You still haven't commented on a difference between open standards and open source, which is vital to security system audit practices. With an exception of SSH and OpenVPN virtually all other security products used in the industry are closed source. The trustworthiness of their implementation is established by a black-box testing against open standards, this is an established practice.

Consider this. If Hamachi were open source, the majority of the users (being unsophisticated as per your own remark) would still be using vendor's pre-built binaries. And this would essentially keep all trust questions still pretty much open. So open source or not, the question is how to establish the trust in prebuilt binaries. That is why the ability to parse the protocol and do external session audit is more important (for the case of dominantly unsophisticated userbase) than just having sources open.

Alex Pankratov 20:04, 13 June 2006 (UTC)

If you can provide relevant black-box testing for Hamachi, that would be a welcome complement of information. So far I do not see anything in the proposed additions refuted nor any demonstration of other relevant reasons not to include it. --Ministry of Truth 09:39, 14 June 2006 (UTC)

I don't oppose including this sort of information into the article. I argue that your version represents an incomplete and therefore naturally biased point of view and therefore is not ready for the inclusion into an article.

Alex Pankratov 18:13, 14 June 2006 (UTC)

Feel free to propose alternate language to achieve NPOV you claim my suggestions lack. --Ministry of Truth 18:20, 14 June 2006 (UTC)

just a draft, language needs polishing, should also be shorter, but for now I'm mainly interested in discussion of hard facts.

Hamachis beta status and that remaining bugs may or may not compromise security should probably also be included. Again, language up for discussion.

Created this section from material not yet addressed in the revert section for clarity. --Ministry of Truth 07:48, 12 June 2006 (UTC)

Here's a detailed critique of proposed version - "As Hamachi explicitly ..

Please justify the use of "explicitely".

.. targets less sophisticated users who value the ease of use and may have trouble with regular VPN configuration, all security tradeoffs ..

This is misleading as it implies that such "tradeoffs" are confirmed, unavoidable and all of them are security related. See below for details.

.. should be made particularly clear to leave the reader of this article with all knowledge required to help him assess whether or not the product fits his needs.

The ease of use is obtained at the cost of a central mediation server, which includes ..

"includes" does not seem to be the right word, would "constitutes" work better ?

.. an additional single point of failure not present in other VPN setups.

"not present in other VPN setups" statement is incorrect. See my remark about managed security services above.

This server also obtains (and could log) the IP address of current users, the time and duration of connections to other users and possibly additional information that could be encoded into the encrypted setup and keepalive packets sent from the clients to the mediation server.

Right now the mediation server is located in the 64.34.106.0/24 netrange.

This is irrelevant to the subject of the section. It is also no longer valid as the backend has been clustered for some time now.

There is no evidence that such backchannel information is included, but the absence of auditable source code makes it impossible to exclude the possibility ..

This statement is misleading. It implies that availability of auditable source code would resolve these issues, which is incorrect. See my comment above for detailed explanation.

.. and the license says: "... the End-User may not decompile, reverse engineer, disassemble, modify ... the client software"

This statement is misleading. It implies that should the license permitted reverse engineering of the code, it would allow excluding the possibility of stated problem. If you have the information on auditing techniques that operate with reverse-engineered binaries, please provide the reference.

Alex Pankratov 18:37, 14 June 2006 (UTC)

Steve Gibson: Hamachis trustworthiness makes "...me anxious and continues to make me anxious." (restored)

I must admit that I made a mistake. Stating that Gibson positively reviewed Hamachi is probably a wrong statement considering this passage in the transcript of the podcast following the one referenced in the article:

"LEO: ... One other note I got from a good friend and Perl wizard, Randal Schwartz, he's the author of "Learning Perl" and really a great guy, had a couple of questions for you. First of all, he said, Hamachi's not open source. How can we trust it?

STEVE: Ah, well, that's a very good point. I mean, it's one of the things that made me anxious and continues to make me anxious. I'm going to end up probably over on OpenVPN, which is how we're going to wrap up this episode of Security Now!." http://www.grc.com/sn/SN-019.txt

Any suggestions how to fix it ? --Ministry of Truth 17:40, 9 June 2006 (UTC)

Trustworthiness of closed source software is a big issue on its own, which probably deserves separate Wikipedia article.

Leo's friend, Steve and other people tend to mix open source with open standards. Closed source software is not going anywhere, including VPN and security software. And the simplest way to establish a degree of trust is to verify that it complies with open standards. This is how it is handled with traditional VPNs. See for example Virtual Private Network Consortium.

Alex Pankratov 18:20, 9 June 2006 (UTC)

No, you didn't make a mistake. I think the following quote from Episode 18 of Security Now! is pretty unambiguous:

"STEVE: I had my fingers crossed while I was vetting the security architecture, thinking, oh, this, I mean, oh, and the UI is polished. I mean, it's a professionally assembled, beautiful piece of work. I mean, I can't recommend it highly enough." http://www.grc.com/sn/SN-018.txt

The rest of the podcast is completely positive. The concern expressed in the later podcast you mention is already covered sufficiently in the multiple paragraphs which emphasize the closed source nature of the application. --Thylark 22:27, 9 June 2006 (UTC)

Upon actually going back and reading the transcript, I feel I necessary to provide the complete quote:

'STEVE: Ah, well, that's a very good point. I mean, it's one of the things that made me anxious and continues to make me anxious. I'm going to end up probably over on OpenVPN, which is how we're going to wrap up this episode of Security Now!. But Hamachi is - I'm convinced that Alex has really designed this system exactly as he's told me he has. He's got years of experience with security, implementing IPSec tunnels, you know, classic VPN solutions. I couldn't feel any better about this than I do, short of doing a complete source audit and, you know, build verify and all that, which is just not practical. So it's certainly the case though that, well, I mean, you know, we're trusting Bill when we use Windows.

Your partial quotation is misleading and now makes me question your motives for your edits. Clearly when looking at the whole statement Gibson still recommends the product. I respect and recognize your skeptical point of view is necessary to maintain balance of this article, but we are looking for a neutral point of view, as per Wikipedia guidelines. Please try to remain objective in the future. --Thylark 22:58, 9 June 2006 (UTC)

I was asking an open question in this section, Thylark, seeking advice. I completely agree that either more context to the "anxious" quote or one pro quote from the previous podcast and the correction would be needed to achieve NPOV. I suggest we link the transcripts rather than the mp3 files to provide better reference. --Ministry of Truth 22:22, 11 June 2006 (UTC)

Restored this section to this revision.

Alex Pankratov 14:31, 13 June 2006 (UTC)

section "Steve Gibson: Hamachis trustworthiness makes "...me anxious and continues to make me anxious." got lost (restored)

Could the discussion that was deleted under the header Steve Gibson: Hamachis trustworthiness makes "...me anxious and continues to make me anxious." please be restored.

I just added an extended Gibson quote according to the result of our debate so far. While I believe it to do the content of the podcasts justice, I am open for comment. --Ministry of Truth 09:24, 13 June 2006 (UTC)

This is a good progress. I added references to p2p-hackers and cryptgraphy maillists back into the article. These (especially latter) constitute the fact of a (limited) peer review in addition to Steve Gibson's opinion. Moreover cryptography maillist is known to be *the* place of interest for industry/academic cryptography professionals. That is why these references are important.

I would also like to the last part of Security section reworked. I understand the rationale for it, but it its current form it implies that Hamachi is insecure. The quote needs to be replaced with more relevant discussion.

Alex Pankratov 14:47, 13 June 2006 (UTC)

Thank you for restoring the integrity of the discussion ..

This is the third time you make an innuendo about my discussion style. Please try to refrain from this as it neither helps the discussion nor it gets the article closer to the completion. Thank you.

Alex Pankratov 19:10, 13 June 2006 (UTC)

.. and acknowledging progress. Adding sources to the mailinglist discussion makes it certainly better than the previous, completely irrelevant line.

I disagree the line was irrelevant. The importance and the significance of these mailing lists is evident to anyone who's familiar with a subject area.

Alex Pankratov 19:10, 13 June 2006 (UTC)

From the few posts I've been able to find, I see strong support for my suggestion to include a warning on Hamachis beta status that may affect security-related functionality.

Please elaborate on this. Beta status applies to the implementation, not the design.

Alex Pankratov 19:10, 13 June 2006 (UTC)

I'd also suggest that you refrain from editing the article on your own, in particular without any debate here showing consensus.

I'd also suggest that you too refrain from making sweeping changes to the article without obtaining the very same consensus. I appreciate that you RFC'd "outstanding security issues" section first and that is very much in line with WP guidelines. Unfortunately you have also demonstrated at least partial lack of the expertise in the subject area with some of your earlier edits that did not go through the discussion first. My recent edit intended to undo some of these changes until we have a chance to discuss them.

Alex Pankratov 19:10, 13 June 2006 (UTC)

As you have a vested interest in the success of product, you're necessarily biased.

I disagree. This is your opinion. Affiliation with a product does not automatically mean unavoidable bias. Moreover someone who's initmately familiar with the subject may actually have more insight on related matters than an outsider.

Alex Pankratov 19:10, 13 June 2006 (UTC)

For now, I've reverted the changes to the mailinglist-part until we can get sorted whether it's relevant ..

It is relevant for the same reasons GRC review is. People skilled in the art talking about the matter at hand and expressing their opinions.

Alex Pankratov 19:10, 13 June 2006 (UTC)

.. and how we could ease the access to significant posts if there were to be any. peer review has a definition, Isn't there anything better ? --> "Cite list archives only when no other source is available." WP:RS --Ministry of Truth 16:20, 13 June 2006 (UTC)

Linked WP page does not contain quoted text.

Alex Pankratov 19:10, 13 June 2006 (UTC)

First of all, while it is clear Apankrat has a vested interested in this article, it does automatically preclude his contributions. His interest highlighting the positive aspects of Hamachi (for whatever reason) is equally as valid as the desire of Ministry of Truth to clearly describe any potential security flaws with the product. One of the aims of wikipedia is to provide an article that encompasses all points of view, and there is no reason a consensus cannot be reached by included both view points in the article. Specifically in regards to the last reverted edits, I see no reason why the full Gibson quote cannot be included. It is verifiable and accurate and has the benefit of supporting both your views; that Hamachi is strongly endorsed by Gibson, but is closed source and therefore not fully audited by him or anyone else. However, in regards to the mailing list, I find it less clear. As an industry outsider, the authority of this forum as "the place" to discuss is not apparent and the link is not easily verifiable (at least without reading a bunch of archived emails). However, on the other hand the reference as added did not say anything about what was the consensus on this message lists were, rather just provided a link. I think ideally, a link to the specific messages endorsing, or contesting hamachi would be useful, but since this may not be practical perhaps the link can be moved to another section. As written, that is grouped with Gibson's endorsement, it implies that the consensus was positive (which I am guessing is the case). However, if moved to a new paragraph, perhaps at the end of the security section. It can be placed in a neutral context where it is just providing a link to more information if the reader desires rather than presented as a peer reviewed endorsement.--Thylark 08:05, 14 June 2006 (UTC)

Thylark, do you mind restoring Gibson quote to its full version ? MoT and myself already touched that part so 3rd party edit would be more appropriate.

Alex Pankratov 19:31, 14 June 2006 (UTC)

There is no such thing as a "full version". I have put considerable effort in crafting a compact excerpt faithful to what Gibson said in his podcasts and feel that Apankrats additions re-introduce bias. Plus, the "you can trust Hamachi because you trust Microsoft" and its conclusion are logical fallacies and have no place here. That is, unless you feel that utterances such as "I think you made a comment, I don't remember if it was before the podcast or under your breath, that was like, you know, Alex Pankratov sounds like a Russian..." equally deserve to be quoted...

There is a consensus between Apankrat and myself that the html-versions are easier to read than the text version. That got lost in my revert, so I've fixed it unless there are reasons I'm unaware of to prefer the ASCII text. I also rectified an episode number - the second part of the quote is from the following podcast. Thanks for taking care of the typos. --Ministry of Truth 23:23, 14 June 2006 (UTC)

The quote deals with Mr. Gibson's opinion, which as any other opinion may or may not be perceived biased. Since you find the meaning of a compact excerpt to be different from complete quote, I fail to see how your 'crafted' version is 'faithful' to what Gibson said. I also disagree with your interpretation of Microsoft-Hamachi bit. It merely states a fact that establishes the context for the trailing part of the quote. It does not imply or conclude that Alex is as trustworthy as Bill.

Alex Pankratov 02:33, 15 June 2006 (UTC)

Initially, the excerpt was introduced to complement a previous mention of the podcast which was not faithful to its content according to Thylarks and my own reading. I was disappointed by my own lack of due diligence to check the facts myself and fixed that as soon as possible. But while you keep me thinking about it, I am more and more inclined to suggest we drop Gibson altogether. Let me quote from WP:RS#Reliability_of_online_sources:

"Publications with teams of fact-checkers, reporters, editors, lawyers, and managers — like the New York Times or The Times of London — are likely to be reliable, and are regarded as reputable sources for the purposes of Wikipedia.

At the other end of the reliability scale lie personal websites, weblogs (blogs), bulletin boards, and Usenet posts, which are not acceptable as sources. Rare exceptions may be when a well-known professional person or acknowledged expert in a relevant field has set up a personal website using his or her real name. Even then, we should proceed with caution, because the information has been self-published, which means it has not been subject to any independent form of fact-checking.

The policy page that governs the use of sources is Wikipedia:Verifiability. About self-published sources, which includes books published by vanity presses, and personal websites, it says: "Sources of dubious reliability are sources with a poor reputation for fact-checking, or with no fact-checking facilities or editorial oversight...""

By those standards, Gibson clearly fails to qualify as "acknowledged expert in a relevant field". Such an expert would not enthusiastically praise a product and pretend to have "fully vetted the system's security architecture", only to pitifully admit in the next episode, when challenged by a third party, that he failed to ask one of the most obvious and relevant questions for security evaluations, now "feels anxious" about the absence of source code availability and recommends OpenVPN instead.

You are AGAIN confusing 'system security architecture' with 'system implementation issues'. You are also misrepresenting what Mr. Gibson said. Please show us the quote where 'Gibson pitifully admits .. that he failed to ask one of the most obvious and relevant questions'.

Alex Pankratov 18:12, 15 June 2006 (UTC)

His opinion that "trusting Alex" simply because of "years of experience with security, implementing IPSec tunnels, you know, classic VPN solutions" is not a good enough reason for a serious expert to determine the trustworthiness of an architecture, implementation and the company behind the product.

Please stop mixing the architecture and the implementation. Your comments lead me to believe that you don't understand principal difference between these two and therefore you are simply not fit to comment on these matters.

Alex Pankratov 18:12, 15 June 2006 (UTC)

I agree that a review by a reputable expert would be an information definitely worth including, feel free to point out reviews meeting WP criteria you may be aware of. --Ministry of Truth 07:14, 15 June 2006 (UTC)

I disagree. You are confusing his actions with his credentials. Whatever you think of him and his reputation, he is an acknowledged expert or at least a well-known "professional person" in the field of computer security. The wikipedia article on Steve Gibson lists him as a contributing editor to InfoWorld magazine, a non-online, reputable source which describes him as such. He is well-known enough that even an anti-Gibson web site appeared ( GRCsucks.com). Now, the quotes in dispute were made in a self-published form (a podcast) which means that including them in the article would have to be one of the "[r]are exceptions". If you want to argue that we should not include it based on the fact they are not worth making an exception I would be more receptive. The article, as it stood before your edits, did not have any of the podcast quoted at all, rather just noted that Gibson positively reviewed it on his podcast. I would support a change back to that, as that statement is a verifiable fact. Whether the reader trusts Gibson's credentials and/or opinions, or wants to read/listen to his review in detail, is up to each reader. However before any changes are made I would like to hear Apankrat's opinion. --Thylark 08:47, 15 June 2006 (UTC)

One other point. The section you quoted from theWP:RS#Reliability_of_online_sources guidelines ends with a final sentence you did not include:

Note that Wikipedia itself does not currently meet the reliability guidelines.

Therefore it appears that the section quoted from the Virtual Private Network article on VPN implementation presently included in the Security section does not meet WP guidelines. I suggest that we remove it from the revamped Security section we are finalizing. --Thylark 09:03, 15 June 2006 (UTC)

I respectfully submit that I am not confusing anything. It is one thing that Gibson may meet the standards to get his own WP article. Note the absence of qualifications other than "computer engineer and journalist" in his WP entry and there are probably good reasons as well that he is not listed in Computer security specialists. Independantly of that, I also made the demonstration, by only using material from the two podcasts, that he obviously lacks the expertise in computer security and crypto to correctly assess relevant facts.

I cannot find any traces of this demonstration, leave alone for concluding that he obviously lacks the expertise. Also unlike yourself I've actually spoken with Mr. Gibson and I can confidently state that his level of crypto and security expertise is sufficient to make the judgements that he made. He was also fully aware that Hamachi is not an open source project and what issues arise from that.

Alex Pankratov 18:28, 15 June 2006 (UTC)

Not to unduly block progress on this disputed item, I am willing to accept one of two solutions: Either we just drop it, because it does not meet the criteria previously discussed, or we keep a balanced version of the excerpt that allows the reader to form an opinion on the seriousness of the claim by providing him the relevant elements of both podcasts. I am open to discuss further refinement of the excerpt if the argument can be made that the original version is no faithful representation of the content, but I'd like to keep it as compact as possible. For the VPN thing, I'm fine dropping it, see upcoming proposal for the security section. --Ministry of Truth 10:33, 15 June 2006 (UTC)

We have shown that your version of excerpt alters its original meaning, and we also demonstrated that Mr. Gibson's opinion is relevant. Whether he qualifies to be an expert as per your criterias is irrelevant to this article. The criticism of this kind belongs to Gibson's WP page. I am open to reverting back to the original version of the part as per Thylark's comment.

Alex Pankratov 18:28, 15 June 2006 (UTC)

Thylark, thank you for your thoughtful, balanced post. Indeed, Apankrat is not automatically precluded from contribution, however his edit history suggests that it would be preferable that he waits for a consensus to build here before he steps up to edit the article.

Ministry of Truth, this will remain your subjective opinion until you present the list of changes that indeed 'suggest' what you imply. Thank you

Alex Pankratov 17:53, 14 June 2006 (UTC)

I do share your concern about the mailing list. Perhaps we should wait until a case for relevance can be made before we discuss the best way to include it. Apankrat, I was referring to this version of the RS page: Reliable_sources --Ministry of Truth 09:21, 14 June 2006 (UTC)

The guideline you quoted was removed from RS page. According to its talk page authors are now 'favoring full endorsement of moderated discussion archives'. Both maillists I referenced are moderated.

Alex Pankratov 17:53, 14 June 2006 (UTC)

Be that as it may, it is a necessary, but not sufficient condition, the demonstration of relevance is still to be made. --Ministry of Truth 18:23, 14 June 2006 (UTC)

The list is comprised of 'people skilled in the art', the subject is brought up, it is discussed, clarifications are requested and answers are given. This list is *the* resource for this kind of discussions. How exactly this is NOT relevant ?

Alex Pankratov 18:44, 14 June 2006 (UTC)

Check the RS page, in particular WP:RS#Electronic_mailing_lists and, for background, its discussion page to understand our reluctance to consider it relevant. --Ministry of Truth 23:23, 14 June 2006 (UTC)

WP:RS guidelines discuss criterias for reliable sources of facts (WP:RS#Some_definitions). In our case the maillist is a source of opinions. Given the nature of the maillist, these opinions are relevant to the content of the section and they are reliable as they were expressed in moderated environment.

Alex Pankratov 02:33, 15 June 2006 (UTC)

See my above answer on the Gibson quote for an excerpt of criteria to be met. --Ministry of Truth 07:14, 15 June 2006 (UTC)

I don't see how it is relevant. Please carify here.

Alex Pankratov 18:30, 15 June 2006 (UTC)

Introduction to the Security section

I would like to put the following as an introduction to the Security section and sollicit comments:

The "ease of use" advantage needs to be mitigated by

• the absence of source code for review
• additional risk of disclosure of login data, IP address, time and duration of exchange with other users and possibly more data which may be logged by the mediation server

"Time and duration of exchange with other users" cannot be logged as it is not known on the server side. Only the duration the tunnel was up, I assume you meant that.

Alex Pankratov 18:07, 14 June 2006 (UTC)

That's correct, thank you for the clarification. --Ministry of Truth 18:37, 14 June 2006 (UTC)

• its current beta status and possible impact of remaining bugs on security

This needs to be discussed. You brought up this point in this thread, I asked you to elaborate on it and you haven't followed up. Please justify the link between beta status and weakended security.

Alex Pankratov 18:07, 14 June 2006 (UTC)

I submit that beta software, by definition, may contain bugs, each of which may or may not affect security. --Ministry of Truth 18:37, 14 June 2006 (UTC)

I don't know your background, but it is commonly known fact that virtually all software contains bugs. The definition of beta software varies by the vendor. For some it means 'unstable', in which case you will be right, for (majority of) others it means 'feature incomplete' as it is a case with Hamachi.

Alex Pankratov 19:01, 14 June 2006 (UTC)

• the additional single point of failure of the mediation server run by the vendor, required to initiate and keep alive connections

The single-point-of-failure part could also go into the how it works section. But it qualifies as a potential denial of service issue and can probably be better dealt with here in context with the logging problem. --Ministry of Truth 10:24, 14 June 2006 (UTC)

What is the 'logging problem' ? Please clarify

Alex Pankratov 18:07, 14 June 2006 (UTC)

I am referring to the second item of the proposed list. --Ministry of Truth 18:37, 14 June 2006 (UTC)

Single-point-of-failure is better be placed outside of the security section. This is important but security-unrelated matter. It is a matter of system resiliency rather.

Alex Pankratov 19:01, 14 June 2006 (UTC)

Fine by me. Working on an addition to "how it works" I'll submit for comment soon. --Ministry of Truth 11:06, 15 June 2006 (UTC)

RFC: new Security section

Here's the new version of the security section I propose:

Security

The following points call for careful consideration:

• the absence of source code for review
• a risk of disclosure of sensitive data which may be logged by the mediation server

Need to clarify which senstive data can be logged. Current phrasing is too vague.

Alex Pankratov 18:54, 15 June 2006 (UTC)

This is the overview, details follow a few lines later --Ministry of Truth 20:33, 15 June 2006 (UTC)

• the current beta status and possible impact of remaining bugs on security

Irrelevant, please review my comments in Talk:Hamachi#Security_issues_not_yet_addressed_in_the_article.

I have considered your comments and am not convinced, see below. --Ministry of Truth 20:33, 15 June 2006 (UTC)

• unexpected security risks due to vulnerable services on remote machines otherwise not accessible behind a NAT, common to all VPNs

Kerckhoffs' principle postulates that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Kerckhoffs' principle is traditionally applied in the context of the architectures.

Do you submit it is irrelevant ? --Ministry of Truth 20:33, 15 June 2006 (UTC)

Given the context, the section that follows offers what appears to be a layman's interpretation of this principle. And since it ignores architectural openness of the system, resulting interpretation is biased. I am willing to keep this "principle" reference if the next section is reworked as noted.

Alex Pankratov 22:41, 15 June 2006 (UTC)

Hamachi being closed source, peer review to detect possible problems is not possible, ...

Unnecessary broad statement, needs to be replaced 'peer review of the implementation'. Also needs to be amended to say that Hamachi architecture is open. Otherwise the statement is misleading and biased.

Could you elaborate how that fits in with this reply of yours:

"> The protocol description is missing some details, so cannot say

>> anything about them (things like what is the format of Ni, Nr, Gi, Gr

>> when sent over wire and when put to the signatures etc, are the Gi, Gr

>> always the lenght of modulus (2048 bits) etc).

What would you like to know exactly ? The page was not meant to

be a bit-level description of messages, merely a description of

the security framework." http://www.mail-archive.com/cryptography@metzdowd.com/msg05790.html --Ministry of Truth 20:33, 15 June 2006 (UTC)

Message formats described on the page are complete and accurate. 'Bit-level' remark refers to the encoding/serialization rules. These rules are trivial to recognize for anyone familiar with protocol analysis therefore they were omitted for clarity. Their description is available on a separate page - http://hamachi.cc/security/encoding.txt.

Alex Pankratov 22:41, 15 June 2006 (UTC)

.. see also the VPN article. For the product to work, a "mediation server", operated by the vendor, is required. This server stores the login, password ..

Client authentication is not password based. There are so-called network passwords, which are optional and can be replaced with manual authorization process.

There might be a misunderstanding here: I am referring to the nickname/internal IP/maintenance password and the associated authentication and welcome appropriate language suggestions. --Ministry of Truth 20:33, 15 June 2006 (UTC)

Current version is fine with me. Just wanted to make sure we were on the same page terminology-wise.

Alex Pankratov 22:41, 15 June 2006 (UTC)

.. and internal IP address of the user, and for every established tunnel it could log the real IP, time, duration and other connected users. For now, it cannot be excluded, nor is there evidence suggesting it, that additional information migth be encoded into the encrypted setup and keepalive packets to the mediation server.

Need to add the discussion about how open security specs enable full protocol analysis and how this can be used to verify the content of 'encrypted setup and keepalive packets'.

see above ML quote. --Ministry of Truth 20:33, 15 June 2006 (UTC)

Replied there.

Alex Pankratov 22:41, 15 June 2006 (UTC)

Hamachi is still in beta and frequent changes to the code base of both the client and the server software increase the probability of bugs, which may affect security.

Speculative, needs to be removed or rephrased.

I submit that frequent changes in source code, for whatever reasons, increase the probability to introduce bugs, that this is the case for Hamachi, see http://forums.hamachi.cc/viewforum.php?f=14 and challenge you to rebutt. --Ministry of Truth 20:33, 15 June 2006 (UTC)

What is your definition of 'frequent' ? It is also your responsibility to demonstrate that Hamachi being in beta "increases the probability of bugs, which may affect security". Until there is a factual backing to this claim, especially its second part, it will remain speculative.

Alex Pankratov

The vendor provides a description of the security architecture[3].

This belongs to the part that talks about peer review above.

Fair point, agreed. --Ministry of Truth 20:33, 15 June 2006 (UTC)

As all peers sharing a tunnel have full "LAN-like" access to each others computers, security problems may arise if no appropriate action is taken.

Speculative and misleading.

Open for alternate language to be suggested. The idea is to make the user aware that his border routers NAT/firewall no longer protects local services, which might be unexpected for the less network literate users. --Ministry of Truth 20:33, 15 June 2006 (UTC)

Fair enough. I think we agree that the wording needs to be more precise as to specify the nature of 'security problems' and 'appropriate actions'.

Alex Pankratov 22:41, 15 June 2006 (UTC)

The security features of the NAT router/firewall are bypassed. This is not specific to Hamachi and needs to be addressed with other VPNs as well.

Apankrat, if you still feel that's needed, please provide language to include your take to complement the security review paragraph. Until a consensus can be reached, I would like to either append the original version of the Gibson excerpt or none at all. I have taken the objection to the large quote from the VPN article into consideration. --Ministry of Truth 11:06, 15 June 2006 (UTC)

I would probably like to see Security section split into two parts. One that talks about features and caveats of the solution including items from your list above, and another that deals with opinions of other people about it. This seems like a natural arrangment. Regarding Mr. Gibson's quote - I strongly disagree that your 'crafted' version of quote is both representative and accurate. As I said above I am OK reverting to the version that existed prior to your edits.

Alex Pankratov 18:54, 15 June 2006 (UTC)

That may be logical. Describing the security design and potential problems in one section, and opinion in a second. Or, if enough material warrants it, a completely distinct section could be created for opinion. MoT, your thoughts? I also believe that the Gibson quote is relevant and the version as it stands is a true and accurate reflection of Mr. Gibson's statements. I see no clear reason for editing the comments; in fact I like it as it nicely sums up both your positions. --Thylark 20:22, 15 June 2006 (UTC)

That may be logical. Describing the security design and potential problems in one section, and opinion in a second. Or, if enough material warrants it, a completely distinct section could be created for opinion. MoT, your thoughts? I also believe that the Gibson quote is relevant and the version as it stands is a true and accurate reflection of Mr. Gibson's statements. I see no clear reason for editing the comments; in fact I like it as it nicely sums up both your positions. --Thylark 20:22, 15 June 2006 (UTC)

I'll get back to the Gibson quote once I'm done with commenting "How it works". --Ministry of Truth 20:33, 15 June 2006 (UTC)

RFC: additions to "How Hamachi works" section

Here's what I would like to add and change in the "How Hamachi works" section, I've included the whole section here to ease review:

How Hamachi works

Hamachi installs a virtual network interface on a computer. Hamachi then tunnels all IP and IPX traffic sent to this interface over a specially initiated UDP connection between hosts using the existing routing functions of the computer's TCP/IP stack.

Hamachi requires a third party "mediation server" to bootstrap and maintain the connections between hosts on a Hamachi network. Currently named bibi.hamachi.cc, resolving to 64.34.106.33, ..

Invalid statement. Please review my comments in Talk:Hamachi#Security_issues_not_yet_addressed_in_the_article from Jun 14th.

Alex Pankratov 19:11, 15 June 2006 (UTC)

Feel free to correct all factual errors, I appreciate that you share your intimate knowledge of the product with us to improve this article. --Ministry of Truth 21:11, 15 June 2006 (UTC)

"Primary Hamachi server is named bibi.hamachi.cc, and it may redirect clients to secondary servers in Hamachi backend cluster as needed." This is a gist of how it works, it can probably benefit from rewording.

Alex Pankratov 23:11, 15 June 2006 (UTC)

Would you kindly provide more than the gist ? Please be factual, you of all people should have detailed knowledge to share. --Ministry of Truth 17:51, 16 June 2006 (UTC)

"Primary Hamachi server is named bibi.hamachi.cc, and it may redirect clients to the secondary servers in Hamachi backend cluster.". That is exactly how it works.

Alex Pankratov 22:58, 16 June 2006 (UTC)

.. it constitutes a single point of failure not present in other VPNs.

Invalid statement. Please review my comments in Talk:Hamachi#Security_issues_not_yet_addressed_in_the_article from Jun 14th. More accurate wording would be 'that may or may not be present in ..'.

Alex Pankratov 19:11, 15 June 2006 (UTC)

Perhaps deleting the "not present in other VPNs" would do the trick ? Perfectly fine by me. --Ministry of Truth 21:11, 15 June 2006 (UTC)

Fine with me.

Alex Pankratov 23:11, 15 June 2006 (UTC)

If it is not reachable, because of local firewall policy, server downtime or other reasons, no tunnels can be established and those already up will go down.

The last part is incorrect, tunnels stay up for as long as they are keep-alived by both peers. Please make sure to check your facts.

Alex Pankratov 19:11, 15 June 2006 (UTC)

Again, sharing your knowledge how long a tunnel stays up when the mediation server dies would be appreciated. --Ministry of Truth 21:11, 15 June 2006 (UTC)

This feature is called "tunnel persistence", it is 10 months old and it is described here.

Alex Pankratov 23:11, 15 June 2006 (UTC)

Are older versions still in significant use ? Does that mean that there are no keepalive packets anymore ? How was the problem they were supposed to address solved ? --Ministry of Truth 17:51, 16 June 2006 (UTC)

Q1 - No, there is no significant use of versions that don't support tunnel persistence. Q2&Q3 - You are confusing things. Keepalive packets were previously discussed in the context of client-to-server connection. Tunnels are between clients, so the 'persistence' feature applies to p2p traffic only.

Alex Pankratov 22:58, 16 June 2006 (UTC)

I2P is an ongoing open source effort to implement a slightly different approach not requiring such a third party.

Largely irrelevant. Belongs to 'See also' section.

Alex Pankratov 19:11, 15 June 2006 (UTC)

Not so sure. Similar, yet different approach doing away with the requirement for a central mediation server sounds pretty relevant to me. Thylark, any thoughts on that one ? --Ministry of Truth 21:11, 15 June 2006 (UTC)

The tunnels use routable, ..

Bad wording. Tunnels do not have a property of being routable.

Alex Pankratov 19:11, 15 June 2006 (UTC)

routable refers to IP space, not tunnels and I think the wording is pretty clear.

(moved your comment here) Alex Pankratov 23:11, 15 June 2006 (UTC)

.. unallocated IP space in the 5.0.0.0/8 IP range, which is discouraged by RFC ..

Please provide exact reference to the 'discouraged' statement.

Alex Pankratov 19:11, 15 June 2006 (UTC)

.. and will cause conflicts as soon as the IANA allocates these addresses.

Need to replace 'will' with 'may'.

Alex Pankratov 19:11, 15 June 2006 (UTC)

You're perfectly correct about the will/may problem, I have fixed it to be more articulate about how exactly this breaks network integrity:

The tunnels use routable, unallocated IP space in the 5.0.0.0/8 IP range, which is discouraged by RFC. It will cause address conflicts as soon as the IANA allocates these addresses and prevent Hamachi users from connecting to "real" IP addresses in that range as long as the tunnel stays up. --Ministry of Truth 21:11, 15 June 2006 (UTC)

I still don't like "routable" bit, because it sounds similar to "globally routable" and therefore may be confusing. It might be better to describe H's function in terms of Overlay networks. The point that needs to be carried across is that Hamachi creates 'separate routing domain'. Therefore IANA's assignment of 5/8 space may lead to routing ambiguities. I'd also like to see "discouraged" comment to be either removed or extracted into a separate statement.

Alex Pankratov 23:11, 15 June 2006 (UTC)

Is this an acceptable variant:

The tunnel endpoints have addresses from the 5.0.0.0/8 IP range. The IANA did not authorise the use of this currently reserved network and as soon as the block gets allocated, the resulting conflict will prevent peers from connecting to any "real" IP addresses in that range as long as the tunnel stays up. --Ministry of Truth 17:51, 16 June 2006 (UTC)

---

It is about the same as a previous version. See if this version works -

Hamachi endpoints are assigned addresses from 5.0.0.0/8 IP range, and they use it exclusively for communicating with other Hamachi endpoints. This range is currently reserved by IANA and it is not used on the Internet. Should it get allocated, it will create routing ambiguities for the computers running Hamachi and may result in 'real' IP addresses in that range not being accessible from these computers.

Alex Pankratov 22:58, 16 June 2006 (UTC)

Hamachi likely establishes the connection between two NATed hosts by directing them to initiate network connections to each other at the exact same time. Since the mediation server knows the public NATed IP addresses of the two hosts, it can direct the hosts to connect to each other at the same time to their respective public IP addresses. Once a connection is established, as long as the Hamachi clients send periodic traffic, the ports will remain open on the NAT devices. This process does not work on about 5% of NAT devices, requiring the user to explicitly set up a port forward.

When a user named G12 brought up UDP hole punching on the Hamachi forums one of Hamachi’s developers, apankrat, responded by saying, "... [it will] get you p2p connectivity in roughly 80% of all cases. How to get it to Hamachi's 97% is another question.[4]

There is a possiblity that the mediation server accepts connections from both clients and so by knowing which TCP port number was used for outbound traffic on the other side the known entry port to direct to the right machine through the NAT is known.

Hamachi must also be able to determine the return port that connections are being translated to on the NAT device. The mediation server might assume that return port numbers on the NAT device are assigned in numerical order, and thus assume that the port number the NAT device will use will be the port number subsequent to a port number used to connect to the mediation server.

Hamachi 1.0 Beta can relay traffic through a 'relay server' to enable a connection for users that are otherwise unable to configure an unsupported NAT device.

The finer point here is that the lack of p2p connectivity depends on the _combination_ of NATs on both sides. Referencing 'unsupported NAT device ' is inaccurate strictly speaking.

Alex Pankratov 23:11, 15 June 2006 (UTC)

How would you put it ? --Ministry of Truth 17:51, 16 June 2006 (UTC)

"Unsupported combination of NAT devices" ? Kind of long, but accurate.

Alex Pankratov 22:58, 16 June 2006 (UTC)

The "How it works" section could definitely use some more cleanup, even if Thylarks previous edits massively contributed to better readability. We should take out the weasel words such as "likely" and either find a relevant way to substantiate the claims in the "a user named G12 brought up" part, keep it in sync with the 5% claim in the line above or drop the percentage indication and the forum quote completely and simply keep something like: "This process does not work on a certain number of NAT devices, requiring the user to explicitly set up a port forward."

5% is an operational number that is made available to the public by the vendor. Getting this number mentioned is essential to the article, because Hamachi's main stregth is its effecient NAT-to-NAT traversal capabilities. Typical failure rate of STUN is 20% (see stun and midcom ietf discussion groups for details) and 5% vs 20% is very much relevant. This number is also easily verfiable by any user with sufficient number of connected clients.

Alex Pankratov 19:11, 15 June 2006 (UTC)

I wholeheartedly agree on the relevance of the percentage and therefore invite you to provide quotable-by-WP-standards evidence to support your claim if you want it included. --Ministry of Truth 21:11, 15 June 2006 (UTC)

Here is a couple of links, not sure if you are going to argue again that ML references are no good, etc -

http://zgp.org/pipermail/p2p-hackers/2005-February/002426.html

http://www.hamachi.cc/howitworks

Note that the number on second page is lower, it was adjusted based on additional year of statistics (compared to first link). Also just to reiterate important point - these numbers are easy to verify. For example, simply entering a handful of public well-populated Hamachi networks will quickly yield 100+ peers, which then can be used to estimate successful connectivity rate.

Alex Pankratov 23:11, 15 June 2006 (UTC)

The ML post lost me completely and you assume correctly that indeed, until you can come up with anything quotable, the percentages will have to go. For now I'd dump the G12 thing completely and keep the "certain number" for the other. --Ministry of Truth 17:51, 16 June 2006 (UTC)

I came up with quotable references. No offence, but the fact that it gets you lost is not a reason enough to dump vital piece of information from the article. We will need to hear other opinions on this matter before deciding if the percentages 'will have to go' or not. You have also not commented on the fact that quoted number is easily verifiable.

Alex Pankratov 22:58, 16 June 2006 (UTC)

Another effort to further de-obfuscate some of the language might be useful as well. --Ministry of Truth 11:55, 15 June 2006 (UTC)

Agreed. I don't particularly like the 'brought up' bit either. I can contribute more accurate description, but I am also bound by confidentiality of certain parts of this information.

Alex Pankratov 19:11, 15 June 2006 (UTC)

What is "confidentiality of certain parts of this information" referring to ? --Ministry of Truth 21:11, 15 June 2006 (UTC)

Specifics of tunnel setup logic. Nothing related to the security/trustworthiness of the system.

I will explicitely let everyone know when/if we come across any of such topics.

Alex Pankratov 23:11, 15 June 2006 (UTC)

Still not the faintest idea what you're talking about... As you want to keep the details of the how-it-works-part secret we could probably get rid of most of the cruft in this section by adding something like

Hamachi uses a NAT-traversal technique, detailed information how it exactly works are kept secret by the vendor, who claims to achieve better results than other methods.

It is a public knowledge that Hamachi utilizes a technique similar to UDP hole punching. This has been discussed in forums and on maillist(s). There are additions to this technique that *are* kept secret. Replacing the description with your version will essentially trim valid and useful information from the article.

Alex Pankratov 22:58, 16 June 2006 (UTC)

Feel free to add extra information you might be willing to provide --Ministry of Truth 17:51, 16 June 2006 (UTC)

Exhaustive argument against the Gibson quote

Let me address that Gibson-problem and try to summarize the essence of what has become a difficult-to-follow debate we've had so far all over the place:

What was the problem of the version on this page when the discussion started ? Here it is:

"The security architecture of Hamachi has been reviewed and endorsed by computer security expert Steve Gibson on Episode 18 of his podcast Security Now!"

1. Gibson is anything but a "security expert" as we'll see --> POV
2. Failing to mention episode 19, it does not faithfully represent his opinion on Hamachi, again resulting in a biased entry

Whatever the result of the discussion whether the podcast passes the tests in WP:RS as a reliable source, misrepresenting his opinion by leaving out important additions he made in the following episode is lying by omission and therefore not an option at all. There has been debate about what to include in an excerpt, but as long as the relevance is not established, the negotiation about what extra half-sentence to include or leave out is not on the table for now.

Relevant vs. Expert

There has been some confusion when it was argued that both Gibson and the Security Now! podcast had WP entries and were for that reason alone acceptable sources.

This is not necessarily so and John C. Dvorak is the canonical example of such a case. He has the merit to have publicly admitted his machiavellian scheme to deliberately make spectacular statements of questionable accuracy to provoke controversy, then claim to have been tragically misunderstood once the hate-mail starts to flow in, to finally reverse his position to elicit even more excited reactions. While this disrespectful attitude has worked well for him to build a large audience, thereby qualifying for a WP entry, such intellectually dishonest behavior would also clearly disqualify his reviews as a reliable source.

Similar methods in newsgroups and forums to disrupt meaningful discussions or draw attention, are called trolling. Note that the discussion of Dvorak is to illustrate the section's title and not meant to be an implied statement on Gibsons attitude the reader will independently evaluate as he sees fit based on evidence provided below.

Why is Gibson not an expert and therefore his podcast not a reliable source ?

Gibson is not an "acknowledged expert in a relevant field", a WP:RS requirement:

1. Real security experts, as defined by having published scholarly papers, books, spoken at reputable security conferences or contributed to high-profile mailing lists such as Bugtraq usually either won't dignify Gibson by commenting on him and when they do, typically consider him to be an empty shirt.[5]
2. Among other questionable statements, some of which are debunked in his WP entry, Gibson makes the preposterous claim to have independently re-invented a mechanism similar, yet inferior, to syncookies in 2000 when the original work of Bernstein and Schenk took place in 1996 and syncookies were implemented in Linux by 1997 for nobody even remotely interested in the subject to ignore. Gibsons attempt missed important aspects of the problem the original inventors had solved by adding some crypto.
3. Finally, let's take a look at what he said in the two episodes of his podcast dealing with Hamachi: In the first one, he has nothing but enthusiastic praise and claims he has "fully vetted the system's security architecture".
   The following week, Randal L. Schwartz raises quite an important question: "Hamachi's not open source. How can we trust it?". You might expect an "acknowledged expert" would have thought of that one on his own. Gibsons answer "...that made me anxious and continues to make me anxious. I'm going to end up probably over on OpenVPN", an open source VPN, is quite telling. How could such an important aspect of a complete review not be included in the previous episode ? It basically boils down to Gibson believing Hamachi to be secure, because he trusts Alexandre Pankratow to have told him the truth. Don't take my word for it, you can check out Gibsons tortuous line of reasoning in the Appendix provided for convenient reference.

Conclusion

Does someone without any of the generally accepted credentials as enumerated, a long history of flat out wrong or severely inaccurate statements in the field he is said to be an "acknowledged expert" in and who fails to deliver a complete security review of a "fully vetted" product, unless prompted by a listener to address a crucial aspect, really qualify as a reliable source ?

I submit he does not. --Ministry of Truth 16:26, 16 June 2006 (UTC)

Please comment here

I would be very grateful if you considered to kindly insert your comments in this section, rather than within the above text to keep the flow of the argument together.

The subsections should be helpful to refer to the part you want to address. Thank you. --Ministry of Truth 16:26, 16 June 2006 (UTC)

---

Firstly -

> Does someone [...] (with) a long history of flat out wrong or severely inaccurate statements in the field..

Please reference or list here this 'long history of flat out wrong or severely inaccurate statements in the field', where the field presumably being security. With an exception of your mentioning of SYN cookies I fail to see any traces of this 'history'.

> In the first one, he has nothing but enthusiastic praise and claims he has "fully vetted the system's security architecture".

This statement is as accurate and correct as it can possilbly get. He is talking system security architecture, not the details of the implementation, which would be the subject of episode #19 quote. See below for more.

> The following week, Randal L. Schwartz raises quite an important question:...

Correct me if I am wrong, but even though Mr. Schwartz has its own WP entry and is an accomplished computer scientist, he is not exactly an expert in cryptography or security. While his question is valid, he appears to fall into the same logical pitfall that you, MoT, do, and which you consistently ignore every single time it is brought up. Open Source != Trustworthiness. Therefore the matter, while important, is not as crucial as you paint it.

My rebuttal is not to address the issue of Mr. Gibson being (or not being) security expert. It is to demonstrate the lack of factual backing and the bias of Ministry of Truth arguments.

Secondly-

I am fully aware of the controversy surrounding Mr. Gibson personality, but the issue at hand is if his opinion on the subject of the article is relevant and worth the inclusion. As demonstrated by Thylark, the answer is yes, it does. Should he be referenced to as 'security expert' ? Hard to say. Neither myself nor MoT are in the position to decide this. This discussion however does not belong here, it needs to go onto Gibson's WP page.

I suggest that we simply drop 'security expert' prefix, link to Mr. Gibson's WP page and let people unfamiliar with Mr. Gibson's personality to get all relevant information there.

Alex Pankratov 22:32, 16 June 2006 (UTC)

First of all, thank you for taking the time to clearly present you argument. I will now respond to your points.

I accept both your original points. Although Gibson has been characterized as a "security expert" in many places, that is a nebulous title without specific qualifications and Gibson has his detractors. He is however definitely a well-known personality in the field, and at the very least can be classified as a computer journalist in addition to software engineer based upon his body of work (writing at least one piece of commercial software and being a contributing editor in an industry magazine) . In deference to accommodating all points of view, I would support a change to a more neutral description, or more simply delete the term "security expert" and just leave it as "endorsed by Steve Gibson on Episode...". A quick link to the Steve Gibson page could fill the reader in on Gibson's credentials and reputation if desired. Also, you are correct to note that this sentence as previously written did not acknowledge Gibson's concerns voiced in episode 19 which should be included to better reflect the whole truth.

However, regardless of your opinion on Mr. Gibson's expertise, he did publicly make these comments regarding the Hamachi application on two episodes of the popular Security Now! podcast (currently #12 technology podcast at PodcastAlley[6]). I believe his public profile, and the popularity of the podcast, make the quotation relevant and therefore it should be included. Since there is no evidence of a "machiavellian scheme", it is up to the reader to decide whether or not Gibson's opinion is worth anything, not the editors.

The WP:RS requirement, as pointed out by Alex previously, applies to facts, not opinions. I think that we can all agree that the quote in this article is a accurate reflection of Gibson's words. The fact here is that Gibson did endorse Hamachi and is not in dispute. Therefore, the podcast (and associated transcript) are reliable sources under WP guidelines as they true reflection of the facts. And even if the WP:RS were to be applied, a close examination of the guidelines says inclusion may be acceptable:

Rare exceptions may be when a well-known professional person or acknowledged expert in a relevant field has set up a personal website using his or her real name

Gibson is a "well-known professional person... in a relevant field... using his... real name" and therefore can be included.

I appreciate your point of view, but my opinion is that the quote is relevant to this article. I suggest the cleanest, most balanced, way of including the Gibson quote would be as it is written. The quote contains the relevant sections from both podcasts and includes the positive review and the concerns over the lack of a full source audit. Alternatively, the original wording could be used (removing "security expert" as suggested above) with the addition of a second sentence describing Gibson's concerns in the second podcast although I feel this is probably a more clumsy solution. --Thylark 23:14, 16 June 2006 (UTC)

Appendix

LEO: That'd be bad thing. One other note I got from a good friend and Perl wizard, Randal Schwartz, he's the author of "Learning Perl" and really a great guy, had a couple of questions for you. First of all, he said, Hamachi's not open source. How can we trust it?

STEVE: Ah, well, that's a very good point. I mean, it's one of the things that made me anxious and continues to make me anxious. I'm going to end up probably over on OpenVPN, which is how we're going to wrap up this episode of Security Now!. But Hamachi is - I'm convinced that Alex has really designed this system exactly as he's told me he has. He's got years of experience with security, implementing IPSec tunnels, you know, classic VPN solutions. I couldn't feel any better about this than I do, short of doing a complete source audit and, you know, build verify and all that, which is just not practical. So it's certainly the case though that, well, I mean, you know, we're trusting Bill when we use Windows.

LEO: Right.

STEVE: We're, you know...

LEO: But that's why a lot of people say use open source security software and only open source security software because you don't know what government backdoors are in there and so forth. Things like PGP, you know what's in there.

STEVE: Well, that's certainly the case. And in fact, I think you made a comment, I don't remember if it was before the podcast or under your breath, that was like, you know, Alex Pankratov sounds like a Russian...

LEO: Who is this guy, KGB?

STEVE: Exactly. Who are we - well, and in fact, it's why I went around and around with him to make sure, for example, that the asymmetric key pair generated by the client was never given at any point, was given to the server or left the client, so that it wasn't necessary for us to trust the Hamachi server. And, you know, I'm sure Alex has told me the truth, but I have no proof of it. So listeners should certainly be aware of that. http://www.grc.com/sn/SN-019.txt:

Let's turn the page

It looks like we're not getting anywhere with the current approach to fix the page. To conform with WP:V#Burden_of_evidence:

"The burden of evidence lies with the editors who have made an edit or wish an edit to remain. Editors should therefore provide references. If an article topic has no reputable, reliable, third-party sources, WikiPedia should not have an article on that topic." and "Be careful not to err too far on the side of not upsetting other editors by leaving unsourced information in articles for too long, or at all in the case of information about living people. Jimmy Wales has said of this: "I can NOT emphasize this enough. There seems to be a terrible bias among some editors that some sort of random speculative 'I heard it somewhere' pseudo information is to be tagged with a 'needs a cite' tag. Wrong. It should be removed, aggressively, unless it can be sourced."

I suggest that we briefly discuss the version of what is reasonably undisputed consensus as of today as posted in the following section. The inclusion of material I am still not happy with is hopefully evidence enough that this is not an attempt of Wikipedia:POV_pushing. Once we've agreed on the new page, we can patiently duke it out point by point and add more consensual content as it builds up. --Ministry of Truth 11:02, 17 June 2006 (UTC)

Hamachi page update

See also Seriola quinqueradiata for the fish and sushi.

{{POV}}

Hamachi

Hamachi screenshot
Developer(s)	Applied Networking Inc.
Stable release	0.9.9.9 / Sep 2005
Operating system	Microsoft Windows, Linux, Mac OS X
Type	P2P, VPN
License	Freeware
Website	www.hamachi.cc

Hamachi is a zero-configuration virtual private networking (VPN) freeware application capable of establishing direct links between computers that are both NATed without requiring NAT reconfiguration in most cases. Currently available as a beta version for Microsoft Windows, Mac OS X and Linux.

How Hamachi works

Hamachi installs a virtual network interface on a computer, then tunnels all IP and IPX traffic sent to this interface over a specially initiated UDP connection between hosts using the existing routing functions of the computer's TCP/IP stack.

It requires a third party "mediation server" to bootstrap and maintain the connections between hosts on a Hamachi network. Currently named bibi.hamachi.cc, it constitutes a single point of failure. If it is not reachable, because of local firewall policy or server downtime, no tunnels can be established.

I2P is an open source effort to implement a slightly different approach not requiring such a third party.

The tunnel endpoints have addresses from the 5.0.0.0/8 IP range. The IANA did not authorise the use of this currently reserved network and when the block gets allocated, the resulting conflict will prevent peers from connecting to any legitimate IP addresses in that range as long as the tunnel stays up.

Hamachi uses a NAT-traversal technique, similar to UDP hole punching, detailed information how it works are kept secret. The vendor claims to achieve a higher rate of successful connections than other methods.

This process does not work on certain combinations of NAT devices, requiring the user to explicitly set up a port forward and Hamachi 1.0 Beta can relay traffic through a 'relay server' to enable a connection.

Hamachi is frequently used for gaming and remote administration. The vendor provides free basic service and extra features for a fee.

Security

The following points call for careful consideration:

• the absence of source code for review
• additional risk of disclosure of sensitive data which is stored or may be logged by the mediation server
• its current beta status and possible impact of remaining bugs on security
• the security risks due to vulnerable services on remote machines otherwise not accessible behind a NAT, common to all VPNs

Kerckhoffs' principle postulates that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Hamachi being closed source, Peer review to detect possible problems is not possible, see also the VPN article. The vendor provides a description of the security architecture[7].

For the product to work, a "mediation server", operated by the vendor, is required. This server stores the nickname, maintainance password, statically allocated 5.0.0.0/8 IP address and the associated authentication token of the user. For every established tunnel, it could log the real IP address of the user, time of establishment and duration as well as the other interconnected users. For now, it cannot be excluded, nor is there evidence suggesting it, that additional information could be encoded into the encrypted setup and keepalive packets to the mediation server.

As all peers sharing a tunnel have full "LAN-like" access to each others computers, security problems may arise if no appropriate action is taken. The security features of the NAT router/firewall are bypassed. This is not specific to Hamachi and needs to be addressed with other VPNs as well.

---

In the Security Now! podcast Steve Gibson described Hamachi as a: "...brand new, ready to emerge from its long development beta phase, ultra-secure, lightweight, high-performance, highly polished, multi-platform, peer-to-peer and FREE! personal virtual private networking system ..." and that he had "... fully vetted the system's security architecture ...".

In the following episode, to a question raised by Randal Schwartz: "Hamachi's not open source. How can we trust it?", Gibson replied: "... it's one of the things that made me anxious and continues to make me anxious. I'm going to end up probably over on OpenVPN ..." Later he continued: "But Hamachi is - I'm convinced that Alex has really designed this system exactly as he's told me he has. He's got years of experience with security, implementing IPSec tunnels, you know, classic VPN solutions. I couldn't feel any better about this than I do, short of doing a complete source audit ... which is just not practical. So it's certainly the case though that, well, I mean, you know, we're trusting Bill when we use Windows." and "... I'm sure Alex has told me the truth, but I have no proof of it."

See also

Virtual Private Networks

• Virtual Private Network Overview article
• OpenVPN Open Source VPN
• VTun Open Source VPN
• I2P Open Source effort to build an anonymous and/or pseudonymous VPN

Network address translation

• Network address translation (NAT) Overview, related RFCs: RFC 4008, RFC 3022, RFC 1631 (obsolete)
• Simple Traversal of UDP over NATs (STUN), a NAT traversal protocol defined in RFC 3489
• UDP hole punching another NAT traversal technique
• Traversal Using Relay NAT (TURN)

External links

• www.hamachi.cc - vendor site
• www.hamachi.cc/security - security architecture description document

Please comment here

I would be very grateful if you considered to kindly insert your comments in this section, rather than within the suggested new version of the article. Thank you. --Ministry of Truth 11:06, 17 June 2006 (UTC)

Thank you for taking the initiative and writing a first draft of the new article.

Thanks for reviewing it, I hope you don't mind I made your numbered, flowed text a list. --Ministry of Truth 14:47, 17 June 2006 (UTC)

I have several comments.

1. I feel it would be a "cleaner" article if the section on "How it Works" focused primarily on indeed how it works rather than scattering the readers attention with so many concerns. For instance, the "single point of failure" caveat is important, but could be moved to the security section and appended after the "logging issue".
2. The I2P paragraph really has nothing to do with how Hamachi works and probably should be deleted from this section and left in the "See Also" section.
3. The IANA paragraph also feels out of place but can probably stay there although it should be changed to "...reserved network and if the block gets allocated...".
4. In the next paragraph, "are kept secret" (is grammatically incorrect and) feels a little POV, perhaps "has not been made public" or "is not known".
5. I think parts of your Security section are going to cause problems with Alex. I ,of course, want your views on the security risks to be included, but as written, I think they may overemphasize certain risks that are only theoretical. There has not yet been a reported security-related bug, security oversight, or theft of data by a "Hamachi insider" (at least to my knowledge). And ultimately, the first four points apply to all proprietary VPN implementations and are therefore not Hamachi-specific. Perhaps as a start, the first sentence could reflect that and read something like: "As with all proprietary VPN implementations, several security considerations apply."
6. It is my understanding that Hamachi uses accepted, peer reviewed, cryptographic algorithms (AES, DH exchange etc). Perhaps a compromise could be made in which this paragraph may read "Although Hamachi uses strong, industry-standard algorithms to encrypt data (cite Hamachi security architecture website), the implementation remains closed source and therefore cannot be fully audited for potential security problems."
7. Since there is no evidence to suggest data is be surreptitiously sent to the Hamachi servers, it may be unfair to devote a whole sentence to this theoretical risk. Perhaps it could be deleted and the previous paragraph could have "backdoor" added so it might read: "the implementation remains closed source and therefore cannot be fully audited for potential security problems or backdoors." This also makes the section shorter.
8. Overall, the security section as written feels to heavy on the security caveats and scarce on the security benefits. I think we will need to reach a more balanced view before the article is acceptable to everyone. I will try to find some time to think of some ways to provide a better balance.

While some of the grammar needs to be cleaned up, and there are still a lot of editing decisions to be sorted out, I think it is a good start! --Thylark 14:15, 17 June 2006 (UTC)

---

1. ok, Alex wanted it there, I have no particular view on that one either way.
2. ok
3. ok
4. vendor considers it a trade secret, if you feel calling it what it is offensive, I can live with "has not been made public"
5. ok, "As with all proprietary VPN implementations, several security considerations apply." is fine by me
6. ok
7. ok
8. I'd welcome if you suggested some balanced language so we can get this version out the door without further ado.

Any help the article could get to be a fluid, error-free read is appreciated. However, I'd rather have some marginal clumsiness (that'll get cleaned up fast by those who read it) remain rather than to keep the version that's up as WP article now with all the unreadable cruft and numerous unsubstantiated claims... --Ministry of Truth 14:47, 17 June 2006 (UTC)

---

A couple of quick comments for now, I will post detailed response later today. I agree with Thylark's comments, perhaps with an exception for 'single point of failure' one, which needs to be further discussed.

1. HowTo section is the same version that I have already extensively commented on. None of the issues I pointed out were addressed in this version. Please review them here - Talk:Hamachi#RFC:_additions_to_.22How_Hamachi_works.22_section. In particular - I2P, IANA, 95%.
2. The same applies to the Security section, in particular - Kerchkof's, peer review, speculative wording and absolutely zero discussion about protocol audit. Please review my comments here - Talk:Hamachi#RFC:_new_Security_section.
3. There are no references to maillist discussions and I am still expecting the explanation as to how opinions expressed on highly relevant cryptography maillist are not relevant here.

Basically Security section in its current form is still factually inaccurate, biased and misleading. The fact that MoT selectively ignores highly relevant comments and continues to push his version of the article in fact constitutes the case of Wikipedia:POV_pushing. I am however willing to assume that MoT merely wants to organize the discussion better and that's reason for copy-pasting previously refuted version here. Alex Pankratov 17:53, 17 June 2006 (UTC)

---

1-3 --> See section #21, right above this one.

I am not ignoring anything and will obviously remove or correct any factually wrong statement that might have made it into my draft as soon as it is pointed out. --Ministry of Truth 21:37, 17 June 2006 (UTC)

---

You are ignoring the fact that the architecture and the implementation need to be discussed separately. I reiterated this point multiple times. You did not respond to my comments and you are now pushing forward with the version that is based on the false assumption. The assumption of Hamachi being completely closed system. This is a principal matter that I'd like us to clarify before moving on to other problems. To help move the discussion forward, I have summarized my clarification request into four questions. I am interested to hear what you say and see where we do start to fork apart -

1. Do you recognize the difference between the properties of the architecture of some system and properties of its implementation ?
2. Do you recognize that the system may have an open architecture, but a closed implementation ?
3. Do you recognize the difference between two closed-source systems, one with an open architecture and one with a proprietory one ?
4. Do you recognize that Hamachi is an open-arch / closed-implementation system ?

Please consider these questions in the context of Security discussion, the architecture being the design of Hamachi system security. I'd also like to hear Thylark's opinion on these questions (if they are meaningful and related to the discussion at hand). Thanks Alex Pankratov 01:28, 18 June 2006 (UTC)

---

I've integrated Thylarks observations into the draft and, not to unduly load this page, have published revision 2 on my Talk page .

Alex Pankratov, please try to understand what I said in the section immediately above this. I have no problem to entertain any of your talking points once we're done agreeing on what is already sufficiently consensual to replace the entirely broken article currently online. You're welcome to make further contributions to that effort, provided, as you so very gently put it yourself "... they are meaningful and related to the discussion at hand". --Ministry of Truth 03:33, 18 June 2006 (UTC)

---

Ministry of Truth, please try to understand what I said in the section immediately above this. You are currently engaged in POV pushing and I want to clarify whether this is caused by your lack of understanding of the subject matter, some principal disagreement on the subject or something else. Without clarifying this matter we cannot be sure your contributions are made in WP:Good_faith.

Alex Pankratov 06:24, 18 June 2006 (UTC)

---

I also want to hear your opinion about requesting formal or informal mediation help. I agree that this review appears to be turning into a lengthy process, and we still appear to be fairly far apart on very basic issues.

Alex Pankratov 06:28, 18 June 2006 (UTC)

---

Comments regarding How Hamachi Works section.

1. I would like to see the description of the system divorced from the discussion of its drawbacks and benefits. Current version mixes facts with in-place discussion ('Currently named .., .. consititues a single point of failure') and I argue that this affects the flow of the article.
2. I suggest rearranging the text so that the article first talks about overall architecture, client functionality, addressing, routing and grouping model, server purpose; then followed by the discussion of specific design elements including their drawbacks and benefits (see the comment on 'IANA' below). See Skype article for an example of this type of a layout.
3. I can provide the draft of this section if we agree that such rearrangement makes sense.
4. I2P bit is still there, I assumed it was to be removed
5. Under the above restructuring proposal the IANA bit will go under the drawbacks of using reserved public range for private networking. The wording needs to be corrected too as IANA is not responsible for 'authorizing' the use of reserved networks for private networking needs. Also in its current version the sentence lacks NPOV because it does not explore the actual reason for using 5.x/8 range.
6. 'The vendor claims ..' paragraph needs to include exact numbers that appear on vendor's webpage. The paragraph deals with vendor's opinion and these numbers comprise an integral part of this opinion.
7. 'This process ..' paragraph probably needs to be split into two sentences for better readability.

Alex Pankratov 07:21, 18 June 2006 (UTC)

---

There might be a misunderstanding due to my ambiguous reference to a "section above", earlier in these comments, sorry if that mislead you. I was referring to Talk:Hamachi#Let.27s_turn_the_page, perhaps that will help to solve the issues you seem to have. I think the draft is making great progress and should be ready for release anytime soon now. Let me address your last observations point by point:

1. Any suggestions to make the draft better, including alternate formulations are obviously most welcome to further the quality of the article. Nonetheless, any of such improvements not affecting factual truth or NPOV should not be a reason to further delay the publication.
2. See 1.
3. See 1.
4. Sorry, honest mistake of mine, fixed
5. Again, feel free to contribute your take on why it is necessary to use an unallocated class A network
6. Fair point, fixed
7. See 1.

I just published rev. 3 of the draft on my Talk page, incorporating the above changes. --Ministry of Truth 10:55, 18 June 2006 (UTC)

---

It's good to see continual discussion is on going.

As I said in my original comments, I think Alex is correct in his first point. The initial section will flow much better if concerns and benefits are left until the second section. We should try to confine the "How it works" section to indeed just that. Not why that is good or why that is bad. Therefore,

1. I think the "single point of failure" comment and the following sentence should be moved to the Security section. Let's just tell the reader what it does here and then say in the next section why this can be a problem. There is a natural place for it anyway in the paragraph describing the mediation server.
2. The IANA comment should be moved as well. Perhaps Alex can expand this section and explain why/how the alternate IP works. Then in the security section, we can explain why this could be a problem in the future.
3. Other than that, the first section is not bad. I think it could use more detail in the mechanics of how the application works . I think Alex's suggestion to write a draft for the technical aspects as he proposed may be a good one. Presumably, they should be pretty neutral as they are just technical descriptions of the application he knows well and should have little point of view. Regardless, we can look at both versions and decide which elements should be included. As long as it is not overly tedious, and from a NPOV, I see no reason why providing the reader with more information is ever a bad thing.

--Thylark 20:05, 18 June 2006 (UTC)

---

Ministry of Truth, while I acknowledge certain degree of the progress on How It Works section, I completely disagree that the draft as whole can be released 'any time soon'. The Security section needs a major overhaul as discussed in preceeding threads. I am holding my comments back on Security section, because as the history of this discussion shows, we need to approach the review in small steps not to end up with important issues and comments getting overlooked and unaddressed. Therefore I vigorously oppose release of existing version prior to completing the review of all sections.

Regarding comments 1-3 -

1. Existing structure of How It Works section does not contribute to NPOV. The reason is that its current structure is based on "<basic fact><criticism>" pattern. This presents exactly one POV (critical one) and needs to be balanced out by POV demonstrating the benefits of particular system property. This is an explicit NPOV guideline, so it must be done. However once POV is balanced out, the section text will grow in size and the information will be hard to follow.
2. Instead of having <fact><discussion><fact><discussion> struture, I proposed to switch to <fact><fact><discussion><discussion>. Thylark appears to agree with me that this approach is cleaner; and it also scales better if/when the article grows with more content. This will also allow us to hammer out factual part first and then independently work on POV <discussion> parts.
3. Since exact wording heavily depends on the section structure, the issue of the structure needs to be dealt with first.

Having said all this, I can probably live with existing structure for now. However the comments required for leveling out POV will be substantial, so as I said the readability of the text is likely to take a hit.

Since Thylark and myself share the view on the restructuring, I'd like us to quickly go over this matter and explicitely decide on how to proceed. I have a number of changes that are required for fixing up POV, I will post them as soon as we sort the structure thing out.

Alex Pankratov 02:52, 19 June 2006 (UTC)

---

You seem to have missed my question about the possibility of mediation -

I also want to hear your opinion about requesting formal or informal mediation help. I agree that this review appears to be turning into a lengthy process, and we still appear to be fairly far apart on very basic issues.

Alex Pankratov 06:28, 18 June 2006 (UTC)

I'd like to know your opinion, because I can easily imagine the need for mediation when we come to discussing Security section. Thank you.

Alex Pankratov 02:56, 19 June 2006 (UTC)

---

If you feel that the perspective representing the interests of the vendor is getting anything less than a fair shake here, who am I to stop you from requesting mediation if you deem that to be necessary ? I think we are doing fine for now and thank you for acknowledging progress in the elaboration of the draft.

Requests_for_mediation#Parties.27_agreement_to_mediate states that for the mediation process to work all involved parties need to agree to participate in it. That is what I am asking your opinion about, not if you mind me requesting the mediation. If it comes down to requesting the mediation, would you be willing to participate in this process ? Thanks.

Alex Pankratov 06:22, 19 June 2006 (UTC)

Thylark has raised interesting points in his last comment; I can't find any of them to meet the criteria of either correcting factually false statements or referring to absence of NPOV, but will wait for him to specifically comment.

Please note again that the draft version is not supposed to end the discussion. Let me refer you to Talk:Hamachi#Let.27s_turn_the_page once more. Note that not only did I include several points I am having issues with, but also have swiftly corrected the proposed version when specific observations have been made.

If you feel there are still issues in need of being fixed, for either factual correctness or NPOV, please, in the spirit of "sofixit", do propose alternate language for anything you can't live with in the draft.

To underline the urgent need of the current article to be updated, as on top of being biased and partially unreadable, it continues to contain at least one factually untrue statement, I am upgrading the status from POV to TotallyDisputed. --Ministry of Truth 04:36, 19 June 2006 (UTC)

Can please point this statement out ?

Alex Pankratov 06:05, 19 June 2006 (UTC)

---

You misunderstood me. We now have two options - (a) to continue discussing current draft or (b) restructure the section as per Thylark's and my comments and then discuss its material. I am saying that if we are to push forward with (a) we will end up with barely readable version and will need to restructure it anyhow. Therefore taking care of (b) first will allow us to save on the discussion time and editorial effort.

I am interested in hearing Thylark's opinion before proceeding.

Alex Pankratov 06:05, 19 June 2006 (UTC)

---

We also have not only the possibility, but the obligation to respect WP policy. Should you have any argument to make to contradict Talk:Hamachi#Let.27s_turn_the_page, do so. Or propose language to improve the draft. In its current state, the article as it is online now is an unfixable mess and the efforts to improve it have shown to be too lengthy to be a viable option. --Ministry of Truth 06:17, 19 June 2006 (UTC)

---

I will try to prepare complete list of my comments, corrections and 'alternative language' within next day.

Alex Pankratov 06:40, 19 June 2006 (UTC)

---

I welcome and look forward to such constructive contribution.

Would you please also, at your convenience, either correct the contradiction between the two percentages for the successful NAT traversal (95% vs. 97%) in the article or put back the appropriate warning ? If you prefer the "contradicting itself" flag instead, I'd be fine with that too. --Ministry of Truth 07:03, 19 June 2006 (UTC)

---

When more than eight hours after your revert of status, some linkspam needed to be pulled anyway, I took the liberty to replace the inconsistent statements with a consensual one and subsequently downgraded the status to POV again. --Ministry of Truth 15:15, 19 June 2006 (UTC)

I agree with your change. Thanks.

Alex Pankratov 04:51, 20 June 2006 (UTC)

---

It just occured to me that we can combine Security Discussion (the open/close source, extra headache with LAN-like setup, etc) with 'single point of failure' point under the 'Comparison' section (perhaps it can use a better name). Basically go over the main differences between Hamachi and other notable VPN solutions and this should allow us to cover all issues that were ever listed. The 'Security' section will then just be collapsed to a couple of sentences summarizing declared security properties and referencing the spec. And then forwarding the reader to the 'Comparison' section for detailed discussion.

Would something like this work ?

Alex Pankratov 06:12, 20 June 2006 (UTC)

---

== How It Really Works ==

I started commenting on existing version (by MoT, draft 3), and then I realized that most of the information I was going to put in was never assembled together in one place before. Bits and pieces floated around various forums and maillists, so it is technically possible to piece the whole picture together. It is however unrealistic to expect this from an outsider.

Anyhow, here is far more fleshy version of How It Works, which goes over main design features and offers some insight into why exactly certain things were done this way or that. I think it is a good starting point and it is always simpler to take something apart and trim the fat than to add new content non-intrusively.

This is based on a slightly reworked version of our OEM paper, so it is a mix of facts and discussions. I went over the text and I don't see any apparent bias, but the text is obviously open to the comments and corrections. The language clearly needs a polish too.

How It Works

Hamachi is a centrally-managed VPN system. It is comprised of the server cluster managed by the vendor of the system and the client software, which installed on end-user computers.

Client software adds a virtual network interface to a computer, and it is used for intercepting outbound as well as injecting inbound VPN traffic. Outbound traffic sent by the OS to this interface is delivered to the client software, which encrypts and authenticates it and then sends it to the destination VPN peer over a specially initiated UDP connection. Hamachi currently handles tunneling of IP traffic including broadcasts and multicasts. Windows version also recognizes and tunnels IPX traffic.

Each client establishes and maintains a control connection to the server cluster. When the connection is established, the client goes through a login sequence, followed by the discovery process and state synchronization. Login step authenticates the client to the server and vice versa. The discovery is used to determine the type of client's Internet connection, specifically to detect the presence of NAT and firewall devices on its route to the Internet. Synchronization step brings client's view of its private networks in sync with other members of these networks.

When a member of a network goes online or offline, the server instructs other network peers to either establish or tear down tunnels to the former. When establishing tunnels between the peers, Hamachi uses server-assisted NAT-traversal technique, similar to UDP hole punching. Detailed information how it works has not been made public. The vendor claims "...to successfully mediate p2p connections in roughly 95% of all cases ..." [3]. This process does not work on certain combinations of NAT devices, requiring the user to explicitly set up a port forward. Additionally 1.0 series of client software are capable of relaying traffic through vendor-maintained 'relay servers'.

In the event of unexpectedly loosing a connection to the server, the client retains all its tunnels and starts actively checking their status. When the server unexpectedly looses client's connection, it informs client's peers about the fact and expects them to also start liveliness checks. This enables Hamachi tunnels to withstand transient network problems on the route between the client and the server as well as short periods of complete server unavailability.

Each Hamachi client is assigned IP address from 5.0.0.0/8 subnet. This address is assigned once, when the client logs into the system for the first time, and it gets statically associated with client's public crypto key. As long as the client retains its key, it can log into the system and use respective 5.x.x.x IP address.

5.0.0.0/8 subnet is used to avoid collisions with other IP addresses that might already be in use on the client side. Specifically - 10.x.x.x/8, 172.16.x.x/12 and 192.168.x.x/16. The 5.0.0.0/8 is currently reserved by IANA and not used in an Internet routing domain. If/when this range gets allocated, it will effectively prevent peers from connecting to any Internet IP addresses in that range for as long as Hamachi client is running.

Using Class A subnet has an additional benefit of creating single broadcast domain between all clients. This makes it possible to use LAN protocols that rely on IP broadcasts for discovery and announcement services over Hamachi networks.

<need to add common uses>

<I will post a separate comment regarding 'single point of failure' in a moment>

Alex Pankratov 06:06, 20 June 2006 (UTC)

---

Thank you, Alex, now we've got something going !

There's definitely a lot more substance in your suggested version. Probably the now very short introduction could benefit from including a condensed version of what is the actual how it works section of the draft, to give an overview, before we dive into the gory details. Definitely needs some streamlining, but quite fixable.

I do nevertheless have a couple of issues with your proposed section, but nothing that would make me veto it for inclusion. Unless you want to address other parts of the draft as well, I'd be fine with including it more or less as is with perhaps some slight nudging here and there (nothing you'd be upset about, I promise ;-) while wikifying it and put the resulting article online.

Just so you can look into those points, here's what I think might need fixing:

1. improve flow and readability, it should really be more plainspoken, that is possible without losing accuracy, condense a bit
2. wikify
3. single point of failure needs to be slightly more transparent. How many machines are part of the cluster right now ? Does a single client connect to more than one server to initate and keep up tunnels ?
4. how long is a "short period of complete server unavailability" right now ?
5. We should probably also refer to RFC 1918 or better yet the newer one that obsoletes it (can't remember the number right now).
6. residual POV issues on the 5/8 part

I'm afraid that an overly detailed explanation of common uses does probably not have its place here. Anything going much beyond what's already mentioned would look like a sales pitch rather than encyclopedically warranted content, you might want to bear that in mind before you start working on it.

I still don't have a strong opinion on where we put the single point of failure thing, but can hardly see how we can get around a section titled security. If you can elaborate on a consistent plan of sections with respective content and defined headers, why not, but for now I'd keep it as is, then sort things step by step unless you find something particularly offensive in the draft security section as is.

I'd appreciate if you let me know what other parts are to follow and when so I can do the work on the final draft in one fell swoop. --Ministry of Truth 07:48, 20 June 2006 (UTC)

---

Ok, since this appears to be a productive way of moving things forward, I would probably prefer to produce a draft of the rest of the article as well. It may take me a couple of days because I severely lack time at the moment. My comments to your points are as follows:

1. Agreed, I think the flow is OK, but I know I'm no Zelazny. I really hoped for someone else's help in this department.
2. Agreed
3. Agreed

Q1 - Under a dozen at the moment, though I think this information does not need to be in the article. It is a backend deployment property, which is completely transparent to the client. Clustering is a typical feature of any scalable client-server system. Stating that there is a cluster should be enough to propagate relevant information.

Q2 - No, each client talks to exactly one server in the cluster.

1. Few minutes (under 5), this refers to the event of restarting the cluster during intrusive upgrades. Does not happen often, last upgrade of this kind was over a month ago.
2. Fine with me, though it might bloat the text
3. Can you elaborate ? Just keep in mind that IANA governs Internet IP space. Hamachi is an Overlay network, it has private routing space that is isolated from the Internet one. Similarly to how I can deploy PBX at home and assign 1-800 number to the bathroom. It will all work, but may cause routing ambiguities.

Agreed regarding the common uses.

I think that at the very least Security section needs to be split in two - facts and opinions/discussion. Former is a short summary of security architecture (because security properties, even if they are only declared, are still an important part of system description). Discussion section can go over open/close source, protocol audit, Mr. Gibson's opinion, etc .. basically provide readers with relevant points for making their own conclusions. This also appears to be a good place for elaborating on a single point of failure point, though it can be given its own section.

Would this sort of a structure work ? If it would, I will try to produce an outline for these two sections in the next few days and we can go from there.

Alex Pankratov 05:34, 21 June 2006 (UTC)

---

I'd like to apologize if you took my remarks about readability as a personal attack, it really wasn't meant to be. We agree that this is a productive way to move forward and pure form problems are likely to be fixed by uncontroversial drive-by edits such as this one [8] as soon as the draft goes live.

I completely understand that you have more to do than to write the WP entry of your product. As you didn't raise any particular concerns about the contents of the security section as it is right now, I'll start to edit your proposed new how it works section into the draft, then make it the new WP entry on Hamachi.

From then on, we can discuss based on the actual article and you can participate at your convenience. If several passages need to be reworked together in order to keep the article consistent, we can work with intermediate versions on my talk page again to fix it. I'm open to discuss any shuffling around of content that serves the purpose of ending up with a better article, so if you can make a convincing case, go for it. We probably don't want to go through stuff like the setup procedure of a tunnel twice, both in how it works, then once more in security, but again, I have no strong feelings on where to put it either way. The new article is a considerable step forward towards NPOV, but as long as the discussion here goes on and until a complete consensus can be reached, I think we should leave in the POV tag, but I'm open to other suggestions as long as the reader is still made aware of the ongoing discussion and disputed passages. --Ministry of Truth 08:53, 21 June 2006 (UTC)

I finally opted for a plain copy and paste of your "how it works" section as an effort to contribute to the trust we've started to build during the process of constructing an acceptably NPOV article on Hamachi. As far as the cluster thing is concerned, I think if we can afford 569 words to explain how it works, a few more about how many servers there are in the cluster, perhaps also to serve up to how many simultaneaous users, would probably not kill us and like Thylark said, more facts are always a good thing. Referring to the clients as interacting with the cluster is factually wrong, they get assigned one machine and stay with it as you said yourself. Try to volunteer facts, I really don't like to sound like am I interrogating a hostile witness.

There's definitely a diverging view on the IP space question. You say you needed to hijack a big net to allow for growth, broadcasts etc. while avoiding any potential conflict with RFC 1918 addresses already used by the client. While I perfectly understand the reasons, I believe that it needs likewise to be pointed out that this is a decision conflicting with IANA regulation and that it will break net integrity as soon as 5/8 gets allocated. Your version is POV, too verbose and weaseling out of the issues that need to be addressed. I'd be tempted to go back to one of the more to the point versions previously discussed and would like to hear your comment.

Feel free to wikify, polish style and compact "How it works" in the current article as you see fit as long as you don't do anything that would need to be discussed here first. --Ministry of Truth 04:03, 22 June 2006 (UTC)

---

Regarding the cluster bit - the main issue with putting exact numbers here is that they are of a highly sensitive nature and therefore I am simply not in the position to disclose them.

The general functioning principles of the backend are the same as that of any clustered system - there is a primary connection point (which is identified by DNS name 'bibi.hamachi.cc' and it may be mapped to one or more actual IP addresses via DNS load-balancing), and there is a mechanism for redirecting the client from one server to another, which is utilized by the members of the cluster to even out the load.

Alex Pankratov 05:21, 22 June 2006 (UTC)

---

Regarding the IP space question - I don't know if I completely understand what you mean by 'breaking net integrity' and 'the issues that need to be addressed'. IANA has no business controlling addressing used in private networks, so the wording you had in draft was at the very least inaccurate. But I agree that the section may need to be appended with some sort of layman's warning. Can you explain which part of my version is POV'd ?

Alex Pankratov 05:29, 22 June 2006 (UTC)

---

Here's what I believe to be a version that includes aspects you wanted to see added, while being factual and neutral about it:

"The IANA has reserved several network ranges to be used in Private networks (RFC 1918). The Hamachi designers, while looking for a large IP space to allow for a single broadcast domain, chose not to follow this RFC because it would have required part of the clients to change their IP address in order to avoid conflicts.

Instead, every client is permanently assigned an IP address from the 5.0.0.0/8 netrange when he first logs in as part of the account creation process. The IANA has reserved this class A network for future use, when it gets allocated, peers won't be able to connect to any legitimate IP addresses in that range as long as the tunnel stays up."

Again, feel free to suggest changes if you feel it's still POV.

For the different technical details (single point of failure, timeout, cluster setup as of today...) you are reluctant to communicate, the only way I can see how to deal with it would be to re-phrase that part of the article using all information that is visible from the outside and to state what informations were withheld by the vendor when asked. Before doing so, I'd welcome your comment.

As far as the security section is concerned, before getting into redacting paragraphs, I'd like to be sure that the idea of moving around contents and changing section titles has been dropped to avoid potential duplication of effort. --Ministry of Truth 07:35, 23 June 2006 (UTC)

---

This is very reasonable version. There are three things that I'd like to tweak -

1. The primary reason behind using non-RFC range is to avoid collisions with existing RFC addresses, and not to create large broadcasting domain (10.x.x.x range is also a Class A subnet). I'd like to reprase the first paragraph to better propagate this point -

The IANA has reserved several network ranges to be used in Private networks (RFC 1918). These ranges are now widely used in home and corporate networking, and in order to provide unambigious addressing space Hamachi developers opted for using different (non-RFC) range.

Instead, every client is ...

1. 'legitimate IP addresses' -> 'public Internet IP addresses'. This is factually accurate.
2. 'as long as the tunnel stays up' -> 'as long as Hamachi client is running'. Routing ambiguities are created by the presence of virtual adapter, and not an individual tunnel.

Regarding "For the different technical details (single point of failure, timeout, cluster setup as of today...) you are reluctant to communicate" -

1. I am not reluctant to communicate about this; I honestly have no idea where you got this impression from.
2. Single point of failure is a property of the system design and it needs to be discussed. I am completely on the same page with you regarding this. Please suggest the wording.
3. I am not sure what you mean by the 'timeout'
4. I gave my reasons for not going into much detail concerning backend structure. Have a look at Skype, ICQ and Windows_Live_Messenger articles, which are similarly structured systems. They do not include a discussion on exact backend structure either.
5. Stating that the information is withheld by the vendor is a biased POV. More neutural wording would be 'was not made public' if you are up to including it. I think this surfaced before in other context and you were OK with latter version.

Regarding Security section - consider that restructuring idea dropped. We can always get to it later if there's some spare time and energy.

Alex Pankratov 21:30, 23 June 2006 (UTC)

Security Section

Here is a copy-paste of current version of Security Section. My comments are in small font, inlined -

---

As with all proprietary VPN implementations, several security considerations apply:

"proprietary" -> "closed source". The issue here (as I understand it) is the lack of source code rather then the custom nature of VPN system in general

• the absence of source code for review
• additional risk of disclosure of sensitive data which is stored or may be logged by the mediation server
• its current beta status and possible impact of remaining bugs on security
• the security risks due to vulnerable services on remote machines otherwise not accessible behind a NAT, common to all VPNs

Kerckhoffs' principle postulates that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

I feel very strongly that this needs to be removed. This principle deals with the need for separating security and secrecy, and it largely applies to the design of the security systems. It also requires certain degree of cryptaphy skills to interpret and place it correctly. All in all, it is basically not appropriate for the context. It is pretty much like referencing Maxwell Equations when describing a problem with a lawnmover.

Although Hamachi uses strong, industry-standard algorithms to encrypt data[9], the implementation remains closed source and therefore cannot be fully audited for potential security problems or backdoors.

Current phrasing does not pay due attention to the fact of security spec being open. This needs to be put in a separate section instead of being some obscure fact that is immediately counter-argued. I would like to have it rephrased as follows -

Detailed description of Hamachi security architecture is available here. According to the vendor this information is sufficient to access raw session data with a purpose of verifying security properties of the communication and auditing its content. Hamachi can also be configured to log all cryptographic data including encryption keys to a disk file for the same purpose.

Hamachi implementation remains closed source and therefore cannot be fully audited for potential security problems and backdoors.

I expect that second part will need to be extended to balance POV of the first part. What I do strongly insist on is the inclusion of the first part. Without it the section has exactly one POV and therefore it is pretty biased.

For the product to work, a "mediation server", operated by the vendor, is required. This server stores the nickname, maintainance password, statically allocated 5.0.0.0/8 IP address and the associated authentication token of the user. For every established tunnel, it could log the real IP address of the user, time of establishment and duration as well as the other interconnected users.

As all peers sharing a tunnel have full "LAN-like" access to each others computers, security problems may arise if no appropriate action is taken. The security features of the NAT router/firewall are bypassed. This is not specific to Hamachi and needs to be addressed with other VPNs as well.

---

In the Security Now! podcast Steve Gibson described Hamachi as a: "...brand new, ready to emerge from its long development beta phase, ultra-secure, lightweight, high-performance, highly polished, multi-platform, peer-to-peer and FREE! personal virtual private networking system ..." and that he had "... fully vetted the system's security architecture ...".

Technically speaking the quote is not from the podcast, but from its description.

In the following episode, to a question raised by Randal Schwartz: "Hamachi's not open source. How can we trust it?", Gibson replied: "... it's one of the things that made me anxious and continues to make me anxious. I'm going to end up probably over on OpenVPN ..." Later he continued: "But Hamachi is - I'm convinced that Alex has really designed this system exactly as he's told me he has. He's got years of experience with security, implementing IPSec tunnels, you know, classic VPN solutions. I couldn't feel any better about this than I do, short of doing a complete source audit ... which is just not practical. So it's certainly the case though that, well, I mean, you know, we're trusting Bill when we use Windows." and "... I'm sure Alex has told me the truth, but I have no proof of it."

---

Alex Pankratov 05:57, 22 June 2006 (UTC)

---

Just curious if this security issue has been addressed since Hamachi was bought by LogMeIn. From the site:

"However what is equally important - Hamachi security architecture is completely open meaning that its detailed description is available to anyone interested for review and validation. More..."

I don't know if open architecture solves any problems, but I'm not security expert either, which is why I raise the question here.

J Wood 21 October 2006

Links Clean-up

I am removing links to OpenVPN, VTun and I2P. Unless Hamachi is cross-linked from their pages, they have no reason to be linked from here. [unsigned]

Security Section Clean-up

Few changes to Security section - split the list of concerns in two parts grouped by the reason and removed the reference to Kerchkoff principle acting upon http://en.wikipedia.org/wiki/Talk:Hamachi#Security_Section comments. Further cleanup is needed, the section is biased both ways and remains speculative. 195.56.169.120 11:03, 6 August 2006 (UTC)

This article reads like an advertisement

I'm too bleary to read through the discussion page carefully, but I agree with the comments about the article reading like an advertisement. Some of the inbound links also appear inappropriate and probably deserve cleanup. I'd even consider an AfD, but I'll leave that to people more knowledgeable about this particular program. Phr (talk) 02:53, 12 August 2006 (UTC)

I see no reason why there should not be an article on a widely used networking application and therefore do not support an AfD. However, it is clear much work needs to be done to polish this article. As you can see, there was much disagreement between editors on the content of this page over the last months and concessions were made on both sides in the interest of dispute resolution that don't necessarily make for the best reading. If you have any constructive suggestions, please help us streamline this article. Thylark 08:25, 12 August 2006 (UTC)

I am not persuaded that this is a widely used application. The article does not make the case for that claim. Phr (talk) 09:41, 12 August 2006 (UTC)

If you go to www.hamachi.cc you will see that the developer claims over 3 million users (Yellow box at top of the page). I would say that is a significant user base. Further, the application has been widely discussed in the technology media (try a google search). The number of users can be added to the article if you feel it appropriate. Thylark 15:52, 12 August 2006 (UTC)

The 3 mil number (which is about 3.9 now actually) is easy to verify. When the application is run for the first time, the server assigns it 5.x.x.x address. Addresses are assigned sequentially and the first ever assigned IP was 5.0.0.2. As of the time of this posting, we are at 5.60.152.xx, which translates into ~3971072 accounts.

Alex Pankratov 20:40, 13 August 2006 (UTC)

Please do read through the discussion, especially the part that involves Ministry of Truth edits and comments before submitting AfD request. As Thylark noted we spent considerable amount of time cleaning the article up and putting together its existing version.

WRT determining if this is notable application or not, and in addition to google.com, I'd suggest looking at the usual batch of del.icio.us, stumbleupon.com, technorati.com, alexa.com and digg.com.

Alex Pankratov 20:40, 13 August 2006 (UTC)

As a user who came to this page looking for an unbiased description of Hamachi, and the pros and cons of using it, I must admit, after reading it that I do not feel that this article came close to that. It definitely has a pro-Hamachi bias, and does even come close to fully encompassing the pros and cons of using Hamachi, nor does it adequately enumerate the security concerns of a close-sourced P2P and encryption product. As a direct contrast the page for Skype, which is also a closed-source P2P application, is very easy to read and fully encompasses the features and concerns of Skype. Perhaps the authors of this article could use the Skype page as a reference. To risk a complete flame war...I am a fan of Alex's, it is clear to me that he is a very bright guy who has a lot to offer to the security industry, but based on his behaviour in this talk article, I can't help but believe that the article would be far less biased and far more useful if he had stepped back after writing the stub article, provided technical input only as requested, and let others edit the article to a neutral tone. Unfortunately, it appears he chose to micro-managed the editing process and seriously hampered the ability to create a useful and unbiased article. I am sure that it will now be my turn to have my opinion challenged...but hey...I just call 'em as I see 'em. HerbieW 20:50, 7 September 2006 (UTC)

Dude, make any changes that you would think add clairity. I'd like to think I have been a relatively neutral party during these discussion, and I can tell you that although I don't give blanket support to all of Alex's suggestions, some of the changes proposed by MoT were unduly critical and irrelevant to the discussion of Hamachi specifically (at least in my opinion). This let to a significant polarization of the discussion and resulted in the choppy and unpolished version that exists now. I think Alex has done the right thing by leaving it as it is, but so far no other editor has taken up the challenge to rewrite the article and iron out the problems. Perhaps when I can find some time I'll give it a try, but please, I think I speak for everyone when I say we would appreciate it if you could find some time to make some constructive changes to the article to reach an informative NPOV. --Thylark 08:33, 8 September 2006 (UTC)

I'm also a user who's looking for information to set up a VPN and by now I've read a good deal about several VPN systems. I've read through the entire article and then looked to the talk page because I was curious what could be the reason for the neutrality dispute. After reading through the entire talk page I must say I've come to the conclusion that while it doesn't read like a good book (or WP article for that matter) just yet, all the points that have come up in this talk page were clear to me after reading the article! So while I may agree that it still needs work, I can assure you that your points have come across, for both sides of the debate.

On August 8, 2006, it was announced that Hamachi was being purchased by LogMeIn[1].

sounds like it hasn't been purchased, yet on the hamachi site it seems the sale was completed? Perhaps rephrase this. I'm also wondering if this fact is so interesting it has to be included in the introduction. As for the Gibson quote, it's rather long compared to the article. I would summarize the contents and let readers check out the full context in the transcripts. Perhaps I've managed to overlook them, but a link to BOTH the actual podcast audio (MP3 file) and the transcripts would be nice.--Rygir 23:56, 26 September 2006 (UTC)

Revision as of 11:37, 26 November 2005 by 67.182.217.139

Revision as of 11:37, 26 November 2005 by 67.182.217.139

I wrote the bulk of the article as it stood on the 26th of November 2005, I had not yet created a Wikipedia account at that time. I am curious to know if that version of the article would be considered NPOV or not. --DataSurfer 06:45, 29 September 2006 (UTC)

a doubt

http://www.hamachi.cc/security/ --> "Hamachi security architecture is completely open meaning that its detailed description is available to anyone interested for review and validation." Is this claim true? It seems to contradict the wikipedia article. I ask because I don't understand a word of this.

This is THE most important page on an entire webstire. It was the first thing that went up on the website back in December 2004. It is complete and accurate description of Hamachi security architecture. It is intended for security professionals versed in applied cryptography in general and networking security in particular. A simpler version of the same information was given by Steve Gibson in Security Now! episode (#18 IIRC). The episode is linked from WP article.

Alex Pankratov 23:25, 26 October 2006 (UTC)

I see. It was just that I didn't read closely: "cannot be fully audited by absolutely anyone who feels like it for potential security problems or backdoors" gave me the impression of the protocols being completely hidden. Perhaps it should be made more clear that at least part (an important part, if I understand correctly?) of the protocols are published in the site and can be examined? Or something to that effect. It's a "newbie-friendlyness" suggestion. --Guruclef 08:43, 31 October 2006 (UTC)

Well, it's my potentially snarky rewording of the rather paranoid-sounding sentence we had there before. Most of the article used to be garbage intimating that Hamachi, as closed-source software (like, you know, most of the stuff in the real world) was not just potentially but likely riddled with security holes, backdoors, etc. Still needs fixing up. Nimmo 09:32, 31 October 2006 (UTC)

Security 2

Have a look at this : http://www.cipher.org.uk/index.php?p=news/Hamachi_considerations.news especially the second point, there is no blocking mechanism in place! so if i want to bruteforce your vpn's password I can without any delays or restrictions.

Regarding your first point - it is trivial to determine if the network exists by trying to create it, so there's no point in concealing the fact that it exists when the user is trying to join it. WRT your other points - these are valid points that were recently addressed in a server-side update. There is a response throttling mechanism that makes guess-based network enumeration impractical. And brute-forcing the network password leads to a ban from the system. Alex Pankratov 06:21, 5 November 2006 (UTC)

The fist point is referring to the fact that there is no option to create invisible networks, for added security. You can update the author regarding the second issue.

All networks share the same namespace, so it is trivial to uncover 'invisible network' by simply trying to create it. Even if the join command does not elaborate on why join failed. Not differentiating between (some sort of) public_id and password failures improves the security of the system only if the system does not allow its users to create authenticatable objects. Which is not a case with Hamachi. Alex Pankratov 18:37, 5 November 2006 (UTC)

I'm Talking 'bout Down Syndrome

In plain English, it establishes a connection over the Internet, to create conditions very similar to that as if the computers were physically connected. -- whoever wrote that, genius, thank you. Maikel 00:17, 4 June 2007 (UTC)

Logmein

Logmein swallowed Hamachi months ago and there's still no Logmein (<--red) article. Let's get crackin pipple! JDG 14:32, 16 September 2007 (UTC)

Actually, there was a LogMeIn page until recently but an overzealous (IMO) admin deleted the article as spam. User DanielRigal is editing the article which is at User:DanielRigal/LogMeIn to make it more acceptable for the admin, but work has apparently stalled. I move that it be restored to the proper article space so that the community can work on improving the article which subject clearly meets WP:N. Unfortunately, the admin has blocked the LogMeIn space so I am unable to be bold and do this myself. Ccscott 14:52, 16 September 2007 (UTC)

A completely new LogMeIn article has been written and access has been restored. Please keep it non-POV or it will probably be deleted again. See th Talk:LogMeIn talk page for comments and concerns. --KJRehberg (talk) 14:40, 23 April 2008 (UTC)

Running your own Hamachi Server?

This would be nice and solve a lot of questions people are having. So can it be done? With Hamachi its very unlikely, because its not open source, and its for profit. But are there any other P2P style VPN solutions that you can run your own server? (EG, i would run the server side on 2 or 3 of my public servers. then make a custom client install that would query those servers and let my 100's of clients connect to each other as needed). Idea's? —Preceding unsigned comment added by 218.185.65.52 (talk) 02:41, 23 July 2008 (UTC)

You can do this. An old version of the page had a reference to a piece of software called Mojako which is is an open source version of the Hamachi mediation server. I don't know why someone removed it... it's completely relevant. 132.177.66.230 (talk)

Origin of the name

Who came up with the name? Is it an acronym? Or did the author just like sushi? --69.111.59.161 (talk) 23:45, 13 September 2008 (UTC)