Michael S. Zick wrote:
On Wed December 24 2008, Edward Diener wrote:
Michael S. Zick wrote:
On Wed December 24 2008, Edward Diener wrote:
In a client application communicating with a MySQL server, I am using
SSL to encrypt/decrypt data sent to and from the database. This requires
me to have the PEMs for the CA, client key, and client certificate
distributed as part of the application. Of course these certificates
will not work except with the corresponding server certificates on the
MySQL server to which I am communicating.
My initial choice was to distribute the client certificates in the same
directory as the application's modules, as they are easy to find at
run-time there in order to make my SSL connection with the database. It
has been suggested to me that this is inherently insecure. Nonetheless I
must distribute them somewhere since the certificates have to exist in
the file system when I make the call at run-time to create a SSL
connection to the server.
What are the best strategies to distribute these client certificates on
the end-user's machine ? Should I be pre-encrypting these certificates,
then decrypting them in memory before writing them to a temporary
location, and then destroying the decrypted certificates from that
temporary location after the connection is made, or is this overkill and
a simpler/better way of distributing the client certificates as part of
my application is possible ?
Any suggestions, help, pointers would be much appreciated.
It is a hard question to answer without some knowledge of your risk model.
What are the risks that you are trying to minimize?
What harm is done if the files are accessable to the people who already
have your application? Is this even a concern? Should it be?
I am working for an employer who will be selling a product to end users.
The risk model is that my employer feels it would be bad if a hacker
were able to easily understand where the client certs reside in the end
user application and were able to use the client certs to communicate to
the server, ie. if someone who buys the product were able to use the
client certs in a destructive way. My employer has also been told by a
Sun representative he knows that if the client certs are distributed in
the directory of the application it is a serious security risk. So he
has asked me to investigate alternative ways of distributing the client
certs.
My own feeling is that even with the client certs, nothing can be done
unless the host-server/username/password/database were known to
destructive hacker.
But my employer is concerned and wants to make it more difficult for the
end users to be able to ascertain where the client certs are once they
install the application.
Ah, so - Your risk model is: "Give the boss a warm and fuzzy feeling."
No, my risk model is to simply ascertain whether distributing the certs
as files in the application directory is a serious security risk or not
and, if it is, what steps can make it less so.
The suggestion of using the ACL protection, to protect from casual
or accidental access sounds like a good one - if your platform supports it.
Windows supports ACLs. But any registered end-user on the client machine
can use the application and the installation of the application does not
know at installation time who are the registered users on the client
machine. So using ACLs is probably not a very effective solution.
Use some light-weight, passphrase keyed, encryption to hide the contents.
I can certainly do that.
Consider using the "__from_memory" rather than the "__from_file" functions
of openSSL so you don't have to write the "un-hidden" files back to
the file system.
That would be great if the MySQL API would allow the certs to be passed
from memory. Unfortunately the client C/C++ API expects file names
instead. So after encrypting the certs I need to decrypt them back to a
files in order to use them.
For the passphrase, use a simple little linear-feedback-shift register
to select bytes from some part of the application.
That way the passphrase isn't stored as a string in the application,
that part of the application would have to be reverse-engineered.
Or maybe checksum (crypto hash function, that is) a critical dll for
the passphrase. Should be hard to find among all the other sha256sum
and such like calls in the application.
Yes, I already have a clever way of generating passphrases which keeps
them from being stored in the application.
This will not keep a cryptographer out of your application, but should
pass the "warm and fuzzy" test.
It may make it harder for a disruptive hacker.
In general what I can do is store the certs in encrypted form as
resources in the application and, each time I need them, read the
resources into memory, decrypt them, write them out as temporary files,
use the temporary files in the MySQL connection, and then destroy the
temporary files after the SSL connection is made. This will keep me from
distributing them as files in the installation.
Whether this extra processing is really necessary, good security, or
"security theatre" as another respondent on this thread claims, I am
really not sure. But that is why I posted my OP, to see what others
think and how others handled the situation.
Thanks !
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
