Jim Seach wrote:
>
> --- Christopher Cain <[EMAIL PROTECTED]> wrote:
> >
> >
> > 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.
>
> I agree, this could be done now, since the keystore password is in the
> config file, but my assumption was that it is not worth going through
> the additional effort to secure the other information unless your
> proposal were implemented.
Oh ... you mean securing the JDBC and Realm stuff? I wholeheartedly
agree that leaving your certs/private keys hanging in the breeze is the
single biggest resource security problem at the moment (of the ones that
you as an admin have no control over). Again, I haven't looked at the
Realm stuff and what-not, but I can't imagine the possible risk being
nearly as devestating. I'm not trying to toot my own horn or talk about
how great I am, but security/crypto is my area of expertise, so really
hope I am believed when I say that having your certs so easily
accessible is an absolute disaster waiting to happen ... much more so
than any of the other system resource stuff.
As to your point, I would agree that if one is not worried about the
security of their certs, they are probably not too worried about the
rest. If you're going to address overall resource security, the certs
are unquestionably the place to start, IMO. I see it as a problem which
requires immediate addressing. Since I secure my own database access
stuff, and I don't use realms or LDAP or any other stuff like that, I
can't really speak to the relative risk there.
> At that point, it might be worth it to develop a standard (carefully
> designed) way to store other information in order to get around Craig's
> scalability concerns.
I think that makes sense. It would be nice to have a well-designed
"External Resource Security" module that could be seemlessly plugged in
and handle all of it from a single point. And I this would make Costin
proud, but if possible I would to do such a thing in the commons so that
multiple contains could benefit from it. I'd have to sit down and
examine the feasibility of such a thing of course, WRT any security
functionality that we would be foregoing by maintaining JDK 1.1
compatibility, but it's a nice idea (at least in my opinion ... I'm not
sure what the general sentiment is). I would even be willing to
spearhead such a thing. I know, I know, I've also agreed to help out
with any Jikes API project, but I didn't necessarily agree to SPEARHEAD
that :-)
In any event, I would still like to see the (at least configurable)
"prompt me" approach in the CVS tree ASAP for two reasons. First, I
think it would be nice to get the option out there for the more
security-sensitive standalone installs immediately. Second, even with a
centralized external security solution, we are still going to have to
get around the "initial authentication" problem anyway, and I really
can't see a better method than command-line prompt (unless I am missing
something). There's just no killer way around not storing passwords in
the clear. Once I have this inital keystore issue resolved (on my end at
the very least :-), I'd be more than happy to call for a vote on a
centralized solution, at which point we could weigh using my existing
prompt solution for initial authentication.
- Christopher
