[Clockwork-developers] More on security

[Joel L. <jo...@lo...>]

I have a few more ideas about security and want to float them past everyone.
I also have some more thoughts on a couple of other topics, but I'll leave
them to separate emails.

Currently, the plan for security calls for all conversations to be encrypted.
Shawn suggested the Rijndael cipher, which was selected to be the new AES
standard.

We'd use public key cryptography to let each end of the connection verify
the other end and securely exchange a Rijndael key to use for the rest of
the conversation (because public key ciphers are too slow for bulk
encryption).

After doing some more reading, I've learned that this is essentially SSL.
In addition, the SSL specification also includes cipher negotiation, so the
two ends can list the ciphers they support and choose the best mutually
available one. Java has support for SSL built-in (to Java 1.4, that is).

In most HTTP-over-SSL applications (like secure web sites), the client
checks the server's identity, but the server doesn't check the client's (at
the SSL layer). But SSL does have support for both ends verifying the other --
that's just not used as much. We'd need to do that.

The upside of using SSL is that we don't have to roll our own code for
exchanging keys, checking identities, and negotiating ciphers. Also, the
issue of changing the client/server keys I touched on a while back (without
giving an easy solution) gets easier, since Java has a concept of a keystore
and certificate store that we could easily add more keys to and later (when
the old keys should no longer be accepted) remove keys from.

The down side? It looks like the SSL support is restricted to only use
certain ciphers: RC4, DES, and Triple-DES (these are the symmetric algorithms,
I didn't list the public key algorithms). At least that's what the built-in
SSL provider from Sun supports. I'll have to dig around some more and see
if another provider is available, or if you can just plug in a cipher.

-- 
Joel