yo jay, i think the security issues exist with the C clients as well as the Java. as Stas said if we want to make our security criteria tight enough than every blessed netrek client out now would have its key revoked. i think carlos has some legitamate concerns and if you can make it comparably as hard to hijack your key as it is with any of the C compiled clients then you will get the key. perhaps allow some others to look at/play with your code. is the CVS server up yet? zach --- ". ." <msucka0xff at programmer.net> wrote: > Folks, > Well I think the only thing Carlos will accept is the > appology I offered last time, but not the java keys I > have been struggling to get him to accept. The problem of > blessed clients is more complex than I can solve with a > one liner like "jar file is signed". It is almost (if not > entirely) equivalent to the netrek server to netrek > blessed client issue. I just shifted the issue, but > solved nothing. > > The reason for this is that even if the jar file is > signed, I need to have something in the applet telling my > server that the applet originated from my server, and is > running in the client's java plugin. This breaks down if > you were to imagine that somebodies could devise a > surrogate process posing to be the digitally signed > applet. Also the authority of that statement is based on > the believablity that the java plug-in running on a > remote host is saying so, and not an imposter > java-plugin/process. This thing has so many complications > including java VM compatibility within different > webbrowsers (e.g. netscape, MSIE, mozilla), implemented > feature sets (some VM's do support specific features > others do not), that it's intended audience becomes > further diminished. As it is, almost nobody uses it > anyway. I would be worse off with this utility > implemented in this fashion, than the applet being what > it is without. When I began to look at it closely, I had > the gut feeling that I was t > rying to get java to do something it was not able to do. > It was the same feeling I had when I tried to get RMI to > operate in an applet over HTTP tunneling and over remote > proxy servers. It is another example of how java appear > to provide one functionality, but after some reality > checks and internal R&D it turns out not to live up to > its glowing promises. > > If I am to continue using java, I must come up with a way > to obfuscate the key in the java byte codes. But again > this is just a guess and still Carlos must approve. Also > to deliver the applet to more users, I need to either get > rid of RMI (I thought XML was an alternative), or get the > users to grant the applet more privileges (which again > limits the audience). If you look at how the java applet > runs now, you would say it does, only bearly run. It is > no where near as robust or solid as the native C compiled > version. I am not certain that this will change since I > have decided to scale back my effort on this project, if > not abandon it entirely. > > In the mean time, if the server admins can add my java > key to their key chains so that the observer client can > still login to pickup servers that would be terrific. > Note that I think it would be almost as difficult for > someone to call my generateRSAResponse in the correct > sequence with their own info borg as it would be to > reverse engineer the netrek clients, and steal the keys. > Also note that the actual code that runs > 'generateRSAResponse' is a method that belongs to a > remotely activated object that is created in response to > a factory call -- it is all very hairy business > understand the program flow in the first place. Note that > my current version of the applet is obfuscated, and has > no RSA keys. So evil hackors must overcome all of these > issues for the relatively weak reward of accessing an > info borg (not in the wildest fantasy as useful as the > keys to a bank vault). The performance just does not > exist for a play borg, because it is tcp only and routed > thru my bottleneck pa > cket rerouter. > > Please let me know if you can add my key so I will know > which servers to allow the JTrekApplet to run on. One > amusing footnote is that now it only runs on my own > netrek server (which nobody uses anyway), and Robert > Temples original unmodified JTrekApplet could have done > that. What a way to waste a year of my time! I hope this > never happens again. I should have stayed in retirement. > (just kidding ;-) I still would like to bring gl4java to > observer clients hehehe. Just give me a key I can use ;-) > ;-). > > Obstreks-RSA-Key-Java1.4.2_02:ct=Obstrek:cr=msucka0xff at programmer.net:\ > :cd=March 2004:ar=Java1.4.2_02:cl=inl,standard2:\ > :cm=JavaSucks:\ > :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ > :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: > > Thanks, > -Bob Dang > > ----- Original Message ----- > From: "Carlos Y. Villalpando" <unbelver at us.netrek.org> > Date: Thu, 18 Mar 2004 19:57:02 -0800 > To: ". ." <msucka0xff at programmer.net>, > vanilla-devel at us.netrek.org > Subject: [Vanilla Devel] Re: Add java key (3rd attempt) > > > > > I've been not very well net-connected at work today, > hence the long > > delays. > > > > Quoting . . <msucka0xff at programmer.net>: > > > > > This is the 2nd attempt at sending the same message. > Basically the > > > jar's will be digitally signed. That means that > nobody can call the > > > 'generateRSAResponse' without a jar that I > distributed/created. The > > > technology used to sign the jar file is stronger > than that which is > > > used to authenticate and bless netrek clients. > > > > I'm researching signed/sealed .jar files, and I see a > lot of > > references to make sure the browser/user can be sure > its untampered so > > that the browser/JavaRunTime can expand priveledges, > but I can't find > > where the server can verify that. Could you help me > out and give me a > > reference link? Thanks. I'm still looking, though and > I admit I'm > > not very knowledgeable about this. Teach me. Convice > me. > > > > What I'm worried about is the user unsigning/unsealing > all the .jar > > classes so that no class would want to throw a Security > Exception, > > giving it UniversalConnect privledges, removing the > certificate checks > > in your code, and running that. > > > > What do you call on the server that will force a > Security Exception to > > get thrown on the client and you finding out about that > and dropping > > the connection? Thanks! > > > > > At this point there are no substantial technical > issues surrounding > > > the secruity and use of the netrek RSA key for other > anything other > > > than it's intended purpose. > > > > I'd like to independantely verify that. Anyone else > listening in here > > can give me pointers too. > > > > > If you do not, I would be inclined to the conclusion > that you are > > > letting your personal feelings interfere with netrek > progress. > > > > Here's a hint: Trying to insult people you're trying to > convice of > > your position isn't a good idea. Especially when that > someone has a > > history of publicly trying to remain impartial and > reasonable when it > > comes to "official duties." As opinionated as we > "official" people > > are, I've noticed that we are all reasonable when it > becomes an issue > > of official duties. > > > > I revoked the Java keys because it became obvious that > more people > > than just you knew how to extract the Java keys on > r.g.n and in my > > personal e-mail. I even publicly stated that the abuse > monkey > > argument wasn't enough. Yes, I have publicly stated as > a player on > > r.g.n. and in hockey games that I think eject/abuse > monkeys are > > driving away new players, but I've also said you don't > need your > > client to be anon, so that wasn't enough. > > > > I'm all for more observers. I'm all for more coders. > > > > Now you're introducing a new client verification > method, so you have > > to expect that you need to convice people. > > > > Assuming that .jar signing does pan out, a few > suggestions: > > > > 1) INL team captains are going to want to know who's > on their obs > > slots. At the very least, leave in an IP address, > or a FQDN answer > > to a pig call handled at the redirector, not the > client. > > > > 2) Now that I think about it...... This really > shouldn't be a > > separate thing. Once this is mature enough I'm > wondering what > > it would take to turn this into a Java version of > ntserv. Or at > > the very least, run the redirector on the same > server as the game > > and put the redirector in the .bypass file. Roll > this into > > Vanilla so it doesn't need a key. > > > > --Carlos V. > > ----- Original Message ----- > From: "Carlos Y. Villalpando" <unbelver at us.netrek.org> > Date: Thu, 18 Mar 2004 19:57:02 -0800 > To: ". ." <msucka0xff at programmer.net>, > vanilla-devel at us.netrek.org > Subject: [Vanilla Devel] Re: Add java key (3rd attempt) > > > > > I've been not very well net-connected at work today, > hence the long > > delays. > > > > Quoting . . <msucka0xff at programmer.net>: > > > > > This is the 2nd attempt at sending the same message. > Basically the > > > jar's will be digitally signed. That means that > nobody can call the > > > 'generateRSAResponse' without a jar that I > distributed/created. The > > > technology used to sign the jar file is stronger > than that which is > > > used to authenticate and bless netrek clients. > > > > I'm researching signed/sealed .jar files, and I see a > lot of > > references to make sure the browser/user can be sure > its untampered so > > that the browser/JavaRunTime can expand priveledges, > but I can't find > > where the server can verify that. Could you help me > out and give me a > > reference link? Thanks. I'm still looking, though and > I admit I'm > > not very knowledgeable about this. Teach me. Convice > me. > > > > What I'm worried about is the user unsigning/unsealing > all the .jar > > classes so that no class would want to throw a Security > Exception, > > giving it UniversalConnect privledges, removing the > certificate checks > > in your code, and running that. > > > > What do you call on the server that will force a > Security Exception to > > get thrown on the client and you finding out about that > and dropping > > the connection? Thanks! > > > > > At this point there are no substantial technical > issues surrounding > > > the secruity and use of the netrek RSA key for other > anything other > > > than it's intended purpose. > > > > I'd like to independantely verify that. Anyone else > listening in here > > can give me pointers too. > > > > > If you do not, I would be inclined to the conclusion > that you are > > > letting your personal feelings interfere with netrek > progress. > > > > Here's a hint: Trying to insult people you're trying to > convice of > > your position isn't a good idea. Especially when that > someone has a > > history of publicly trying to remain impartial and > reasonable when it > > comes to "official duties." As opinionated as we > "official" people > > are, I've noticed that we are all reasonable when it > becomes an issue > > of official duties. > > > > I revoked the Java keys because it became obvious that > more people > > than just you knew how to extract the Java keys on > r.g.n and in my > > personal e-mail. I even publicly stated that the abuse > monkey > > argument wasn't enough. Yes, I have publicly stated as > a player on > > r.g.n. and in hockey games that I think eject/abuse > monkeys are > > driving away new players, but I've also said you don't > need your > > client to be anon, so that wasn't enough. > > > > I'm all for more observers. I'm all for more coders. > > > > Now you're introducing a new client verification > method, so you have > > to expect that you need to convice people. > > > > Assuming that .jar signing does pan out, a few > suggestions: > > > > 1) INL team captains are going to want to know who's > on their obs > > slots. At the very least, leave in an IP address, > or a FQDN answer > > to a pig call handled at the redirector, not the > client. > > > > 2) Now that I think about it...... This really > shouldn't be a > > separate thing. Once this is mature enough I'm > wondering what > > it would take to turn this into a Java version of > ntserv. Or at > > the very least, run the redirector on the same > server as the game > > and put the redirector in the .bypass file. Roll > this into > > Vanilla so it doesn't need a key. > > > > --Carlos V. > > > > > > _______________________________________________ > > vanilla-devel mailing list > > vanilla-devel at us.netrek.org > > > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel at us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html _______________________________________________ vanilla-devel mailing list vanilla-devel at us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel