RE: Crash when using FIPS OpenSSL
Hello,
After digging some more I saw that the cause of the problem was that the
BIO callback function "b->method->bgets" that should have pointed to
file_gets actually pointed to BIO_new_fp which obviously crashed my
program. I don't know what caused this, but I can guess that this is
related to the special build required for OpenSSL 0.9.7 FIPS support
(using MSYS & GCC for the FIPS canister). This does not happen in 0.9.8.
I was able to find a workaround by using different API to load the
certificate, this code works:
bioCert = BIO_new(BIO_s_file());
if(bioCert == NULL) {
printf ("problem\n");
return;
}
if (BIO_read_filename(bioCert," CA.cer") <= 0)
{
printf ("problems\n");
}
hCert=PEM_read_bio_X509_AUX(bioCert,NULL,NULL, NULL);
Cheers,
Hagai.
From: Hagai Yaffe
Sent: Thursday, December 04, 2008 11:08 PM
To: openssl-users@openssl.org
Subject: Crash when using FIPS OpenSSL
Hello,
I am working on using OpenSSL in FIPS mode in my application, I am using
OpenSSL 0.9.7m on windows. I have successfully built OpenSSL according
to the FIPS user guide, but on specific operation my application crashes
inside OpenSSL.
I have created a small program that demonstrates the problem, when
linked with regular OpenSSL build in works successfully, when working
with FIPS build OpenSSL (in FIPS mode or not) it crashes (in a call to
BIO_gets).
The certificate I am trying to read is a base 64 encoded CA certificate.
Any ideas on what is causing this? I can't seem to debug into the
BIO_gets command (I guess that this happens since it is in the FIPS
canister), any help would be great.
Thanks,
Hagai.
Program:
#include
#include
#include
#include
#include
#define OPENSSL_FIPS
void main()
{
#ifdef _FIPS
if (!FIPS_mode_set(1))
{
fprintf(stderr,"*** Problem entering fips mode ***\n");
return;
}
else
{
fprintf(stderr,"*** IN FIPS MODE ***\n");
}
#endif
int iRc = 1;
BIO*bioCert = NULL;
FILE *hStoreFile;
X509 *hCert = NULL;
hStoreFile = fopen("CA.cer", "r");
// Create new BIO and set it to point our store file
bioCert = BIO_new(BIO_s_file());
if(bioCert == NULL) {
printf ("problem\n");
return;
}
iRc = BIO_set_fp(bioCert,hStoreFile, BIO_NOCLOSE);
if (iRc <= 0) {
printf ("problem\n");
}
hCert = (X509 *)PEM_read_bio_X509(bioCert, NULL, NULL, NULL);
}
Crash occurs at line: i=BIO_gets(bp,buf,254); (pem_lib.c:643)
> libeay32.dll!PEM_read_bio(bio_st * bp=0x0172acb8, char * *
name=0x0012d14c, char * * header=0x0012d148, unsigned char * *
data=0x0012d150, long * len=0x0012d158) Line 643 C
libeay32.dll!PEM_bytes_read_bio(unsigned char * *
pdata=0x0012d180, long * plen=0x0012d188, char * * pnm=0x, const
char * name=0x0fbee77c, bio_st * bp=0x0172acb8, int (char *, int, int,
void *)* cb=0x, void * u=0x) Line 231 + 0x19 C
libeay32.dll!PEM_ASN1_read_bio(char * (void)* d2i=0x0fb3af70,
const char * name=0x0fbee77c, bio_st * bp=0x0172acb8, char * *
x=0x, int (char *, int, int, void *)* cb=0x, void *
u=0x) Line 77 + 0x1f C
libeay32.dll!PEM_read_bio_X509(bio_st * bp=0x0172acb8, x509_st *
* x=0x, int (char *, int, int, void *)* cb=0x, void *
u=0x) Line 68 + 0x22 C
RE: Where to store client PEM certificates for an application
> 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. If it's a security risk, it's because something is broken someplace else. Why do you need to hide a customer's own certificates from that customer? Presumably, the certificate only permits the customer to do things the customer is authorized to do. If the customer's cert lets the customer do something the customer is not allowed to do, then something is broken elsewhere. > > 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. How would a hacker be able to disprut anything by obtaining normal user access? If normal user access permits disruption, you have a design flaw. > 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 ! If it's necessary, it's inadequate. An ordinary user should only be permitted to do those things you wish to allow that user to do. So an ordinary user getting access to his own credentials should not pose a security risk. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where to store client PEM certificates for an application
Victor Duchovni wrote: On Wed, Dec 24, 2008 at 03:59:13PM -0500, Edward Diener wrote: 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. It sounds like you are trying to implement DRM with an application that is running on untrusted hardware controlled by a potentially hostile user. You want to ensure that only your code has access to your server, and not modified or user developed code. This is a "whitebox" DRM problem. Are you saying that any application sold on the market which needs to ensure secure access to data on a server outside the client machine on which the application runs is a "whitebox" DRM problem ? Your problem is completely unrelated to SSL and certificates. You need a DRM professional. This is likey not the right forum for help with whitebox DRM. Unless you have trusted hardware, you need code obfuscation techqniques that hide key material in code visible to the attacker. There is some commercial software in this space, but none in OpenSSL. Good luck. Thanks for your input. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where to store client PEM certificates for an application
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 m
Re: Where to store client PEM certificates for an application
Kyle Hamilton wrote:
On Wed, Dec 24, 2008 at 1:27 PM, Edward Diener wrote:
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 it's under Windows, you can place the certificate (and key) in your
app's registry. You could also use the so-called "native" API to
embed a NUL character ('\0') in the name of the key you place it in.
See http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx for
information on this (look for "Hidden Registry Keys" on the page);
however, be aware that many rootkit scanners will find and delete
these WinSDK-inaccessible entries.
My interpretation of using the Windows registry is that a very long
string should not be placed there, even if I could obfuscate the actual
key using the NUL character technique you mention above.
This is a red flag to most security-conscious hackers, though, and
many will do anything they can to figure out what's in there.
I fully agree.
Also, the host/port must be considered public information. They can
be easily derived with netstat.
You are right.
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.
If you're using CryptoAPI, why are you not using it for key storage as well?
According to the MySQL client documentation using the C/C++ API, I must
pass file names to the API where my CA, client certificate, and client
key reside.
Furthermore the CryptoAPI is not a storage mechanism, only an
encrypt/decrypt mechanism AFAIK.
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.
The openssl library (libeay) can do everything that cryptoAPI can do,
as well. It doesn't use the same API convention, though.
I am not using OpenSSL directly in my application, although I suppose I
could do so. I find the CryptoAPI pretty adequate and the doc for the
CryptoAPI which Microsoft supplies is quite good.
This is potentially a very good idea. At least I could keep everyone except
my application from easily viewing the certs.
No, since your application runs with the user's rights, the user must
be able to read the certs and key.
The user meaning my application. You are correct.
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.
This is absolute garbage. The idea behind certificates is that they
uniquely identify the consumer's public key (and thus the private key
they use with it), and they're signed by someone you trust. You can
also embed a critical extension in the certificate so that no other
X.509 application would or could use it. You don't have to put any
kind of private or confidential data in the certificate itself. (It
is the PRIVATE KEY which must be kept protected.)
I totally agree with you.
I'd like to know the name of the rep at Sun who told your employer
this, so I can go to Sun and say "you need to train your developer
liaisons better about X.509 and asymmetric cryptography."
I would gladly give it to you if my employer agreed to do it. I did not
think the Sun representative was right.
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.
MySQL uses the certificate itself to identify the user to the
database, avoiding the use of a passwo
Re: Where to store client PEM certificates for an application
On Wed, Dec 24, 2008 at 03:59:13PM -0500, Edward Diener wrote: > > 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. It sounds like you are trying to implement DRM with an application that is running on untrusted hardware controlled by a potentially hostile user. You want to ensure that only your code has access to your server, and not modified or user developed code. This is a "whitebox" DRM problem. Your problem is completely unrelated to SSL and certificates. You need a DRM professional. This is likey not the right forum for help with whitebox DRM. Unless you have trusted hardware, you need code obfuscation techqniques that hide key material in code visible to the attacker. There is some commercial software in this space, but none in OpenSSL. Good luck. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where to store client PEM certificates for an application
On Wed, Dec 24, 2008 at 1:27 PM, Edward Diener wrote:
> 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 it's under Windows, you can place the certificate (and key) in your
app's registry. You could also use the so-called "native" API to
embed a NUL character ('\0') in the name of the key you place it in.
See http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx for
information on this (look for "Hidden Registry Keys" on the page);
however, be aware that many rootkit scanners will find and delete
these WinSDK-inaccessible entries.
This is a red flag to most security-conscious hackers, though, and
many will do anything they can to figure out what's in there.
Also, the host/port must be considered public information. They can
be easily derived with netstat.
> 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.
If you're using CryptoAPI, why are you not using it for key storage as well?
> 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.
The openssl library (libeay) can do everything that cryptoAPI can do,
as well. It doesn't use the same API convention, though.
> This is potentially a very good idea. At least I could keep everyone except
> my application from easily viewing the certs.
No, since your application runs with the user's rights, the user must
be able to read the certs and key.
> 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.
This is absolute garbage. The idea behind certificates is that they
uniquely identify the consumer's public key (and thus the private key
they use with it), and they're signed by someone you trust. You can
also embed a critical extension in the certificate so that no other
X.509 application would or could use it. You don't have to put any
kind of private or confidential data in the certificate itself. (It
is the PRIVATE KEY which must be kept protected.)
I'd like to know the name of the rep at Sun who told your employer
this, so I can go to Sun and say "you need to train your developer
liaisons better about X.509 and asymmetric cryptography."
> 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.
MySQL uses the certificate itself to identify the user to the
database, avoiding the use of a password entirely -- but only if the
certificate is issued by a trusted authority. The hostname/port is
public information (remember, netstat). The username which is used to
authenticate to the application is tested against the database, and
the password is as well. (You are remembering not to store the users'
passwords in clear-text, right?)
> But he has asked me to investigate the ways it can be done nonetheless.
You should instead be focusing on mitigating what happens WHEN (not
IF, because it WILL HAPPEN) someone manages to break the security of
your application and server. That's where you should be focusing your
development time/effort, not on some "makes the manager feel warm and
fuzzy" security theater. (You have my authorization to print out this
message and share it with him, if you think it would do any good.)
>> Depending
Re: Where to store client PEM certificates for an application
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." The suggestion of using the ACL protection, to protect from casual or accidental access sounds like a good one - if your platform supports it. Use some light-weight, passphrase keyed, encryption to hide the contents. 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. 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. This will not keep a cryptographer out of your application, but should pass the "warm and fuzzy" test. Mike > > > > Mike > >> 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 Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where to store client PEM certificates for an application
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 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 h
Re: Where to store client PEM certificates for an application
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. Mike 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where to store client PEM certificates for an application
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 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 Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where to store client PEM certificates for an application
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? Mike > 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 Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Where to store client PEM certificates for an application
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
