tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: [PROPOSAL] Standalone SSL
Date Wed, 01 Aug 2001 17:46:40 GMT
Christopher Cain wrote:
> 
> "Craig R. McClanahan" wrote:
> >
> > Not a problem ... it's just that I think you're being a little narrowly
> > focused on the solution to *your* problem, and ignoring the bigger picture
> > :-).
> 
> I suppose that's fair to a certain extent. I do see cert protection as a
> little more critical than many of the other resources, but I agree that
> it's just one man's opinion.
> 
> > Protecting your certificates is all well and good, and I have no objection to that.
 It's necessary, but it's not sufficient.
> 
> Agreed.
> 
> > To flesh out my example, to use features like container-managed security,
> > you need to tell Tomcat how to gain access to its "repository" of
> > usernames, passwords, and role information.  Most users will do this
> > either in a database or a directory server, which means that a
> > configuration file read by Tomcat must contain the appropriate database
> > (or directory server) username and password.
> 
> Again, I think my goal lies along the same path as the broader goal.
> Authentication is needed, it's just a matter of implementation.
> 
> > What I'm saying is that I don't care much about your certificates if I can
> > snoop the database connection information and go hack your passwords
> > database.  So protecting just the certificates is insufficient to solve
> > the entire problem you are raising.
> 
> True.
> 
> > How many challenges for different pieces of sensitive information are you
> > willing to impose on the system administrator?  And, is that really any
> > more secure (in that the sysadmin is now going to have *all* the answers
> > to these questions on a little sticky note someplace, instead of
> > memorizing the one password needed to start the server as root :-)?
> 
> I guess my eventual vision is something along the lines of a master
> "Tomcat Config" password. This would be used to protect ALL sensitive
> resource information. It could be something as simply as encrypting all
> of this information in a single file in "conf" by deriving a symmetric
> key from the supplied passphrase. Any admin which turns on this feature
> would need to be prompted at startup in order to load any resources,
> such as SSL, which are needed at startup. Anything which can be
> configured on-the-fly while the server is running could be administered
> from the admin context perhaps. The user would be challenged again every
> time he/she wanted to access this page, but we're still talking the same
> "Master Tomcat" password. And since we probably want to run this page in
> SSL, we will need the password at startup anyway :-)
> 
> My point is that the prompt code will be necessary anyway, so why not
> let me use it to grab the keystore password (if appropriate) until the
> more comprehensive solution can be put in place? Again, I consider SSL
> the weak link, so that would at least get us some level of protection
> right away, and most of the code will be needed eventually anyway?
> Again, all of this will be optional so that the non-security-sensitive
> environents won't be forced to do any of this.
> 
> So does my general idea make sense? And also, does my SSL stopgap sound
> reasonable, or am I being a little selfish here (it wouldn't be the
> first time ;-)?

Encrypting server certificates is not bad but it prevents starting the server
automaticly.
Storing this password is a nonsense.
OpenSSL (for example) allows to modify this password or to have no password.
If the server certificates is encrypted then we should prompt for the password.
Of course this password should be independant for the other passwords used in
the system...

If you are afraid having user passwords stored in the machine you should use
"user certificates" or something like that....
(I will go on tomorrow if the thread is still active ;-))

> 
> - Christopher

Mime
View raw message