I have only a limited understanding of security basics and things like digital signatures. I understand, for example, how digital signatures are useful in public key cryptography. I do not, however, understand why signing my JNLP is necessary, or what maliciousness it prevents against, nor can I find this info readily available.
I have found that deploying unsigned JNLP's is allowed, but things like disk and network access are restricted. However, let's assume I am a malicious person who makes a Java application that will do something malicious to the content of your disk (and I disguise it as something else). I can easily sign this, deploy it, and you can come to my website, unsuspecting, and launch the app and have your disk attacked. In a case like this... what did the signature accomplish?
More to the point... if anyone can simply sign an application with hardly any effort required... then what's the point?
I'm sure I'm missing something painfully obvious... please enlighten me.
You cannot just sign something - not if you want the browser to execute it without restrictions. The certificate that you use to sign your software must be signed using another certificate, and so on, until the chain of trust reaches a root certificate that has been installed in your browser.
While there have been a few less than diligent Certificate Authorities occasionally, you cannot generally get such a certificate without providing some proof of your (network) identity. That means that malicious people have to provide some sort of identification, little as it may be. Even more important, CAs are expected to revoke certificates that have been used for malicious activities, or otherwise compromised, thus limiting the extent of the exposure.
To get to your point, if you use a CA-signed certificate in your site and that certificate is used to distribute malicious software, the CA will revoke your certificate sooner rather than later. If, on the other hand, you use a self-signed certificate, the browser will ask the user to confirm its use. If the user goes through with it despite the warning, well, it's their own fault, ain't it? There is no general countermeasure to either stupidity or ignorance, after all...
This question does raise some valid points and thkala provided a good defense for the value of CAs that are issued from a trusted authority.
But why do we need a CA for a JNLP and not for a regular execuatbale JAR file? I think the reason is that JNLP is meant to be launched from a browser. JNLP files are a replacement for applets that run withing the browser in a sandbox - theoretically secured away from doing any harm on your computer. A user may launch a jar file running in an applet simply by visiting a page. Likewise, a JNLP may be launched by simply clicking a button. In Chrome I get asked to first save the JNLP. But in IE or Firefox, I see a launch button or regular web link - it looks like any other button or link in a web page - and with a click the program runs. This is a bit more seemless than downloading an executable and then running it.
On the other hand, an executable JAR file can be installed or just run a number of ways. For instance, they are often packaged on CDs along with MRIs since some MRI viewing software runs on the JVM and the patient or doctor needs to launch the custom software to view the MRI. But this software doesn't get "installed." You simply run it from the CD.
A JNLP on the other hand can work more like an installer than a stand alone program. I've been able to get them to create desktop shortcuts and do file associations. From the users perspective, my JNLP app feels like a native program with it's own icon and file type. Since it runs so seemelessly from the browser and has unfettered access to the client PC, having it "signed and trusted" can make users feel more secure in running this.
Historically, I believe this is why JNLP and applets get signed. I believe the practical value of this signing has expired.
First of all, signing your app from a CA costs hundreds of dollars so many companies skip this. There are some cooperate apps that run self-signed code and the users just know to click the "accept" button after the browser gives the warning.
More importantly, the recent security updates for Java have centered around patching back doors that allow unsigned code to get out of the sandbox and do everything that a signed applet or JNLP can do. It seems that every time Oracle patches a way out of the sandbox, someone finds a different way out. The best solution is to have the runtime always prompt the user for permission to run a Java applet or JNLP file. Not only can a self-signed JNLP file gain access to the local file system and the LAN, but an unsigned JNLP can as well. If the user has the very latest security update from Oracle (of course, most do not) and before the next clever way to slip out of the sandbox is discovered, then the sandbox model is really working as intended. But for most users, most of the time, the sanbox model has not been working as intended. I think it's time for all JNLP files to ask for permission to run and just given them all the same access that a regular JAR file has.
Then I won't have to re-create my security certificate every 6 months.
Related
I have been trying to create a self-signed jar. I have embedded it on a website. However (this may be a Windows-specific problem), when the applet loads, this pops up:
"Your security settings have blocked a self-signed application from running."
According to every scrap of documentation I can get my hands on, I am supposed to be prompted as to whether or not I want to trust this application.
This is embedded in GameJolt's website, so there is no HTML code to be posted.
My META-INF folder contains a .MF, .SF, and .DSA file.
Do I need anything else?
According to every scrap of documentation I can get my hands on, I am supposed to be prompted as to whether or not I want to trust this application.
You must be getting old scraps. In recent times, Oracle decided to raise the security level so self-signed apps. were no longer acceptable.
I have a small company with website, that I'd like to make more interesting by adding there applet. I've prepared it already, and when launched from eclipse it works correctly. However when it is launched as an applet, from website I have a warning that it is not trusted and cannot run it without adding my page to java exceptions.
And here the fun begins. I'd like to have my applet signed in order to allow customers use it without any changes in their java configuration. I'm not planning to make more applets, or any other code that would need signing, so I don't really need to buy expensive certificates.
I've tried self-signing, however according to Java 7 policies it is not enough to run an applet.
I've also wanted to obtain free OpenSource Code certificate from Certum.eu, however the link doesn't work anymore.
CACert is also not an option, as I've heard that it is not trusted in all browsers...
Is there any way I could sign my applet with no harm to my wallet?
The closest thing to an open source certificate is CACert which is however not supported in all browsers. Thawte and Certum seem to have stopped offering free certificates for open source projects. (If you really want to know write an email to Certum why the link is dead)
The only thing I know of currently is GlobalSign.
I've been looking into using Jar Bundler to create a .app from my .jar and I read that you should sign the code using a Developer ID certificate before bundling the application. However, I am not a member of the Mac Developer Program and cannot afford to be for now.
So how will not signing the Java application change the end-users experience, if at all? How badly do I need to find an alternative solution, if available?
well unsigned java is worse than unsigned cocoa from a usability standpoint, because you don't have access to the file system.
if you have a native cocoa app bundle you get different security warnings and safeguards depending on the end user's settings, but with java I am pretty sure unsigned means basically no Disk or network IO
It depends on their Security preferences. If a user has their "Allow applications downloaded from" security preference set to "Mac App Store and identified developers", then by default they will not be able to run your app (but see options below). This restriction has nothing to do with Java and would apply similarly to an unsigned Cocoa app.
If they changed the setting to "Anywhere", then they'd be able to run your app.
Another option is to tell your users to Control-click or right-click the app, then select Open. This will give them the option to bypass the default security setting for this app only. Once they run it, they won't get the warnings again.
Certainly the smoothest route is to sign your app, but I don't think unsigned apps are so uncommon either and you may find that many of your users are already educated to this procedure.
When i visit a java application running website I get error "application blocked by security settings" This is due to certificate problem. I know the publisher so i can trust him.
Then after a quick google search I changed security setting of java to medium and also added the website to Execption website list. Still I am getting a different window asking me to accept risk and continue running application(Shown in image below). This window comes every time i run it. So how it can be avoided?
For an application that was signed by a legitimate code signing certificate (that itself was signed by a proper certificate authority in Java's web of trust), you will still see the above dialog, but without the red text. It will display the name on the certificate, and you will have a checkbox that allows you to automatically trust all apps from the same vendor, thus avoiding seeing the dialog again.
However, when the application was not legitimately signed, you will see the above dialog even on medium setting, but you can run it by "accepting the risk". On default security level, you may not even have the option to "accept the risk" and proceed, and on "very high", you will definitely not have the option to proceed.
In order to avoid the dialog with the warning, the application will need to be signed. If it's signed by a legitimate code-singing certificate, it will behave as I described in the first paragraph. If it's self-signed, then the vendor will have to supply you with a copy of the root certificate they used to sign it, and you'll have to import the certificate into Java's store. Then, it will behave just like one that was legitimately signed.
I have a small applet hosted free of charge on my website. It doesn't desire any special permissions to access the user's computer and the code hasn't changed in 5 years.
In the past few months, I've been getting lots of emails from users complaining about security popups/warnings every time they use the applet. Most recently it appears that there's no way to "permanently allow this applet" anymore, and now warnings that say in the future unsigned applets won't be allowed to run at all.
I've tried self-signing the applet but the warning message is even scarier, stating that the applet will now have unrestricted access to the user's computer. I set the self-signed applet to run in the sandbox but the warning is still scarier than the unsigned applet warning, even though it runs with the same permissions.
What options do we have? I've been thinking about porting it to a different language, such as flash or HTML5. Are those any better? Is there any hope of Oracle backing off and letting unsigned applets live in peace again?
The warning is presented by the browser. Executing Java is disabled in Chrome for security reasons.
Mozilla Firefox
Chrome
Applets needs to be signed. You can use self-signed certificates. Yes once you sign, your applet has privileged access on user's computer to store and even delete files. However the user will have to click on "I Trust" for the applet to run. Self-signed certificate they can add it in their keystore of browser so that next time it will not pop up the warning. However I suggest that you buy code signing certificate from Digicert, Verisign etc so that your website looks professional. Since this is 5 years old code you need to describe to us what the applet code does so that we can think of alternative ways of implementation using different technology.