Johan has posted 1 posts at DZone. View Full User Profile

Webstart Changes Between 6u17 to 6u20: Signed Applications Almost Impossible

  • submit to reddit

Sun/Oracle have done a lot in the latest releases of Webstart, but most of these changes are not very good for us. I am curious to find how others are affected by all these changes.

First we got u17/u18 that broke the desktop shortcuts, because the cached file was already gone, but this is a minor problem. When u19 was released, all our customers deployments of our product (which is a server that serves a Webstart application) didn't work anymore, mainly because of two bugs:

  1. Certain jar files can't be downloaded: they end up in some kind of exception and "unable to launch application"
  2. When point <1> was resolved, we got the new mixed code (signing) dialog, but that dialog was triggered from a thread pool thread. And somehow the whole application hangs because the dialog can't be clicked and blocks all input.

I reported both quickly to Sun, I even got on the phone with them, but u20 which was rushed out didn't fix either of those issues. So we now still have to sign everything, all the jars we ship, even if those that are in extensions and don't ask for permissions.

The setup we have is as follows. We have an application server product that serves out a Webstart application, but that webstart application can have plugins and beans from 3rd party vendors or even open source plugins/beans. We did sign the main jars and the rest are loaded in by extensions: until Java 6u19 this was always working pretty fine. Besides that, because everything is dynamic we have to generate the JNLP's at the server side to auto include all the beans and plugins our customers want to use in their application. So then end configuration is not really in our hands..

What we want is what we had before for quite a long time: no warning or security dialogs at all, maybe one information dialog that informs the client (customers of our customer) that they are about to install an application through Webstart that is signed by us.

But there is already something that has changed, I dont know exactly which java update that was, but now it seems that a JNLP file also has to be signed alongside the jar files because if this isn't done,  we get  a warning dialog that the signature couldn't be verified (which is absolutely not true, our signature/certificate is fine). But it says this because of the unsiged JNLP file. But the JNLP file is generated on the fly and we really can't do anything about that. In our setup that main JNLP file can have infinite number of possible content combinations.

Then I was brainstorming: we have that JNLP file problem, we now have the problem that all plugins and beans including 3th party open source variants need to be signed,  or else you get that mixed mode dialog that can't be accepted for every plugin, so clients will get that everytime.

That signing is already a burden on our customers or plugin vendors. We just want to accept everything that comes from the same server.

So I thought about solution like creating a bootstrap application, that is very small and that just creates a ClassLoader itself and we load all the rest ourself.  So by passing the Webstart classloader completely we would solve the problem of all the jars needing to be signed. But then the only problem I still have here is that how to pass arguments to that client to also get rid of the first dialog that warns about unsigned JNLP files.

When Java 6u20 came along, which suddenly has an extra requirement that the "codebase" must be in the JNLP. So we have to rewrite the JNLP's anyway! But how can we then sign then the JNLP? 

The solution for us would be if javaws would just not try to trust something if it is already trusted. How can we do that? This sounds very easy to me. If javaws sees that the application comes from a https (ssl) site, and that site certificates validates, then everything that comes from that site is trusted automatically.

What do you think?

Published at DZone with permission of its author, Johan Compagner.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Ronald Miura replied on Sat, 2010/04/17 - 5:48am

No, definitely no!

This would be very convenient, but as a security-specialist professor told me once, 'convenience is inversely proportional to security'.

If I enter a https site, I trust it to get the data I choose to enter in its forms (e.g. credit card number at, but I don't trust it to run code on my machine with root permissions.

Frank Schwarz replied on Sat, 2010/04/17 - 6:38am

from jsr 56:

5.4.1 Signing of JNLP Files
A JNLP file can optionally be signed. A JNLP Client must check if a signed version of the JNLP file exists, and if so, verify that it matches the JNLP file that is used to launch the application. If it does not match, then the launch must be aborted. If no signed JNLP file exists, then the JNLP file is not signed, and no check needs to be performed.

A JNLP file is signed by including a copy of it in the signed main JAR file. The copy must match the JNLP file used to launch the application. The signed copy must be named: JNLP-INF/APPLICATION.JNLP. The APPLICATION.JNLP filename should be generated in upper case, but should be recognized in any case.

The signed JNLP file must be compared byte-wise against the JNLP file used to launch the application. If the two byte streams are identical, then the verification succeeds, otherwise it fails.

As described above, a JNLP file is not required to be signed in order for an application to be signed. This is similar to the behavior of Applets, where the Applet tags in the HTML pages are not signed, even when granting unrestricted access to the Applet.



Johan Compagner replied on Sun, 2010/04/18 - 5:54am

I figured out the problem why we where getting the security warning about not being able to verify the signature. We are also sending in some <property> values (for example the mac menu bar position) and 1 jvm args property (SoftRefLRUPolicyMSPerMB) which is important for our application (we rely big on soft references in our application)

I dont agree with if you trust https to fill in your credit card information that you dont trust it for running an application. I dont say that the app needs "root" permissions just user permissions to do stuff for that user (read/write files). I am the opposite in this area, the credit card info for me is way more sensitive data then that application... Besides that signing stuff is just to validate it origin, so thats exactly the same for https sites, if we download a webstart application that completely comes from the same server (jnlp files and jars) and that is a https server so the downloaded can verify exactly where it comes from What is then what you loose??

 I find this uber sensitive restrition we have now with the latest webstart releases just way to much. 99% of the people on the internet just download application and just install it.. 99% of the people that get that webstart security dialog just dismiss it and say yes i accept, because 99% of those people really have no idea what to do else and what it all means, and they want just to have that app.

For example if we made our application a downloaded application and people could just install it locally there wouldnt be any strange security dialog and people woud just install it as easy. So why is a webstart suddenly so much harder? This will make webstart applications just way harder to use. Because it managers could say no we dont allow those app that say "cant verify signature" which is in our case just not true.. Everything is signed, except the jnlp file that sets 1 vm property that we want for performance.... If we would have a downloadable application that users could install then suddenly in that same environment it wouldnt be any problem! That is just strange.

For our product it is already a burden now that every plugin and extension that 3th party vendors can build must be signed also because else you will get that mixed mode dialog now everytime. So thats not an option. And as i said many of those plugins are free open source plugins, how can they sign it?? years and years before java 6u19 this was not a problem and suddenly it is a bit problem where we just can go around.. 

I dont mind Information dialogs telling the user that this application is going to be installed or this (jnlp) extension  is going to be installed. Thats just fine, i just dont want those "signature cant be verified" warning dialogs.

1 other reason for us that a https check and information dialog would be way better for our product that the dialog they get now is that end users dont know is, because they are not a customer of us, they think they download application X from there supplier, so for them there suplier is the one they want to trust and know. Not us. So that dialog doesnt tell them much at all. 

kappa one replied on Sun, 2010/04/18 - 7:54am

yeh the changes in J6u19 broke a lots of java applications, see this thread,22230.0.html for example.

Ronald Miura replied on Sun, 2010/04/18 - 9:18pm

Web Start will only require you to sign a jnlp app if you do potentially dangerous stuff (open sockets, listen to ports, read/write the local disk, etc.). If you say you trust a signed app, it will have permission to do anything you, as a logged user, can do (the fine-grained security model has never been implemented). And most (Windows) users log in as administrators. So, one could, for example, install keyloggers and other malicious software, automatically.

HTTPS, in contrast, indicates you trust that the site you are visiting is the site described in the certificate, and that you trust the communication between it and your computer is secured (encrypted). But, it will only have access to data I input myself.

Guido Amabili replied on Mon, 2010/04/19 - 12:40am

I am working on a signed webstart application which should support i18n.

So I placed  all the properties (properties and fxproperties) files in a folder in the user directory and added thoses files to the classloader.

Now I get the mixed code dialog too even if those files are not binary files.

As a workaround, I will try to bundle the properties files in a jar and sign that jar.




Johan Compagner replied on Mon, 2010/04/19 - 3:58am in response to: Ronald Miura

and our solution is just exactly that.

It is a webstart applicaiton that is launched by downloading it from a https site, but without that site running also our server portion the application itself is useless. Because the client side is more or less a "browser" for the data that comes from that site (a tomcat application server) 

So it is a always connected webstart application of the server it is coming from. 

The thing is with signed application the only thing it does for you is that you can validate where it comes from. Or validate who made it so that you can trust it, the same is for a https site where you fill in your credit card information. You know 2 things, you know that the communications is encrypted, and you know that you talk to the person/site that you expect to talk to. And thats just the same when downloading jar files. You know where it comes from, you know for sure that it really comes from that site, and you know who is giving you those files because you do know and trust the site.. So what is the difference? Which other security do you think you get by adding a layer of signed jnlp and jar files on top of that? Do you think that because of that you dont get keyloggers? If you install such a program then with a signed jar or with a https site you know where you can go and complain to. There is not a big difference, its just what you trust. Do you trust the site, do you trust the company that signed the jar?

Johan Compagner replied on Mon, 2010/04/19 - 4:03am in response to: kappa one


 that site exactly also sums up the things we found, i already made bug reports for most of them yes.

Especially that all our extension jnlp files now also need and must ask for all permissions... Else we still get that mixed mode dialog.. Very weird, you force now that the extension must ask for something they even dont want or need.

Silvio Bierman replied on Mon, 2010/04/19 - 6:51am in response to: Johan Compagner

There is a big difference. I can visit a HTTPS site without trusting the publisher of the site. I can do that because I know that as long as I do not enter any sensitive info on the site they have no way of getting at my secrets. Trusting an application to run on my machine is a completely different thing because I will ONLY allow that if I do trust the publisher.

Johan Compagner replied on Mon, 2010/04/19 - 6:58am in response to: Silvio Bierman

I dont say that you dont have those checks anymore.

You just get a Information dialog when installing a webstart application from a https site telling you that you are about to install an installation from this website with this certificate that is verified.. If you dont like that you can always just cancel it!, Its not that i say it always just should install without any user intervention.  

No, One information dialog where you can see the https certificate (path) where you can say "Install"  or "Cancel".  But from that moment on (if you say accept/install), everything from that same site is seen as secure. This way the end user is still in full control, gets all the information up front that he can checkout to see if he really wants to install this app.

Zac Bedell replied on Mon, 2010/04/19 - 4:38pm

I know it's somewhat apart from your question, but have you considered using alternatives to Java Webstart? I switched to an open source replacement called GetDown about a year ago, and it's saved me countless hours of head banging. It even made it easy to build NSIS based native installers for Windows which was something my users were clamoring about for some time.

You can find GetDown's source here:

I used it for the desktop component of an ebook reader for iThing's called BookShelf. One of the biggest benefits to me was that GetDown supports inter-release JAR patching rather than just downloading the entire JAR every time. I know that's something jnlp supports, but I never did get it working properly with WebStart. It works great with GetDown and has saved a bundle in bandwidth fees.

Granted that's not much help if you're married to WebStart for any reason, but it's very much worth a look if you have the flexibility to change.

Johan Compagner replied on Tue, 2010/04/20 - 2:44am in response to: Zac Bedell

we throught about such model, thx for pointing to a implementation..

problem is that  how to get that first jar and execute it with those arguments.. Thats way to much for an average user and we have a problem because we use urls for "deep linking" so if you use url X then the application (same app code) starts up loading X and if you use url Y then the application is called with other arguments so it is configureds and loads solutio Y... So we push quite some arguments to the applicatio from the server to the client with the jnlp, don't know if that is easy to do with GetDown..

Patrick Talbot replied on Tue, 2010/04/20 - 10:45pm

I agree with Johan saying that this whole new security layer is way too much and will only lead to kill the very idea of what WebStart was made for at first, and which was one of the strength of the JVM: an easy deployment and updating tool already installed with any Java enabled computer.

Not allowing mixed code can make sense in a way, but right now it is so badly implemented that it just adds complexity and problems to the technology, and as Johan said, the end user will not really see any benefit in that, only right now they can surely feel the pain, just like us developers (and open source developers like me who now have to sign their every jars - including each and every library they use). Will the average end user understand this? Of course not!

Actually this reminds me of a discussion a few months ago on the apple java-dev list about the kind of message that Mac OS users get in the Apple implementation of Java Web Start: when you launch a jnlp file on a Mac, you will see a very scary message if your app requires , something like: "Give me the keys of your computer and all your passwords or I will not run this app!" - I'm only half kidding here - one of my user when first confronted to that message send me an angry email resuming his views: "Never going to happen!" - I had to explain to him that if this was his choice then the app would never run.

Now, remember that with the current security model, which is far from fine-grained in WebStart, you must add the security/all-permissions node for something as simple as System.getProperty() - and then of course you must sign all your jars if you do that! Know also that for a binary application that you download from the internet, you will get a very simple warning on Mac OS, saying 'this application has been downloaded from the internet, do you want to execute it?'

So why such a difference? Why would an application launched with WebStart be treated differently from an application downloaded with a browser? I don't know. Maybe the big problem is that WebStart is mixing two different kind of things: applications that you download and install on your computer, and applets that run inside a web page (and can be launched automatically in a web page). Personally, I rather trust an app that I have downloaded from a trusted source, but I will not necessarily trust an applet on a web page. Maybe the answer to that is to definitely separate these 2 models?

What I know for sure is that most of our clients don't know and don't care whether it's WebStart or not, whether it's signed or not. They want an app to run, as long as they cab be sure sure that the code is coming from the supplier they trust, that's well enough for them.

Someone concluded in the very long and heated thread on the apple java-dev list that the WebStart dialog could be written like this:

"I believe any security question can be resolved with a simple dialog containing only two buttons." [Agree] [Deny]

Or maybe:
"I have come to the sad realization that no effective security decisions can be made with this dialog." [Agree] [Deny]"

I think this is a lot closer to the user's reality than what we have today with java 6u19/20!

Liezel Jane Jandayan replied on Thu, 2011/08/11 - 6:21am

The problem for Java Webstart is, I think, that Java Webstart can not inherit the security from the browser like applet. In other words, if I have already signed in to a page, then I click a link to launch JWS, JWS need another sign.

 Senior Healthcare Consultants

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.