I am new to certification in java.Just on another post just now,I found out that it is not possible to use jarsigner on java apps,its only used for applets.Could anyone confirm this?
Next I would like to know,what is the common way people developers give thier apps to the clients,I mean do they not put any certificate for it?I mean a year or six months certificate.
This I am talking is with respect to a normal java app not an applet
UPDATE
This is what I tried:I jarsigned my app yesterday and gave the validity of 1 day,today when I saw it never got expired.So thats why I was wondering if it is only for applets?
If you have a trusted way of delivering your jars to your client, you do not need to sign it. A "normal" Java program also does not do anything different for a signed jar.
However there is a difference if you use some other way of distributing your application. You already mentioned applets. The user cannot really be sure who is offering the application. By signing it, you can ensure it is comming from the trusted guy (you).
Another big usecase for this is Java Webstart. If you want to distribute your application with that tool (a good idea), you need to sign the Jar files if your application wants to have some extra permissions (like accessing files, network IO, stuff like that). If the user then trusts those certificates, the application is started.
As for the duration: Usually those applications are signed with rather long validity (> 2 years), usually longer than the applications supposed lifetime.
Related
I have a old projects developed by java and that old project made by Jdk 1.4 version.
This is single application java program.
Currently server and database configuration is written by .ini file.
but That is not really good for security because everybody can see this file physically.
Do you guys have any way to hide perfectly instead of using .ini file.
I think this is two way.
1. Make properties class in side of project and make .jar files.
- I can make .jar file but also I can decode it.
2. Separate Back-End server and communicate.
- This way I have to fix too many source code. So I am not sure it's good or not.
- Also what is this concept for specific we are calling in Java environment?
And anything else please suggest to me
Thank you!
The least protection you can provide to your configuration file is encrypting it.
Make properties class [inside] of project and make .jar files.
As I pointed out in the comments, you should never place sensitive data in compiled files. For one, it makes your design quite unflexible: If you decided to change your server password, for instance, you would also have to change your compiled files. As a second and more important reason, saving configuration data in compiled code is insecure; especially for Java, there are decompilers out there which can be used to decompile and thus retrieve the sensitive data.
Separate Back-End server and communicate.
I do not understand what is meant by this so I will not comment on it.
A means to secure your files is encrypting them; this is the least layer of protection though. When you login to your server sent the encrypted password to your server and the server, knowing the encryption key, will be able to decrypt the password and check whether the password is valid. While the last part may seem to be obvious, I insist on communicating that to you.
However, you should not rely on encryption solely. Furthermore, if the information you are protecting is not client specific, such as their login credentials, you should not store it on the clients computer in the first place; anything can happen on the clients computer - the client may even be the one trying to crack the your sensitive data. If you do not have to, do not store it on a computer you do not have control over. I do not know you circumstances, so there are hardly specific answers I (and the community) could provide.
I hope this answer helped you
I have been developing a static program analyzer (a kind of tool that attempts to detect program errors at compile-time), and it is almost finished. I would like to put a demo version to the web so that the few people who may be interested into the tool can test out its functionalities.
Context:
1. I have a personal computer to be used as a server if necessary. Otherwise, I am not sure if it is technically possible to put the demo to the computers of my institute because their computers do not have the required library used to launch the demo.
I am using Eclipse and Maven to develop this analyzer. The analyzer is written in Java.
The analyzer is somewhat time-consuming. It takes, for example, 5 seconds and 500 Mo JVM virtual memory to do an interesting work. So I need to limit the number of accessors.
I do not plan to send the .jar files to the clients, because I don't know who they will be.
I know nothing about the web application.
Under this context, what is, in your opinion, the easiest way to demonstrate my analyzer on the web?
This may be a different question from most questions about how to convert a desktop program to a Java web application, such as this
Thank you.
[EDITED] What would be the best solution if the constraint 3 above is to be taken into account?
You may be looking for Java Web Start, a deployment option used by the popular analyzer, FindBugs. This example illustrates few key concepts and leverages minimal-cost hosting.
Addendum: #Capn Sparrow helpfully comments that Java Web Start downloads copies of the program's JARs from the server to the client, violating requirement three in the question. This entails several risk/benefit tradeoffs:
Pro: The server can be easily updated to ensure that the client always has the latest version. JARs are cached on the client, minimizing latency on update.
Con: The cached JARs may be decompiled or tampered with. The user must accept whatever <security> setting is chosen or reject the application. Using jarsigner can mitigate some risks.
I was hoping to do this from a flash plugin, kind of how flash accesses the microphone or webcam but it doesn't seem possible.
Is this going to be possible using Java, or ActiveX, or some other strategy that I haven't looked at yet?
The idea is to do it without a client install, or at least something lightweight and browser and platform independent, (and possibly the moon on a stick as welll ;-))
Your only real hope is ActiveX, both Flash and Java applets run in a security sand box that prevents access to resources like scanners. All you need for ActiveX controls is for it to be signed by a trusted CA and you get full access to the local machine so in theory you can do what ever you want. ActiveX is of course not browser or platform independent, so it might not be a suitable choice.
You may get some milage with Java webstart or .NET's click once deployment, both are like an easy local install that'll keep it's self up to date, there a good half way house, but aren't hosted in the browser.
Sorry I can't be more helpful, good luck
Why should I sign my JAR files?
I know that I need to sign my client-side JAR files (containing Applets) so that special things like filesystem access can be done, and so that the annoying bit at the bottom of windows doesn't show, but why else? And do I need to sign my server-side JAR files containing Servlets, etc.?
Some basic rules for when and when not to sign JARs would be appreciated - thanks!
The short answer - don't, unless your company policy forces you to.
The long answer
Signing jars is effectively telling your customer "I made this, and I guarantee it won't mess up your system. If it does, come to me for retribution". This is why signed jars in client-side solution deployed from remote servers (applets / webstart) enjoy higher privileges than non-signed solutions do.
On server-side solutions, where you don't have to to placate the JVM security demands, this guarantee is only for your customer peace of mind.
The bad thing about signed jars is that they load slower than unsigned jars. How much slower? it's CPU-bound, but I've noticed more than a 100% increase in loading time. Also, patches are harder (you have to re-sign the jar), class-patches are impossible (all classes in a single package must have the same signature source) and splitting jars becomes a chore. Not to mention your build process is longer, and that proper certificates cost money (self-signed is next to useless).
So, unless your company policy forces you to, don't sign jars on the server side, and keep common jars in signed and non-signed versions (signed go to the client-side deployment, non-signed go to server-side codebase).
Signing a jar file, just like using certificates in other contexts, is done so that people using it know where it came from. People may trust that Chris Carruthers isn't going to write malicious code, and so they're willing to allow your applet access to their file system. The signature gives them some guarantee that the jar really was created by you, and not by an impostor or someone they don't trust.
In the case of server-side or library jars, there's usually no need to provide that kind of guarantee to anybody. If it's your server, then you know what jars you're using and where they came from, and you probably trust your own code not to be malicious.
A good reason could be if you never wanted anybody to be able to sneak in modfied classes to be called by your code.
Unfortunately that includes yourself :-D So this is only to be done if you really need it. Check the "sealed jar" concept.
In terms of applets: From 6u10, the Sun JRE replace the warning banner with less obtrusive (from 6u12, IIRC) warning triangle (necessary to support shaped and transparent windows). 6u10 also allows controlled file access through the JNLP services API.
The principle of least privilege says that you should not sign the classes of your jar files. Security is not necessarily easy.
Simply showing a certificate dialog box should not be construed to mean that the entire contents of a web page is to be trusted.
What are the security implications for hosting signed jars on the internet?
As I understand jar signing, once a user choose to auto-accept a certificate, it doesn't matter if the signed jar came from your domain, linked from another domain or hosted on another domain. For example, Sun uses this method to give applets OpenGL support, by providing (hosted) signed jar that link to the driver. So are there any precautions I should make as the developer and certificate-signer of the java-code I make available?
Depending on the context, you are relying on the security manager and associated security policy to do the right thing. Generally unless you are doing your own classloader magic, you shouldn't need to do anything special. If you have control of the security policy, (for example in a java application rather than applet) you can grant permissions to call your jars only to certain other code. If you rely on codebase to distinguish code, a https URL is better. It is also no harm to limit access to the jars on the webserver if you know where/who the accesses should be coming from, but is probably more trouble than it is worth.
However, you should always bear in mind that the caller of your API may not be your code, and may be malicious. So in your threat modelling, you should think about what a malicious user may be able to do if they somehow had access to the functionality given by the API your code exposes. The security manager is supposed to check up the call stack to prevent this kind of thing. But if for example your signed jar has a method LaunchMissiles() ...you might want to ask the user if they are sure anyway. And you might want to authenticate the user too.
Nor should you necessarily rely on the user to click the right button on any security warning, especially if it refers to certificates and URLS etc - most users fall into one of two categories: those who click OK on any warning because they don't understand it, and those who click Cancel on any warning because they don't understand it.