On Sunday 18 September 2005 00:41, Raphael Manfredi wrote: >>> A call for idea is launched: how can we make sure this >>> GTKG-specific server is not used by other servents,
Quoting Haxe <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel: >> You can't. But if it's something specific to GTKG, I don't think >> that others will try to exploit it. I suspect they likewise have >> their "own" servers. On 18 Sep 2005, [EMAIL PROTECTED] wrote: > Well, you can make it GTKG-specific by using several tricks: for > instance, you can use the token logic GTKG uses to identify itself, > which is not secure but is a burden to adapt by foreign servents. [snip obfuscation ideas] As you will be giving the source code away, I don't really thing that the binary protocol or port rotation should be used. Or at least used for the rational that only GTKG will use the host cache policy. A binary protocol maybe better for bandwidth reasons. Also, it seems kind of counter to the open-source idea to prohibit other open source developers/project from using these servers. I certainly don't have the blood and sweat in GTKG, so perhaps I can be caviler with my idealism. But if another open-source gnutella/file sharing project has a good idea, there should be no qualms about using that code/concepts in GTKG. I think the real problem would be to prevent a closed source (and commercial) vendor's clients from using these servers for free. I think a good place to start would be to look at authentication mechanisms in security protocols. They will all boil down to some "secret" on the client that must be verified by the server before communication begins, afaik. Generally maintaining this secret is a pain. There are hierarchical schemes to issuing the secrets and revoking them, but I really don't think that is worth the effort. You would need a separate mechanism to issue the secrets from the source and it would be vulnerable to compromise. Making this automated, would mean that any vendor could copy the automation to have their clients issued secrets. Perhaps you could have default secrets in each version of GTKG. As bandwidth nears some limit, use could be restricted to only later versions, etc. You might issue alternative secrets to donors and developers. Now you have a problem co-ordinating these "secrets" to all cache servers. To get around this, the secret could be sent in the form of a signed public key to the cache server. The cache server could then verify the client certificate was properly signed. That sounds workable. However, I don't know if there are encryption libraries available that fit GTKG license model. Also, this would really eat up some CPU cycles on the cache server allowing some sort of DOS attack. Does anyone have information on how the current protocols behave? I have lots of ideas on communicating IP addresses and ports, but I think I should look at the current specification before spouting off crap. fwiw, Bill Pringlemeir. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
