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