[PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

First, just a quick follow-up on the previous thread. Using the keystore
defaults for the TC4 SSL standalone config works as planned. Trying to
override the keystoreFile and/or keystorePass defaults, unfortunately,
does not work (different exceptions for each). 

It makes me extremely nervous to have a default password on my certs. Of
course, it also gets me nothing to change it to a solid password and
then type that into server.xml. How would you feel about changing the
SSL process to be more like the Apache approach, where the user is
prompted on the command line for the store/key password at startup? The
one drawback is that the web server/container cannot restart without
human intervention (although the only real-world scenerio I've ever
encountered where it was really an issue is a clean automated
shutdown/restart from UPS program, for example).

IMHO, that is a VERY small penalty for not having to store your cert
password in plaintext in server.xml. In fact, the current solution is
completely unimplementable in a production system. I'm sure I don't have
to tell you that one would have to be completely insane to store the
password to their official cert/private key in the clear in a config
file. Since I have an immediate need for this functionality, I am
volunteering to do it. So the only question is, how does everyone feel
about switching to the Apache approach? I assume that there is not a
spec issue which would preclude this.

To be fair, I should tell you that I am one of those crypto freaks, so
please keep that in mind when I start ranting about having a solid
crypto design =) The primary OSS project I am involved in is a java
crypto library, so this issue is near and dear to my heart.

Regards,

Christopher

Re: [PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

"Pier P. Fumagalli" wrote:
> 
> The only thing is that apache uses getpass(), so securing the password when
> you type it, as it's not read from stdin, but ioctling your tty device.
> Asking for your cert on stdin is not _that_ secure.

Depends on your point of view, I suppose. If I'm sitting at the
terminal, it's pretty damn secure. If I'm SSHed in, it's still
reasonably secure. If I'm accessing it over a local network, it's a
little less secure. If I'm telneted in, it's not so secure. IMO, all of
that is still more secure than having it sitting plaintext in a file
that is probably at the very least group readable. At least with the
Apache method some would have to be snooping real-time.

> When the service code is in place, under UNIX, you'll be able to use a
> configuration file owned and readable only by "root", since it's read by the
> JVM process when it's still running as root...

Cool! At that point I would still consider having it in a file a risk,
but a MUCH lower one. My vote would still be to have it prompted for at
startup and NEVER stored anywhere, but if the file is root read-only
that is a vast improvement.

Unfortunately, that still leaves Windoze. Those poor users don't have a
real OS-level security scheme, so for them it's pretty much still stored
for the world to see. And we all know that it can be MUCH easier to
crack a standard Win box than a standard *nix box, so for Win users
having it not stored anywhere would definitely be a better solution.

- Christopher

Re: [PROPOSAL] Standalone SSL

["Pier P. Fumagalli" <pi...@betaversion.org>]

Christopher Cain at ccain@mhsoftware.com wrote:

> First, just a quick follow-up on the previous thread. Using the keystore
> defaults for the TC4 SSL standalone config works as planned. Trying to
> override the keystoreFile and/or keystorePass defaults, unfortunately,
> does not work (different exceptions for each).
> 
> It makes me extremely nervous to have a default password on my certs. Of
> course, it also gets me nothing to change it to a solid password and
> then type that into server.xml. How would you feel about changing the
> SSL process to be more like the Apache approach, where the user is
> prompted on the command line for the store/key password at startup? The
> one drawback is that the web server/container cannot restart without
> human intervention (although the only real-world scenerio I've ever
> encountered where it was really an issue is a clean automated
> shutdown/restart from UPS program, for example).
> 
> IMHO, that is a VERY small penalty for not having to store your cert
> password in plaintext in server.xml. In fact, the current solution is
> completely unimplementable in a production system. I'm sure I don't have
> to tell you that one would have to be completely insane to store the
> password to their official cert/private key in the clear in a config
> file. Since I have an immediate need for this functionality, I am
> volunteering to do it. So the only question is, how does everyone feel
> about switching to the Apache approach? I assume that there is not a
> spec issue which would preclude this.
> 
> To be fair, I should tell you that I am one of those crypto freaks, so
> please keep that in mind when I start ranting about having a solid
> crypto design =) The primary OSS project I am involved in is a java
> crypto library, so this issue is near and dear to my heart.

The only thing is that apache uses getpass(), so securing the password when
you type it, as it's not read from stdin, but ioctling your tty device.
Asking for your cert on stdin is not _that_ secure.

When the service code is in place, under UNIX, you'll be able to use a
configuration file owned and readable only by "root", since it's read by the
JVM process when it's still running as root...

    Pier

Re: [PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

> Jim Seach wrote:
> [snip]
> >
> > 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.

You just made me think of another decent argument against the current
implementation. In a typical install setup, all developers,
administrators, and anyone else with access to the box currently has
unfettered access to the keystore, because they have the password. That
is not good. You probably want only a single administrator have access
to the cert, that way you don'd have to get a new one every time someone
leaves the business. Of course a highly-knowledgeable admin could simply
hide the keystore and/or TC conf directory in an inaccessible directory
(preferably both for maximum security), but not everyone is a security
whiz. The opt-in configuration option for a "prompt me" approach makes
it ALOT easier to secure everything right and without goofing up
directory permissions. And again, it is probably the only decent option
for Windoze shops.

- Christopher

Re: [PROPOSAL] Standalone SSL (status?)

[Christopher Cain <cc...@mhsoftware.com>]

I forgot to mention that I plan on offering to port this initial
keystore security solution (whatever it ends up being, although the
Apache-style prompt is so far the only idea being floated) to the 3.3 if
there is any interest in having it. I don't technically consider it a
bug, so the 3.2 branch is probably not appropriate. I'm not sure what
the general feeling on the 3.3 beta process is, if such a thing would be
considered too big a modification at this point, or if anyone in the 3.3
branch is even interested. I just thought I'd point out that you 3.3
cats are more than welcome to speak up on this idea as well.

Also, where are we at in the process? I hate to be pushy (no, really
:-), but I kind of need to get my app up and running, plus I'm up
against it on the cluster management tool I mentioned. If I could just
get a general feel as to how much support the (configurable, as pointed
out by Jim) command-line prompt idea has as far as addressing the
problem, then I can go ahead and jam on that. I'm not necessarily asking
for anything offical (although I probably wouldn't mind :-), but I 
mainly just want to make sure that I'm starting on the best possible
(initial) solution ... or at least the solution that would make the most
sense in the long run should it eventually make in into CVS. Unless it
is just something wildly personal, I hate writing code to extend an OSS
product and just sit on it myself, but I kinda need to start coding soon
=)

- Christopher

Re: [PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

jean-frederic clere wrote:
> 
> 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 ;-))

We're in agreement. My initial thought was that either the cert is
encrypted (the secure approach) or not encrypted (the insecure
approach), and if encrypted you are prompted for the password. Since
storing the password in server.xml is essentially the equivalent of not
encryptng it at all, I assumed that we would want to keep the current
approach in place as the "insecure" option both for backwards
compatibility and since the "keytool -genkey" method (which obviously
generates an encrypted keystore) is easy for end users to do. I would
have no objections to the encrypted vs. unencrypted approach you
describe, but that's why I didn't propose it.

As far as the thread still being active tomorrow, I promise I won't let
it die without either a resolution or a fight ;-)

- Christopher

Re: [PROPOSAL] Standalone SSL

[jean-frederic clere <jf...@fujitsu-siemens.com>]

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

Re: [PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

"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 ;-)?

- Christopher

Re: [PROPOSAL] Standalone SSL

["Craig R. McClanahan" <cr...@apache.org>]

On Tue, 31 Jul 2001, Christopher Cain wrote:

> Quoting Jim Seach <jw...@yahoo.com>:
> > 
> > I think we're in agreement.  The "initial authentication" problem
> > needs to be resolved before we can talk about leveraging it to solve the
> > other problems.  I like your proposal of an optional prompt solution
> > for this.
> 
> Cool.
> 
> > This is an area of interest for me, but it is not something I spend a
> > large part of my time on, so despite being a CISSP, I am certainly not
> > an expert.  I am willing to lend a hand, though, if you are interested
> > in spearheading a general solution to the larger problem.
> 
> Cool. You're definitely invited if I can manage to browbeat the commiters into 
> signing on for such a monster =)
> 
> Seriously, though, it always helps the cause if at least a few people state an 
> interest in helping out, so I definitely appreciate it.
> 
> One other thing, Craig. In re-reading a few of my posts, I realized that I come 
> off a bit heavy-handed. Sorry about that ... it's that damn cryptography-weenie 
> demeanor that drill into us before they give us our membership cards :-)
> 

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
:-).  Protecting your certificates is all well and good, and I have no
objection to that.  It's necessary, but it's not sufficient.

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.

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.

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 :-)?

> - Christopher
> 

Craig

Re: [PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

Quoting Jim Seach <jw...@yahoo.com>:
> 
> I think we're in agreement.  The "initial authentication" problem
> needs to be resolved before we can talk about leveraging it to solve the
> other problems.  I like your proposal of an optional prompt solution
> for this.

Cool.

> This is an area of interest for me, but it is not something I spend a
> large part of my time on, so despite being a CISSP, I am certainly not
> an expert.  I am willing to lend a hand, though, if you are interested
> in spearheading a general solution to the larger problem.

Cool. You're definitely invited if I can manage to browbeat the commiters into 
signing on for such a monster =)

Seriously, though, it always helps the cause if at least a few people state an 
interest in helping out, so I definitely appreciate it.

One other thing, Craig. In re-reading a few of my posts, I realized that I come 
off a bit heavy-handed. Sorry about that ... it's that damn cryptography-weenie 
demeanor that drill into us before they give us our membership cards :-)

- Christopher

Re: [PROPOSAL] Standalone SSL

[Jim Seach <jw...@yahoo.com>]

--- Christopher Cain <cc...@mhsoftware.com> wrote:
> 

[SNIP]

> 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


I think we're in agreement.  The "initial authentication" problem needs
to be resolved before we can talk about leveraging it to solve the
other problems.  I like your proposal of an optional prompt solution
for this.

This is an area of interest for me, but it is not something I spend a
large part of my time on, so despite being a CISSP, I am certainly not
an expert.  I am willing to lend a hand, though, if you are interested
in spearheading a general solution to the larger problem.

Jim

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

Jim Seach wrote:
> 
> --- Christopher Cain <cc...@mhsoftware.com> 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

Re: [PROPOSAL] Standalone SSL

[Jim Seach <jw...@yahoo.com>]

--- Christopher Cain <cc...@mhsoftware.com> 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.

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.

> 
> > 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


Jim

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

Jim Seach wrote:
> 
> --- Christopher Cain <cc...@mhsoftware.com> 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

Re: [PROPOSAL] Standalone SSL

[Jim Seach <jw...@yahoo.com>]

--- cmanolache@yahoo.com wrote:
> On Tue, 31 Jul 2001, Jim Seach wrote:
> 
> > What I meant was, in order to implement SSL,  Tomcat must be able
> to
> > decrypt the keystore to retrieve the private key for the cert.  A
> > Tomcat extension or module could be developed to use the private
> key
> > not only to decode the SSL traffic, but also to decode other
> > information like database passwords and so forth that developers
> wished
> 
> In particular the admin and/or ajp password :-)
> 
> One of the biggest problems is that so many people are installing
> tomcat
> and they just forget to change the passwords.
> 
> We already generate a random number for the shutdown command, but a
> module
> that checks if the admin password is still "changethis" and refuse to
> start until the user types a better password will do a lot for
> secuirty
> :-)
> 
> I'm not very sure about certificate passwords or other things - but
> if
> someone needs this then great. I think ( IMHO ) the authentication,
> etc
> should happen outside tomcat ( at least in a different process ), I'm
> not
> sure if existing auth servers ( kerberos, tacacs, radius, etc ) have
> any
> support for certificates, but as long as tomcat is running user code
> (
> even with the security manager in place ), I wouldn't trust it more
> than I
> have to.
> 
> And don't forget that tomcat may even crash, or hung ( well, if not
> tomcat

It has never crashed on me, except where it was clearly my fault! :)

> maybe some user code or even the JDK or OS ). :-)
> 
> Costin
> 

I think these are important features/requirements for the "External
Resource Security/Centralized Repository" project that Christopher
would like to pursue, but was waiting for an expression of interest
from the committers.

Can this be construed as the expression of interest he was looking for?
:)

Jim

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [PROPOSAL] Standalone SSL

[cm...@yahoo.com]

On Tue, 31 Jul 2001, Jim Seach wrote:

> What I meant was, in order to implement SSL,  Tomcat must be able to
> decrypt the keystore to retrieve the private key for the cert.  A
> Tomcat extension or module could be developed to use the private key
> not only to decode the SSL traffic, but also to decode other
> information like database passwords and so forth that developers wished

In particular the admin and/or ajp password :-)

One of the biggest problems is that so many people are installing tomcat
and they just forget to change the passwords.

We already generate a random number for the shutdown command, but a module
that checks if the admin password is still "changethis" and refuse to
start until the user types a better password will do a lot for secuirty
:-)

I'm not very sure about certificate passwords or other things - but if
someone needs this then great. I think ( IMHO ) the authentication, etc
should happen outside tomcat ( at least in a different process ), I'm not
sure if existing auth servers ( kerberos, tacacs, radius, etc ) have any
support for certificates, but as long as tomcat is running user code (
even with the security manager in place ), I wouldn't trust it more than I
have to.

And don't forget that tomcat may even crash, or hung ( well, if not tomcat
maybe some user code or even the JDK or OS ). :-)

Costin

Re: [PROPOSAL] Standalone SSL

[Jim Seach <jw...@yahoo.com>]

--- "Pier P. Fumagalli" <pi...@betaversion.org> wrote:
> Jim Seach at jwseach@yahoo.com wrote:
> > 
> > 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.
> 
> Cool, are we going to use a private key to encrypt the password for
> the
> private key of Tomcat? Cool, kinda gets recursive... :) WHAT?
> 
>     Pier
> 

That would be a good trick! :)

What I meant was, in order to implement SSL,  Tomcat must be able to
decrypt the keystore to retrieve the private key for the cert.  A
Tomcat extension or module could be developed to use the private key
not only to decode the SSL traffic, but also to decode other
information like database passwords and so forth that developers wished
to securely make available to Tomcat. (How to make this information
available to the webapp code would have to be carefully designed)  If
Christopher's suggestion about prompting for the keystore key is
implemented, none of these private pieces of information need to be
stored in plaintext.

Jim


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [PROPOSAL] Standalone SSL

["Pier P. Fumagalli" <pi...@betaversion.org>]

Jim Seach at jwseach@yahoo.com wrote:
> 
> 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.

Cool, are we going to use a private key to encrypt the password for the
private key of Tomcat? Cool, kinda gets recursive... :) WHAT?

    Pier

Re: [PROPOSAL] Standalone SSL

[Jim Seach <jw...@yahoo.com>]

--- Christopher Cain <cc...@mhsoftware.com> 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.

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.

Jim

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [PROPOSAL] Standalone SSL

[Christopher Cain <cc...@mhsoftware.com>]

"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

Re: [PROPOSAL] Standalone SSL

["Craig R. McClanahan" <cr...@apache.org>]

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).

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?  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?

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.

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.


On Tue, 31 Jul 2001, Christopher Cain wrote:

> First, just a quick follow-up on the previous thread. Using the keystore
> defaults for the TC4 SSL standalone config works as planned. Trying to
> override the keystoreFile and/or keystorePass defaults, unfortunately,
> does not work (different exceptions for each). 
> 
> It makes me extremely nervous to have a default password on my certs. Of
> course, it also gets me nothing to change it to a solid password and
> then type that into server.xml. How would you feel about changing the
> SSL process to be more like the Apache approach, where the user is
> prompted on the command line for the store/key password at startup? The
> one drawback is that the web server/container cannot restart without
> human intervention (although the only real-world scenerio I've ever
> encountered where it was really an issue is a clean automated
> shutdown/restart from UPS program, for example).
> 
> IMHO, that is a VERY small penalty for not having to store your cert
> password in plaintext in server.xml. In fact, the current solution is
> completely unimplementable in a production system. I'm sure I don't have
> to tell you that one would have to be completely insane to store the
> password to their official cert/private key in the clear in a config
> file. Since I have an immediate need for this functionality, I am
> volunteering to do it. So the only question is, how does everyone feel
> about switching to the Apache approach? I assume that there is not a
> spec issue which would preclude this.
> 
> To be fair, I should tell you that I am one of those crypto freaks, so
> please keep that in mind when I start ranting about having a solid
> crypto design =) The primary OSS project I am involved in is a java
> crypto library, so this issue is near and dear to my heart.
> 
> Regards,
> 
> Christopher
>