Kyle Hamilton wrote:
If you're on Windows, it does make sense to include the PEMs for the
CA (and chain) in the application directory. (See, for example, the
software distribution of Second Life, which has its own CA for TLS
authentication of its own grid servers.)
For client certificates, though, it depends. If it's a per-user
certificate, the certificate (and key) should go in the user's home
directory (in a folder not unlike, but also not, ~/.ssh) -- and should
have permissions which only allow the user access. If it's a
per-machine certificate, the certificate (and key) should go under
either /etc/ or /var/ (on *nix) or the application directory (on
Windows).
It is a per-machine cert in my case under Windows. But it is solely for
the use of a single application. I certainly can distribute the certs
in the common application directory under Windows but that complicates
the issue under Windows Vista protected mode, where certain directories
are off-limits to a running application unless the application runs with
Administrator rights, which is something not being required of the end
user once the application has been installed. Nonetheless it is a good
idea to consider. At least the certs are more hidden there than in the
application directory.
If you encrypt the client key, you can place the decryption
information into your client binary itself; if you do this, though,
you should try to scramble it a bit (to prevent a simple 'strings'
operation from seeing it), and you should statically link it and make
it mode \111 (executable-only for owner, group, and world).
If I encrypt the cert files pre-installation I would use the the Windows
Crypto API library to do so, and then use the same library at run-time
to decrypt it and put it someplace temporarily in order to user the cert
files. I have already used the Crypto API successfully so I know it can
be done fairly easily.
I do not think I really need to scramble anything once the data is
encrypted as the "strings" are just totally encrypted sequences of byte
information once Crypto API encrypts them.
If the
filesystem you're on supports POSIX ACLs, you should include
"everyone: deny read".
For a Windows binary, you should apply the same ACL entry, along with
SYSTEM: deny ACL modification. (This only provides a small modicum of
security, since non-Windows NTFS drivers tend to completely ignore the
access control list.)
This is potentially a very good idea. At least I could keep everyone
except my application from easily viewing the certs.
Overall, it's important to recognize this: you are attempting to keep
the user's computer from knowing what the key is unless it's within
your process. This is, ultimately, a doomed endeavor.
I fully agree with you. It is my employer who has been told that
distributing the certs so that an end user can easily view them is a
security risk. My own viewpoint is that the certs are useless without
host-name/username/password/database knowledge of the server database
anyway so there is little point really in inventing elaborate measures
to hide the certs from the end users eyes.
But he has asked me to investigate the ways it can be done nonetheless.
Depending on
how important it is that the data be secure, you may need to ensure
that a given client key is only used from a specific IP address or IP
range...
It is an application to be sold to end users, so the 'from' IP address
can not be pre-established. We do have ways from within the application
to make sure that the client is a registered user which takes into
account the client's machine. But of course a destructive hacker who
could use the client certs along with the
host-name/username/password/database knowledge to access the database is
not running from within the application.
and you may also need to be on the lookout for inappropriate
access patterns (any 'select *', for example, if your application
doesn't use that means of getting data out of the tables) -- and if
you do see it, boot the connection from the server and invalidate the
client authentication credentials.
I do not know how I can 'see' such patterns from within the application
itself. I do not think a destructive hacker can easily change the
application, even knowing the client certs, but maybe there are ways and
I am willing to be educated about them.
Your threat model may or may not require this much; in most
circumstances, I would consider it overkill. However, if you're under
contractual obligation to ensure that the data remain confidential,
you might need to take these steps -- and more.
Thanks for your suggestions, especially about the ACLs, which can fairly
easily be manipulated by the installation program.
-Kyle H
On Wed, Dec 24, 2008 at 4:54 AM, Edward Diener <el...@tropicsoft.com> 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.
Finally the client application runs on Windows and not LInux so if there
are OS specific arguments as to how to distribute these client
certificates you will know to what OS the application is targeted.
Thanks !
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
