On 02/19/2012 06:03 AM, Mark Thomas wrote:
On 19/02/2012 09:25, Pae Choi wrote:
On 02/14/2012 09:32 AM, Caldarale, Charles R wrote:
From: Luca Marchesano [mailto:luca.marches...@ericsson.com]
Subject: Keystore password not masked in server.xml file
Is there a way to specify the keystore's password in encrypted way?
Think about it: where are you going to put the encryption key so
Tomcat can get at it to decode the encrypted password? Eventually,
something must be in plain text, accessible to Tomcat. Secure your
Tomcat configuration files so you don't have to worry about random
users looking at them.
- Chuck
The OP's inquiry was quite reasonable as well as valid in a security
aspect.
No it wasn't. It was illogical. Chris has already pointed to the FAQ
entry that discusses this in more detail. I don't propose to repeat
those arguments here but I will say the proposal below is nonsense.
Mark
Which part of OP's comment illogical? is concerning the clear-text
password illogical?
Where is the part in the FAQ that describe *in more detail* part? I'll
be interesting to
read about it.
Nonsense? Is logical and rational simply saying nonsense without any
logical explanation?
You could point out which part specifically you do not understand.
Perhaps, security topic
is too much for you to digest?
When you do not understand, you simply just don't get it.
Pae
P.S.: Also, why I am seeing your post without my original posting? How
funny!
The 'password' for
the key store falls in the same category. I remember there were more
than a few times the same and
similar subject addressed, but i guess it's still as it was.
To give an idea in terms of where to place and how to access,
1) The clear-text or enciphered-form password in the code.
2) The clear-text password in the connector in the server.xml can be
replaced with the API method
name that can provide the password.
This simple mechanism can be either or both by Tomcat as default and/or
custom-class that implements
the defined API.
Within the implementation, how the API method provided the password can
be left to the implementation
provider. In that way, each Tomcat will have unique as well as more
secure depends how well implemented
the password provisioning class implemented which can be left to the
implementation provider.
Anyhow, this is a basic idea where the password can be placed and how it
can be accessed. And it can be
easily implemented with reasonably short amount of time and effort.
To go further more for multiple certificates for multiple vHosts such as
SNI+OpenSSL(or alternatives),
it will be a bit more challenging, but not so hard about it.
Pae
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
