AutoHotkey Community

Hi all,
I've not been posting for waaaay too long, and will, I fear, keep on doing the just-reading-not-posting-thing for a while longer (as I am much too busy).

But anyway, I came across something I just had to share: Hamachi, to create your own free secure virtual network over the internet.



And you'll find it all here: http://www.hamachi.cc/

I have not use dit myself yet, but 165.000 users can't be all wrong...

Ehm, 265.00 users that is ...

Well, it is all about trust. The Internet suffix .cc is for Cocos (Keeling) Islands. (They are located in the middle of the Indian Ocean some 2750km north-west of Perth, and 900km west south-west of Christmas Island, their closest neighbor). The company behind Hamachi is located in Vancouver, Canada, but using the suffix .cc instead of .ca makes me wonder if they are really trustworthy. When you use a mediator for establishing connection, you have to trust it. Even if their SW does not do bad things in your PC, they could connect whoever they want to your private network. If they play fair today, what if someday somebody there becomes curious or wants to make an extra buck?

And even a million users can be wrong.

Isn't it always about trust?

The virus scanner I run might be abused by not letting some viruses pass.
The router-with-firewall under my desk might be built to spy on me.
The spyware control tool I run might contain backdoors.
The OS (one of Bill G.'s) on my system might send stuff about me to the US government.
My provider might scan all my mail on dubious content.

Yet I use all that stuff daily...

If caution is not used with a bit of research some/all of those are certainly possible. Many people just shrugging and saying oh well when using software that seems a bit suspicious without doing a bit of research first (I'm not saying that you are. the last post just came off sounding a bit like that) is probably the biggest reason why much of the spyware and scams continue to exist...

It does sound interesting... Thanks for the link .

When MS was caught sending personal info with SW registration or storing unnecessary private data in Word headers, they were forced to retreat, issued patches, private data removal tools. Big companies cannot afford any more to spy on you. If they do, you can sue them. A class action lawsuit is very expensive, and many people are well trained now to spot any dubious activity. But small companies in the Cocos Islands cannot be held liable for any damage they might cause.

Yes, you trust different companies with your secrets. But if you really have something to hide, you can be more cautious than using a mediator from the Cocos Islands. For example, you work on a PC, which is not connected to any network. When you want to send an email, you encrypt the text in this PC and burn it on a CD. From a connected PC you send the encrypted text. If you receive an encrypted email, you burn it on another CD as text and read it with your own text extractor SW on the secure PC, decrypt it there and read. It is slow, but you can judge if the inconvenience is worth the extra security.

It is the best if you don't have anything valuable to be stolen (living in a cloister). Not even a name or address, because those are of value for identity thefts. Otherwise, try not to install SW of a company without good reputation or name. And under no circumstances use a mediator from the Cocos Islands to establish secure connection. A VPN or SSL server can do the work, but you only trust them with secrets they could get from you anyway. Microsoft's VPN server is trustworthy, because they could steal your secrets without it. And if they did, it would cost them billions of dollars.

Hi Laszlo,

I want to thank you for your cautionary comments. I've thought some more on this over the weekend, and looked for some more comments on Hamachi on the web, and I found more critical comments.

It is, like you say, a matter of trust. They say the program is secure, and nobody will be able to see the communications between to peers. They say their program does not contain spyware (well, actually they say "Hamachi software contains no spyware, bannerware or any other -ware unrelated to its purpose. And it never will." - so if one is somewhat paranoid, one might ask what the purpose of the program is!??).

Maybe it is a good thing to be somewhat paranoid when connecting to the internet (I am not saying you are), and when using free software (might be worth every cent I've paid for it). I do run frequent anti-spyware tools, I do keep my virus scanner up to date, I do take care on configuring my router-with-firewall, I am reasonably careful with the sites I visit, but on the other side I also put lots of freeware on my computer, for a great part because I don't want to pay for it; I do tend to get it only from sites I trust.
The news on Hamachi came from a site I trust (a Dutch internet provider), so I thought I'd share.

And probably there is nothing fishy going on (except for Hamachi being a yellow-fin tuna, that is ). But it is, as you say, a matter of trust. And it bay be I am a little too trusty...

_________________
The Gods smile upon you. Beware - it is probably because they know what is going to happen to you next, and find it amusing. To them, anyway. --- Discworld Horrorscope: http://www.weirdnes.force9.co.uk/stars3.html

Here is another typical shady small company from Cocos Islands - http://www.intel.cc

FYI, .cc is top-level domain managed by VeriSign and widely marketed and used as .com replacement.

And now back to the original programming ..

I did not know that. But, are you sure that http://www.intel.cc is really Intel or someone impersonating Intel? But even if the Hamachi company is in Vancouver, Canada, how much asset do they have? If you sue them, they just get out of business and you end up paying your lawyers but recovering nothing. Everything I wrote is still true for small companies anywhere in the World: it is dangerous to trust them with your secrets.

There is a fine line between being cautious and paranoid.



If you'd bothered to read their website carefully, you would've noticed that Hamachi thing is designed not to require end-user trust. You are actually trusting Google with more secrets by using their search engine with cookies enabled than you would ever need to disclose to run Hamachi.

As a binary application it certainly requires certain amount of trust, but the company being small actually means that they MUST care not to do anything wrong, because the reputation is all they got and it would be extremely stupid to ruin it by bundling the product with a spyware. And the fact that you have a possibility to sue, say, Google without forcing it out of business does not mean that you will win. In fact you will loose, because their lawyers are incomparably better than what you can ever afford.

I was speaking about class action lawsuits. As an individual I cannot even sue the builder of my house for unfinished or lousy work. (Actually, I did, and ended up paying legal fees 5 times higher than what the judgment was against the builder, and even that I cannot collect, since they went out of business right in time.) Another good example is Hyundai. They lied about the horse power rating of several models of their cars. Some rich lawyers sniffed business there, and filed and eventually won a class action lawsuit against Hyundai. Their legal fees and recoverable expenses were several million dollars. As a customer who bought a Sonata with the false rating I became eligible for a compensation of $250, without even knowing about it. Being a registered customer I got a notice and so I submitted my paperwork. However, Hyundai conveniently lost my letter (which was requested to be sent by regular mail; certified or registered mail was not going to be accepted). Now I am an individual against Hyundai, completely powerless. They claim they never received my letter and because of the requirements of using regular mail I have no means of proving that I have sent it. I have photocopy of everything, but it is very weak evidence. The moral is, if there is big money involved, there is always a lawyer who will take the case. And nobody cares what damages a single person suffers.

I said, Hamachi might play fair now, but this could change in any minute. What is more lucrative: building up reputation in a cut-throat industry in the course of several years, or after a few months stealing the secrets from the users and selling it? I don't say they do or even plan to do it, but I see nothing that ensures they will stay honest. The temptation and the value of the secrets could be high.

And I did bother to read their website. There is not enough information there to make a security analysis. Especially, implementation details are missing. All the security depends on that. Slogans, like "industry-standard algorithms and protocols" do not say anything. Other claims cannot be verified either. You just have to take their word for it. This is not "open security", but hogwash, until the actual source code is published. Just one example: P2P key exchange with Diffie-Hellman protocol. It is known to be susceptible to man-in-the-middle attacks, where the mediator just can get every secret it wants. You just have to trust the server.

Former of course. If you are not a low-life criminal with questionable morale.



Agreed. But being overly sceptical and paranoid will result in complete isolation. You have to estimate risk in the context.



http://www.hamachi.cc/security has as much implementation details as you can handle.



You don't seem to understand the difference between 'open specs' and 'open source'. Cisco VPN agent is based on published specs, it can be verified to comply with them and therefore it can be rated as trusted. It is not an open source however.



DH purpose is to deriving shared secret. Period. It does not guarantee authenticity. Authentication of generated keying material is done as a separate. This is how key exchange protocols work including Hamichi one.

Next 'hodwash' example.

I am not, but I don't know those people. Do you? Even if you say they are saints, I have to trust you. And they might hire somebody, who is less honest. Or some hackers might hijack their servers. Or they could get forced to spy at gunpoint. Or they have to obey a court order. Or the police or their intelligence service request them to look at the communication. There are countless possibilities when becoming dishonest (to me) is what they would want to do.
I can handle much more. Only the protocols are described there. As I wrote, there are not enough details. Like "the random IV is generated", "it generates a pair of random 32 bits numbers", "client's 1024-bit nonce", etc. How are these random numbers generated? What are the requirements (entropy, uniqueness, independence...). "Every message is also uniquely numbered". How? What happens if a message is lost? Or a part of the message? Or it is repeated after a random error? Likewise, how are the keys generated? The client uses the supplied code, but seeing a few output values nobody can tell if they are really random or generated by an algorithm known by Hamachi only.
Of course I do. What I meant was that specifying some part of a set of protocols is worthless without the missing details. Open specs ensure interoperability, but don't establish security. I trust Cisco because of its name and financial background, but not because of published protocol specs. In case of a small, unknown company only open source can establish trust.
What is "overly"? Hamachi is a security product and so it has to be assessed by security standards. People use it to communicate secrets. I use Open SSL when I need security, and I did look at the source code, as others I know did and I trust their judgment. Or, I use the products of large companies, like MS, McAfee, IBM. I don't see the reasons why I should trust an unknown, small company, which provides a proprietary security solution, without open source SW. If it was not a security product, I might have given it a try.
Shared by whom? By the mediator *and* by both communicating parties? Of course, not. Only the two clients should share the secrets. (There are combined protocols, which ensure authentication also.) In the Hamachi case, the mediator knows all the initial keys, it might know how private keys are generated and how public keys are transferred, so it is nontrivial how to keep the DH shared secret from the mediator. Here again the devil is in the details, not available from the "open specs".

Of course they can be evil, but you missed the point of Hamachi entirely. The amount of trust you are required to place in them does not make you vulnerable even in a worst case scenario, which would be them going completely evil. This is one of its core properties.

The server merely establishes tunnels. Tunnels are direct, not server-relayed. No peer-to-peer data including their key exchange goes through the server. The control connection between clients and the server is used essentially to request tunnel establishment. That's all. Clients have full control over tunnels. If they dont like this or that tunnel, they can drop all traffic to/from it (possibly using external 3rd party firewall).

Even at the gunpoint they will not be able to spy on anything more than a tunnel establishment.



You are switching a subject. Whether it is Mersenne Twister or ISAAC is a an (important, but) irrelevant implementation detail. Do you know what random generator IE uses ? I don't know either.

You started by saying that binary distros are untrustworthy. With that I can agree to some degree. However saying that you cannot trust them because they don't specify PRNG algrotihm does not make much sense to me. It is important, but it affects security rather than trustworthiness.



It's called message replay protection. It is a basic functionality found in all bulk transfer security protocols starting with SSL/TLS and ending with ESP. It's only natural they don't go into the detail describing it.

Arguably their description requires an exposure to VPNs, so it might appear vague to someone who is merely sceptical and do not come from VPN background.



This is described in a spec.



Open specs also show a willingness and commitment to interoperability.



I disagree. Nothing prevents them from releasing source code that is different from the one that is used for building official releases. If they decide to go evil, it will be perfectly possible to do even with sources open.



Which standards are these exactly ?



It is most certainly your choice. However MS is the last company I would ever trust



No comments. Either you haven't read their spec carefully or you seem not to understand how DH is used in authenticated key exchanges. Their key exchange is almost an exact replica of IKE, which is an industry standard.

To sum my points up - their problem is not in their protocol or architecture, which are both fine and actually very clever. The problem is in end-user trust in their binary distribution. I agree it is a trust issue, what I do disagree with is the fact that a possibility of class action suits is what makes software of large companies any more trustworthy. To me trust is based entirely on the reputation, not on financial standing of the company.

Only if you believe they operate as stated (that is, you trust them - and in that case you shouldn't care if they could eavesdrop or not, because they will not). I tried repeatedly to explain that if they control the algorithms running in your PC, the keys, the nonces, the sequence numbers etc. they can make all the secrets visible to them. You say: "they told me how they operate, and in that way they cannot cheat". But if they lied (or they are mistaken) about how they operate, you know nothing.
The communication is still over the Internet, is not it? Everybody can see the packets, cannot they? Can they insert extra packets with their own information? And then the question becomes critical: what happens if two messages arrive with the same sequence number? If one of them is dropped, which one? This is how, with clever, innocent looking programming, the man-in-the-middle attack becomes feasible. Therefore, the issue about handling messages with the same sequence number is critical. It is a security issue, but more importantly a question of trust: did they leave open this back door for a future attack?
Not at all! The random number generator can be seeded with a known piece of data, like the serial number of the SW and the time. If it is also known by the server, it will know the sequence of the "random" numbers a client generates. If nonces, keys are derived from these numbers, they are known by the server (or mediator or whatever you call them), so they can learn your secrets. You have to trust them not to implement this kind of pseudorandom number generators, but you cannot tell for sure if it is not open source SW.
I did not say it cannot be done securely, but you cannot be sure if it *is* done securely in proprietary SW. Especially, if nonces are not random, if your keys are known by the server. Also, as I mentioned earlier, it is a nontrivial issue what happens at a replayed or modified-replayed message blocks. They can open a backdoor.
As it is described their keys are generated from random nonces. By now you should understand that the problem is not how to assemble the keys from these nonces, but how these nonces were generated. If they were members of known sequences, the keys are also known by the server.
You catch them immediately with recompiling the source. In fact, this is the test most people do with open source security SW. In many cases binaries are not even provided.
For example FIPS 140-2, but I meant common sense "standards", like backdoors, side channels, error tolerance, attack detection and response but most importantly: open source or third party (like government agency) evaluation under NDA.
Not the last for me, but not among the top 500 either.
You can separate secret sharing and authenticating the result with public key signatures. My point is that you might not be able to do either of these in a non-trustworthy environment. As I explained above, the man-in-the-middle attack could be made possible with improper reaction to duplicate messages, and the server knowing the private signing keys can easily forge signatures.
This is the most dangerous statement in information security. As we have seen, a seemingly trivial detail, how a pseudorandom number generator is seeded, makes all the difference between a secure system and an insecure one.
This is a correct summary.
You decide whom you trust. For me reputation is a volatile thing, you have it today but might loose it by tomorrow, and then you are in trouble with all the secrets you trusted to the wrong people. Companies are governed by financial interest, and I trust large companies often (but not always) act accordingly. Financial interests do not change that fast, but it might be just wishful thinking. Sometimes you have no choice: you have to trust the OS vendor your company imposed on you.