Out-of-the-box SSL in Java Applet

Question

I'm currently attempting to implement having a (signed) applet communicate to a server program via SSL. I have found the right kind of incantations to create key stores for the client, the client's trust manager, and the server. This allows me to create compatible SSL contexts on the client and the server.

However, as it stands, this setup would require an admin to create the key stores and then distribute them to the client and server machines. I would like to avoid having to make people configure the system.

So as a fallback, is it possible to generate a client-side key automatically and use a "lobotomised" trust manager to create compatible SSL contexts without any configuration?

Answer 1

If it's your well-known server that you're communicating with, and SSL is causing you headaches in one way or another, then you might also consider the option of just ditching SSL.

SSL is really designed to solve the problem of talking to an "unknown" server, hence the complications of certificates and protocol negotiation. If the problem you're trying to solve is just sending some encrypted data to a known server, then you can always generate an RSA key pair, stick the public key in a file in the jar, and use the boring old cryptography API to send and interpret your data. Just a thought...!

Update: I should have mentioned, that I'm assuming in the first place that you have a trusted means of installing the software on your clients. A commenter has rightly pointed out that if this isn't the case, then distributing the public key this way is subject to a man-in-the-middle attack (whereby the MITM gives you a doctored jar with the public key for THEIR eavesedropping server). I had assumed that this wasn't the thread model you were trying to protect against, and that clients were being given the jar from a trusted source (e.g. an engineer from the company installs the program on their system). If they're downloading the jar over the Internet, being sent it via e-mail etc, then you'd still want to sign the jar with a CA-issued certificate, even though within your actual code, you may use the public key you distributed in the jar to connect.