AppletTalk.com

Ted Byers · Guest

OK, here is what I want to do. I want to create an applet, sign it, and
then, when it needs to do so, use the certificate it was signed with to
authenticate itself with the server. This is to ensure that the applet has
not been modified between the server and client. And of course, the server
has to authenticate itself with the applet, so that it can not be
impersonated. After this, all communication between the applet and server
needs to happen using SSL/TLS. User authentication is a different issue. I
want to be sure that when my applet connects with my server, it is using
code I wrote, not something someone else has used to modify my applet, and I
want to ensure that my server is not impersonated.

First, is there an easier, or better, way to acheive what I want to do.

Second, how do I tell the applet that it needs to authenticate itself with
the server. Is it sufficent to simply use an SSL socket or HTTPSConnection?
How do I tell the applet to a) always trust the certificate I'll be creating
using the java SDK (since I trust myself, and it is my code I want to
trust), and b) use the unlimited strength security policy I have on my
machines, regardless of where the client machine is or what security policy
files the client normally uses. Can a keystore and security policy file be
embedded within a signed jar file, and then used by the applet to
authenticate itself, either for itself (it would be good if the applet dies
giving a suitable message to the user if it can determine whether or not it
has been modified) or for the server? Is simply using the keyword "final"
for the applet class sufficient to ensure the applet class has not been
modified? I don't see how it could be, especially if the bytecoede can be
modified.

Can I use a single certificate for all the servers I use (MySQL, Postgres,
Apache, Tomcat, Sun's application server, &c)?

Ancillary requirements mandate use of an applet since I need a GUI rather
better than that which a web browser can provide a servlet. The application
will also require use of several servlet and and java server pages. Since
the data is sensitive, I have to do evrything possible to ensure the
confidentiality and integrity of the data.

BTW: is there anything on the web, that can safely be accessed, that
provides something like a catalog of possible attacks and well established
best practices for dealing with them? Is there anything like a catalog of
trustworthy open source software that a developer can use to attack his own
code to test for vulnerability?

Thanks,

Ted

--
R.E. (Ted) Byers, Ph.D., Ed.D.
R & D Decision Support Solutions
http://www.randddecisionsupportsolutions.com/
Healthy Living Through Informed Decision Making

sgoo · Guest

your case is so complicated and i'm not sure if i catch all the points.
however, at the very beginning, in order for your signed applet be
launched by the end-user, the signer certificate should be trusted by
the user's JRE. if that certificate is not signed by a well-known CA,
you need to explicitly tell the user to manually "trust" your
certificate.

next, in order to make sure the server is the right one, your client
can use the server's certificate in its TrustManager for JSSE. since
you already have that certificate, you can hardcode it in your client
in a byte[] and feed it to
CertificateFactory.generateCertificate(InputStream) with a
ByteArrayInputStream.

third, i've no idea how to let the server determine if it's
communicating with the correct client, since if you want to use
client-side authentication of SSL here, you need to provide the private
key with the client. this is surely something you'll definitely don't
want to do. in fact, once the applet is out there on the user's
machine, anyone will have a chance to learn all the protocol details
and create his/her own client.

hope this helps,
speedo

Ted Byers · Guest

Thaqnks speedo.

Question, you say I can hardcode my server's certificate in the applet. How
exactly do I do that? Do I include the certificate in the jar file, and
read it from there? Since this is the same certificate that is used to sign
the jar file, can it be used to verify the applet has not been modified? If
so, how? It doesn't seem very secure since presumably the embedded
certificate could be used to sign a modified version of the applet. In
other words, wouldn't a cracker be able to extract the certificate and use
it for whatever evil purpose he wants?

Perhaps a different approach.

What attacks is the following vulnerable to, and how do I defend against
them?

1) User using his web browser uses https to open my login page and logs in.

2) If the login is successful, the user gets to a welcome page, again using
https, and this has a link to a page containing my applet and the protocol
used is https. On the server side, this page is generated by a servlet, and
there will be an item in web.xml forcing all access to this page to be
through https.

2a) I assume the applet itself will be sent to the client browser over an
SSL/TLS socket. I also assume that the applet is signed, so the browser
will not run it if it has been modified in transit in an attempted man in
the middle attack.

Question: I see, in the Postgres documentation, I can use OpenSSL to create
self signed certificates, and that I can place such a certificate into a
file called "root.crt" into the data directory. It says that when this is
done, the server will request a client certificate. If the attempt to
connect is from an applet, where will it get this certificate? Can it use
the certificate that was used to sign it? I will, of course, be using JDBC
to connect to the server (whether from a servlet or an applet). Where, in
JDBC, do I look for instructions on how to use it to make a connection to
the server using https (i.e. what class and what function do I use)?

Is there a way to ensure that the jar file containing the applet is neither
cached nor modified on the client machine?

Question: Can an applet create a digest of the jar file in which it was
sent to the client browser, and then send that digest to the server for
comparison with the digest of the jar file as it exists on the server? And
can the browser be prohibited from caching the jar file containing the
applet? Would that enable the server to ensure that the applet had not been
modified either on the client machine or between the client and server?

I am torn between having the client interact with a database through a
servlet or directly with the database running on the same machine as the
application server. I am also torn between using an applet or an
application launched using webstart (again having both configured so they're
not cached on the client machine). In either case, the applet/application
is very small, so sending them over the network will not impose a
significant wait time. Regardless of whether I use an applet or
application, it will not need to access the client hardware, and can quite
happily function within the original sandbox security model to which Java
applets were originally confined. I neither need nor want access to the
clients' hardware!

Is it not a significant hole in java security if I can not verify, from my
server, that the applet or application trying to connect to my server is in
fact the same code I signed?

Thanks,

Ted

--
R.E. (Ted) Byers, Ph.D., Ed.D.
R & D Decision Support Solutions
http://www.randddecisionsupportsolutions.com/
Healthy Living Through Informed Decision Making

Mike Amling · Guest

Ted Byers wrote: