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