[cap-talk] securing capability communication channels, Waterken

[Tyler Close]

Hi John,

On 12/11/05, John Carlson <john.carlson3 at sbcglobal.net> wrote:
>  I was concerned about this when looking at the Waterken server product.  It
> is delivered with an
>  unprotected key pair, so if you don't regenerate your server keys, your
> communication is not secure.

This key pair is provided just to get you up and running, so that you
can read the documentation and play with the software. Since the key
pair is for the "localhost" domain, there's little threat of someone
mistakenly hosting a production application with it: the clients would
fail with a domain name mismatch.

>  I guess I should figure out how to generate my own key pair, but I am not
> so concerned about my
>  YURLs being hidden yet.  Perhaps this should be stated somewhere on the
> Waterken site, with
>  instructions on how to generate your own key pair?

The 3.3 release will have more documentation on this. For now, the
keytool command you need is:

keytool -keystore keys.jks -storepass nopass -genkey -keyalg rsa

>  I am also concerned
> that I have to put the server
>  certificate in my main Java CA certificates file to get clientside SSL
> working (as well as my local
>  client certificate), but i guess that's the price of doing business.

Eeeks.. I suppose that's one way to get things working. Realistically,
you'll need a CA signed certificate for your production application.
For development work, you could just use HTTP URLs, and layer on the
SSL later. There are no coding changes required to make the switch
from HTTP to HTTPS.

> Should I be using httpsy: in my client side code?

It depends on what you're doing. Are you making an application where
you get to control both the client and server side code? If so, then
yes, using httpsy is a good solution. Otherwise, you're stuck with
normal https:, and all the costs that entails.

I'm hopeful that I'll be able to get something done with the https
domain name cludge discussed a few weeks back on cap-talk, but that
will be a while yet. I think I will be able to implement a Firefox
extension that does the hash check, instead of using a CA. Until then,
we're stuck with the standard CA stuff.

>  So unless someone tells me differently, we still have the same problem with
> client side security
>  we have always had, that was solved by Web browsers, hence unless we can
> come up with
>  an easy to deploy client side solution, Waterken will be relegated to
> serverside coding, or
>  server to server coding.  Can we somehow use the OpenSSH/Putty key  files
> for the client
>  side keys?  That would make things easier.  No normal user want to run
> keytool to generate
>  their keys...we need something simple.

I think there's some confusion here. Clients don't need a key pair.
Only servers need a key pair.

>  Let me know where I have misstepped, I am known to do that.  I probably
> have misstepped, but
>  I need clarifying instructions on how to set up a properly configured
> environment.

The problems you're running into are the ones faced whenever using
HTTPS software. If you want to use standard client software to connect
to your server, you need to get a CA signed key pair. If you're just
doing development work, using a browser for client software, it is
easy enough to click through the warning dialog about a self-signed
certificate; however, as you're finding out, it's not easy when using
a client with no GUI warning dialogs. You could do your development
work using plain http: URLs. Your application is also accessible from
http://localhost/ URLs. There are no code changes required to switch
to using https: for the production application.

Tyler

--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=957