I have a Java applet which doesn't need any special privileges to run (i.e, it runs fine in the sandbox), but which expects the user to enter some sensitive information. Therefore, I'd like the user to be able to verify the origin of the applet.
I then signed the applet, and everything appears to be working correctly. The browser apparently accepts the signature; for test purposes, I tried executing PrivilegedActions and everything worked. However, the browser doesn't inform the user that the browser is signed - from user's perspective, both unsigned and signed versions of the applet appear exactly the same.
So my question is: is there a way to instruct the browser to present the signature authority to the user, or something similar?
Firstly, this is not a valid usage for signing a jar.
Did you at some point ever forget to untick the always trust tickbox?
Back to the first point because it is quite important. By signing a jar you are putting the certificates name to the claim that it is secure. Note that being secure is very much broader than being non-malicious. The security dialog which asks whether the user wants to give full local user access pops up if any code anywhere is encountered is signed. It doesn't mean that some particular set of pixels are from a trsuted source.
The correct approach is to use https.
Related
In the previous months I developed a sandbox Java applet for an academic project. I wasn't able to sign it with a trusted Certificate Authority because of the restricted budget.
With the release of Java 1.7.51 I found that the new security restrictions forbid the execution of the applet, because of the lack of signature.
Until now, I have found two rough solutions to this problem:
ask the user to include the applet page on his/her exception lists;
ask the user to set the Java security level to "Medium" (which, of course, is a risky manoeuvre).
Is there a way to overcome the restrictions imposed by Java with a self-signed applet without asking the user to change the security settings?
I would deeply thank you for your answers, since the option to buy a trusted certificate remains an expensive one.
Is there a way to overcome the restrictions imposed by Java with a self-signed applet without asking the user to change the security settings?
Short answer, no. Long answer, nope.
Its not a real solution but maybe a bit more convenient for the enduser:
Write a small programm (as jar file, or batch) which adds your site to the exception list. This tiny programm you offer to the user which can't execute your applet. It only has to be executed once. How this can be done is described here.
The file controlling the Exception Site List is stored in the user’s
deployment location as described in the deployment configuration. On
Windows 7 the location is
C:\Users\username\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites.
The format is one site per line.
If you think that is not really trustworthy to the user you are probably right ;-) who executes a file downloaded from the internet? You can also just add a small description to your page and a user could execute it from commandline. For windows it would like that:
mkdir %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security
echo http://www.carlos.com >> %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites
The more I read my post I think the best solution is the certificate but still wanted to share this option.
I want to prevent decompiling for my game client.
Is there a option I can some how protect the .jar file with .htaccess or any other method so the client (Browsing user, that loads the client via a applet) won't be able to get the file & decompile it.
I always wondered if there is a solution for this, is there? Maybe creating a crypt code, and whenever the server tries to get the client jar, it will send a crypt code via GET, if the crypt code matches, it will load the client from that page, I don't know, there should be a solution ?
Thanks!
For a browser to execute an applet, it needs to download the jar file containing the applet code. An if it downloads it, it's available for decompilation. To protect you against that, you can obfuscate the byte-code, or not use an applet at all, and simply use a traditional web application, where the code is at server-side, and the client only see HTML and JavaScript code.
No. You could stop the browser getting the file, but then it would be unable to run it.
Maybe creating a crypt code, and whenever the server tries to get the client jar, it will send a crypt code via GET, if the crypt code matches, it will load the client from that page,
The user could see the code and still get the file.
There is nothing you can do to prevent the user getting hold of the unencrypted bytecodes.
NOTHING.
The user's machine needs the applet's bytecodes in unencrypted form in order to execute them. Since a user (with sufficient knowledge) has totally control over what his machine does, you can assume that control will extend to allowing him / her to intercept the bytecodes at some point where they have been decrypted.
And if the user can intercept the applet's bytecodes, then he / she can change them to defeat any clever stuff you put into the code. And that includes changing the bytecodes to defeat any measure that you use to detect changes to the bytecodes.
"just make it so they have to use it in the browser then check if they are accessing it from our url" Could that work?
Nope. The user can modify the applet to remove that check.
"you could also make php create a session variable with a hash in and check if that hah is present and matches our hashing algorithm"
Nope. The user can modify the applet to remove that check too.
I don't know, there should be a solution ?
Unfortunately, there is no practical solution ... apart from running everything that needs protecting on the server side.
By the way, this problem is not unique to Java. Someone with the technical knowledge and the motivation can defeat any tamper protection measures in Javascript too, or even in native code plugins that you get the user to install (if he is foolish enough).
With the new release of OS X 10.8, the Gatekeeper will popup the following warning, when you try to start a signed Java applet:
The applet has been signed with a valid code signing certificate and will work correctly on other platforms as well as previous versions of OS X. If I change "Allow applications downloaded from:" to "Anywhere", it works correctly.
As far as I can figure out "The digital signature could not be verified", actually means something like "the signature has not been made with a Mac Developer ID".
So: Can I sign Java applets with a Mac Developer ID? Can I sign it with both a Mac Developer ID and a standard code signing certificate? Is there a better approach?
Here's the answer that I got from Apple Developer Technical Support:
Thank you for your patience while we investigated this.
The alert is presented by Java, not by Gatekeeper. However, you're
correct that the verification logic was changed on OS X Mountain Lion.
For a while now, users have been presented with this alert when
running a signed applet, because signed applets can escape the Java
sandbox and make unexpected changes to the user's system. Users have
the option to check the "Allow all applets from " box if
they trust the developer and thus they won't see the alert again
unless they remove the item from the Java Security preferences.
What's changed in Mountain Lion is that the verification alert now
basically means that the applet's signature is valid, but the applet
is from an unidentified developer and is trying to escalate privileges
when Gatekeeper is enabled and the user has to decide whether to allow
that.
"Unidentified developer" means a source other than the Mac App Store
or a Developer ID-identified developer. Note that Java applets cannot
participate in the Developer ID program.
If Gatekeeper is set to trust only Mac App Store apps, then you will
not be able to add the applet to the trusted list unless you add the
applet's certificate to the keychain using the sheet that appears
after clicking Show Details.
Unsigned applets are not allowed to escape the Java sandbox at all.
This is consistent with Gatekeeper's treatment of native Mac apps;
apps from unidentified developers are not allowed to run by default.
If you'd like to see the wording of the alert changed, please file a
bug report at https://developer.apple.com/bugreporter.
This basically means that there is no way to sign the applet in such a way that you can avoid this message to be shown. I filed a bug report to Apple saying that I want the wording of the message to be changed not to contain words like UNIDENTIFIED, UNVERIFIED, INSECURE... because that's the whole point of signing the applets, so that the users can feel all warm and cosy inside when they need to allow the applet to run, to assure them that what they are about to allow is OK and verified and it won't do any harm to their computer, and we need to show it on a place where it will be visible, to poke their eyes with it.
You answered your own question.
Gatekeeper considers that certificates / signatures not issued by Apple are not trusted.
Apple Documentation will tell you how to export your certificate. You can then use it as usual.
The codesign command may also do the trick.
I created a java applet that uploads a file to a server via ftp, it uses an external library by apache, I signed my applet but when I start the applet from the browser I get two security popups, how do I prevent to show or show only one? hello and thanks
this is the example link:
http://frx08.altervista.org/javaftp/
(the second popup says that the code contains signed and not signed code but I don't know why..)
Either:
Make sure all your code is unsigned, perhaps using javax.jnlp available to applets since 6u10. [best route]
Make sure absolutely all your code is signed (and this includes resource files).
The "Trusted-Library" feature allows a signed and trusted library to run with untrusted code. It can be very difficult to write the library securely.
I have developed an applet. But when my browser fetches it from the webserver it pops a security warring. I don't want this message to come. Meaning applet should run without the end users permession. How can I do that? Do I need to get my applet signed? If yes, from where can i get it signed? What's the cost of geting it signed?
Your description might relate to a number of problems, such as the code trying to do things which require trust. That does not sound like the case in this instance. If your unsigned code tried to do things that required trust, it would not prompt the user at start-up, but either prompt them when the trusted action is attempted (e.g. for cross site access in later JREs) or just fail with an AccessControlException or similar.
It could be that your applet uses multiple Jars and has run into the mixed code restrictions introduced in Java 1.6.0_20. But the symptoms do not sound quite right for that either.
Is your applet publicly available? What is the URL where I/we can visit it?
As an aside, if your applet tries to break out of the security sand-box, it must be trusted. That means the code must be digitally signed, and OK'd by the end user at the prompt. There is no way around it.
But it does not require a code signing certificate issued from a CA. You can roll your own code signing certificate using the tools of the SDK. I have a few small demos. of code projects that compile and build code before signing it.
You need to get yourself a code-signing certificate. Probably by some "well-known" CA if you want to avoid all warnings. The certificate itself costs money, but once you have it, you can use it to sign as many applets as you want (you do the signing yourself).