"Craig R. McClanahan" wrote:
>
> Christopher,
>
> I can sympathize with your concerns, and would always set up production
> systems running under a username no one has access to (so they cannot read
> server.xml etc. anyway).
Definitely. But if the box is compromised, you're screwed.
> My question is, though, where do you stop? Is the password to your
> certificates file really any more sensitive than the username/password for
> logging on to your database?
Depends on what you have in your database, but potentially ...
definitely. On the system I am currently setting up, definitely. I'm not
storing any truly sensitive data such as credit card info or social
security numbers or anything like that. I suppose some of it is mildy
sensitive, but nothing earth-shattering. In any case, I would personally
*never* store database passwords in the clear either, but that's just
me. To address the question in general, I would argue that with database
access, I at least have the option of locking it down (I store my JDBC
info myself). My hands are tied with the current cert design.
> Or the login information for the directory
> server containing your users and roles (assuming use of JNDIRealm)? Or
> all the other sensitive configuration information that needs to be passed
> on to web apps (or web containers) to make them work?
Don't know about the realm stuff, because I haven't played with it yet.
I can't think of any other truly sensitive external resource information
that is exposed. In my opinion, when dealing with security, always err
on the side of caution. I should not have to weaken my security design
just to run Tomcat. If I owned a business, this would definitely be a
deal-breaker for me. Allowing my admins to store the master cert
password in the clear would be out of the question. Sure, I could always
run Apache in from of Tomcat, but now you're talking a much larger
footprint, so there goes embedding + SSL.
For another example, we are about to begin development on a cluster
management tool which our customer can distribute with their cluster
hardware solutions. It needs to be web-based, and it needs to be secure
(for obvious reasons). There is no static content, so there is no need
to bundle Apache with it. Tomcat standalone will be a much smaller
footprint and MUCH easier for customers to install and configure (no
Apache connector to worry about, and only one program to configure and
administer). Now especially if the customer wants an official cert, or
if they already have one, I can't very well tell them that they have to
store the "master key" in plaintext.
> It's just not clear to me that a "prompt the user at startup
> time" approach is scalable to cover all the sensitive information you
> might wish to protect.
Again, I consider the site cert to be MUCH more sensitive than almost
anything else. The possible exception is the database, in which case if
you store the password in the clear on that, too, you're crazy. If I'm
storing credit card info in my database, and the password to that
database is sitting in a widely-known config file, I'm just begging for
trouble. In fact, the Visa merchant agreement for online sales is rather
strict. I know for a fact that you cannot store passwords to a resource
containing credit card numbers (i.e. a database) in the clear ANYWHERE.
That same agreement also mandates SSL for transmission of card data, and
I'm reasonably certain that exposing your cert like that is explicitly
prohibited (I'd have to check to be positive). This is relevant because
I *have* developed an e-commerce solution running on Tomcat (although in
that instance Apache was sitting in front). In other words, you are also
prohibiting the use of standalone TC for e-commerce.
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).
> Craig
>
> PS: I'll also work on why the attributes don't work for you -- they did
> for me when this was originally coded, and I cannot recall any changes
> that should have made them stop.
Thanks! =)
I'd be happy to have a look at it instead, if you have some more
pressing things to attend to. I realize that it's not exactly a
high-profile use case.
- Christopher
