JNLP Extensions Signing/Dependencies

Networking & Multiplayer
#1

As mentioned before I’m writing a little 2D library thing. It’s based on LWJGL. LWJGL are going to provide an JNLP extension some time soon, and I’d like to provide a JNLP extension for my library. So… I’d like to chain these things together. However, I find if I have one extension that references another (where the first isn’t signed but the second is) I get the following error in webstart:

Category: Security Error
Multiple hosts referenced in resources

Now this doesn’t really make sense to me - I want to reference an unsigned extensin and have it use a signed extension so only the bit of code that absolutely positively has to be signed has privledged access.

Has anyone else tried this, had the same failure, got it to work etc? If I combine the two extensions into one signed extension everything is fine. If sign the first extension (my library) then everything is also fine.

You can find the extension jnlps here:

http://slick.cokeandcode.com/demos/slick-ext.jnlp.txt
http://slick.cokeandcode.com/demos/lwjgl.jnlp.txt

And the extension is referenced by the line:


<extension href="http://slick.cokeandcode.com/demos/slick-ext.jnlp"/>

Any thoughts/ideas/pointers appreciated,

Kev

#2

The webstart faq said something about making a helper extension if there are different certs (for different jars) involved. I guess this is the same kind of problem and could be solved in a similar fashion.

http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/faq.html#213

#3

In this case the only JARs I want signed are the ones in the LWJGL extension. They’re all signed with the same cert.

Kev

#4

You have the codebase in the extension JNLP set to “http://www.kevinglass.com/”, I think that’s the problem.

#5

That extension was actually hosted on kevinglass.com, needed a seperate domain for tested. Just the text file was at slick. If they were all in the same domain it would just work :slight_smile:

Kev

#6

Ok, I was thrown off by the relative reference to lwjgl in slick-ext.jnlp. So you want slick-ext.jnlp to be on a different host than lwjgl.jnlp, right? Mmm…

#7

Thats correct, since I’ll be hosting the slick extension and LWJGL will host their extension. However, the issue appears to be that to reference an extension thats not hosted on your game’s server from your game’s JNLP, the extension must be signed and trusted. That seems kinda wrong to me - I’m just hoping some can point out where I’m going wrong.

Kev

#8

Oops if I misunderstood, but I thought you said in IRC that that was one of the cominbations that DIDN’T work - that the game had to be signed too?

By design, without any extra context, what you said above is definitely the case, unless you are running in a sandbox. The idea being that the user chose to trust YOUR site, not “random untrustable code somewhere on the internet” that you’re pulling in.

But, not mentioned in the quote above, is the fact that you are in a limited way breaking out of that sandbox, and that you’re doing the breaking out of it not in the main game NOR in a signed extension referenced by the main game, but in a signed ext referecnecd from a NON-signed extension (which is ref’d by the main game).

i.e. you’re allowing untrusted code (the extension) which you - the game-author - cannot declare safe because you dont control it, to access something that has full access, and it could be abusing that power.

…but, as mentioned above, I thought this wasn’t the problem, because I thought this combo hadn’t worked for you. Or, maybe I was just misreading your replies because I was tired and stressed, sorry :(.

Finally: this is one of the reasons why “purchasing certs for libraries (preferably in bulk at very low price)” was one of the things on my list of must-haves for JGF. Pretty much every nont-trivial game-lib needs certing, basically, and most open-source projects dont have the money to do so.

#9

This keeps happening. It makes no difference whether I’m an extension or a application - if I’m not doing anything that requires a certificate - I shouldn’t need one. In this case for instance, Slick may well be using LWJGL to do some stuff that require priviledges but the user should only have to accept the license for LWJGL which is the thing giving these permissions.

If I can do dodgy things via LWJGL is besides the case. If I write an application that uses lwjgl it doesn’t need to be signed - in that case you’d still be allowing unsigned code to use signed code to do prived things. Just because its an extension doesn’t make any difference. For instance, I could just include everything thats in the extension for Slick (unsigned) as part of the main JNLP, reference the LWJGL extension and then the user only has to agree to the LWJGL extension certificate to get the exact same result.

In that use case all the jars in the main JNLP (including everything slick) would be unsigned - no need for the user to agree to anything and only the LWJGL cert would be important.

It just makes no sense.

Kev

#10

I’m not sure how to explain this differently, but I believe its about who you trust. The point of the signed/unsigned stuff is that the user:

  • knows the identity of the game developer (they chose to run this url … or not)
  • does not know the identity of 3rd party code
  • …but is automatically safe trusting 3rd party code IFF you (the trusted developer) have vouched for it (by including it in your game) AND the code you vouched for is the same code being run.

From a cryptography perspective, it makes sense - they are insisting on the set of criteria that makes it possible for the user to decide whether or not to trust what you’re peddling. If you’re providing the file, then its the same one you (the developer) assessed and decided was safe.

Off the top of my head (v.tired right now) there is still a problem - whenever you use signed webstart extensions you’d really need to include the signature of the signed extension in your own JNLP to prevent the provider changing the extension and re-signing it. So, in fact, all this (and what follows) may not make sense. Argh.,

AFAICS (and I’m tired right now, so may be missing something) there is one other assumption, which is that you control your own website and the files on it - which is necessary since the alternative is to somehow certify that e.g. the Kev who runs cokeandcode is the same kev who posts on JGO. As there is currently no such thing as a true globally trusted global online identity (despite the many corporations and organizations trying to become the de facto standard for it) - and won’t be until govts start certifying that the holder of SSL cert X is also the person who has passport number / ID card Y who is also Kevin Glass of 14 Acacia Avenue - this assumption is needed to make the whole scheme work.

But it is definitely a flaw, since webstart does nothign to protect you against momentary DNS-hijacking attacks. In all honesty, webstart SHOULD have an extra check for whether the URL you’re going to is being served via SSL, and if not it should warn the user “the code you are about to run MAY NOT BE what you think it is! Run away now! Burn the computer, and flee!” (which would approximately fit in with the tone of most of the webstart warning messages :wink: ).

So … actually, it looks like they trieD to make a proper, secure, system, but the security expert was having a day off, and his assistant / friend / colleague thought they could do it without him. YMMV, will re-think in the morning when more awake :(.

#11

…so, I was trying to say "this does make sense, because this way you CHOSE which files to put on your webserver (which version of the library, etc - i.e. the version “without the trojan horse” for instance :)).

#12

That still doesn’t hold water for me.

So, as a developer I can decide that a certain set of libraries that I’m going to store locally are safe enough to distribute from my website. Presumably you don’t believe that all developes decompile the libraries they use and check that there’s no hidden bits of code in there that can do dodgy thing say on timed events. We look at the source of the library, decide whether it’s reputable - and decide that the library is likely to be safe. So, how’s that different from a developer deciding that a source of an extension is reputable, and that any updates that source makes is likely to be safe. DNS, WebServer hacks aside (thats a whole different matter, if I can hack your webserver I can probably hack your source repository and take your certs anyway) - there’s no real different apart from distribution method between these two things is there?

Ok, you can argue thats theres a slight difference - the extension could be changed with the developer knowing and hence do something dodgy that wasn’t seen in the original version - right, but isn’t that the developer’s choice - and isn’t that the very choice they’re making by becoming dependent on any extension anywhere?

This whole thing just stinks of me making some simple mistake somewhere which makes it look like it’s shite, but I’ll be damned if I can find it.

Kev

#13

Yeah, I’m just trying to find reasonable explanations - bearing in mind, though, that I’m working from the official documentation that explicitly describes doing most of the above on purpose as part of the spec. It doesn’t quite explain why, but it seems to hint at my above description as being the “why”. So, I don’t think it’s far wrong.

Agreed, (modulo the above) - but we’ve been through it and no-one’s seen the mistake yet, so :slight_smile: …

#14

I’ve looked into this some more, and the behavior you’re seeing is consistent with the spec. I’m quoting from section 5.5 Untrusted Environments (JNLP 6.0 spec), emphasis mine:

“Extensions: The JNLP file can request extensions and JREs from any host. An application cannot make a socket connection back to any of the hosts where JREs or extensions are downloaded from (unless it happens to be the same host as for the JAR files). Extensions requested from hosts other than the one that the JAR files were downloaded from must be signed and trusted as per section 5.4.”

So while you are able to download extension from any host you want, even if your main application is not signed and trusted, those extensions have to be signed and trusted themselves, regardless of whether or not they need to be permissions-wise. This would mean your slick-ext needs to be signed if you want to include it from a different host, regardless of whether or not it includes the lwjgl extension.

#15

That almost identical text is in the current versions, except that in current versions its clearly not exactly true (I dont know about the context of what you’ve quoted from 6.0) - it can only be talking about not-all-permissions applications, and never makes it clear WTF it really means. In current versions, you have to infer this, from the claim about not being allowed to make socket connections. This lack of clarity pervades the spec, and so its hard to be sure what is intended and what is accidental - and what is a bug. That spec is an excellent way to prevent people filing bugs - nobody really knows what its supposed to do ;).

#16

Thanks for looking up the detail. The old spec was slightly less clear but implied the same thing, I was just hoping that I’d got it wrong - becase while it’s in the specification it just smells wrong :slight_smile: It’s probably me not reading the spec in detail but I don’t see why it makes sense to enforce that extensions not requiring permissions are signed.

The simple example given in the extremely poor extensions documentation for a good use case is an extension that provides an XML parsing library. Using the current mechanism the user has to accept a certificate to allow the application they’re running to parse some XML! Thats just funky.

Kev

#17

Well, the limitation only applies to extensions hosted elsewhere, which does seem to make some sense in light of the “only connect the host you came from” restriction of the default sandbox, but I agree it seems a bit weird not to allow unsigned extensions from different hosts. I don’t see any holes in the trust/security model resulting from it.

#18

…other than those I outlined above?