Jim Seach wrote:
>
> --- Christopher Cain <[EMAIL PROTECTED]> wrote:
> >
> > In short, it is currently a needless exposure, and
> > certs are much more
> > important than most other resources. If I paid good
> > money for a real
> > cert signed by a CA, I would especially have a
> > comprehensive security
> > scheme in place to protect it. Leaving the password
> > sitting around would
> > be about the last thing I would possibly do. If your
> > box is compromised,
> > then your cert store is also unquestionably
> > compromised. If your store
> > is compromised, than every cert and private key in
> > that store is
> > worthless. That could potentially be catastrophic in
> > a business
> > environment, and would leave you open to all kinds
> > nasty things. If
> > someone gets ahold of your cert, bad, bad, BAD
> > things can happen. Just
> > ask Microsoft =)
> >
> > And if you should be cracked, and someone
> > masqaurades as you to do bad
> > things, that is a lawsuit you will not win because
> > you did not have take
> > resonable precautions against it. I realize that
> > this is all a bit of
> > Chicken Little-ism, but my point is that SSL
> > implementation is a serious
> > business. And I can choose to lock down the rest of
> > the stuff you
> > mention with a custom solution. I have no such
> > option with the SSL
> > implemention (short of hacking the code, which we
> > can't reasonably
> > expect people to have to do).
> >
>
> One of the possible custom solutons is to encrypt the
> other information with your public key, then use the
> private key to decrypt the other sensitive
> information. Since the info is signed with the public
> key, any developer could encrypt information that
> could only be retrieved by the system. That way, the
> solution would scale.
The system would still have to have access to the private key, which
would have to be protected with some kind of PBE scheme, in which case
you are right back to specifying a password in the config files.
Aside from that, it's not really a "custom" solution in the sense that I
can implement it without hacking Tomcat. Any possible solution to not
storing the password in the clear will require a custom build of Tomcat,
which is really one of my points. One can work around the other security
issues without resorting to that. I am going to have to hack a more
secure solution into Tomcat at this point regardless. My hope is that we
can come to some kind of consensus on the best way to lock the SSL
keystore down so that I can contribute the code back to the product.
IMHO, the current solution is a rather big hole waiting to be exploited
and needs addressing anywy, at least in a business production
environment.
> Anyway, if you implement the "prompt for key on
> reboot" it could always be a configurable option, so
> if someone didn't feel that level of security was
> necessary, they wouldn't have to use it.
Excellent idea! Configurable is good =) I wouldn't mind at all adding
that in during my rework, assuming everyone agrees that it makes sense
(and that my basic patches are accepted anyway, of course :-)
- Christopher
