Re: Where to store client PEM certificates for an application
On Thu January 1 2009, Victor Duchovni wrote: On Thu, Jan 01, 2009 at 06:26:49PM -0800, David Schwartz wrote: Edward Diener wrote: 1) You need someone to confirm that having a client use a known-compromised private key to authenticate over SSL is no worse than the client using no key at all. It seems to me like you'd almost have to try to make this a problem, but who knows -- maybe it's never been thought about. Whether a client private key is used or no client key at all, there is still the issue of figuring out the username/password. No, there isn't. If using a known-compromised client key compromises the SSL connection, then an attacker can get a username/password simply by reading it out of a compromised SSL connection. No such compromise happens, so this is not relevant. Compromised client keys don't compromise SSL provided the server key is secured and the server does not rely on client certificates for client authentication. Which, by one of his recent posts, is where Edward Diener is at now - He went off to re-examine the GRANT statements and options in the server side of his application. The confusion seems to be based in the MySQL reference manual example of setting up secure communications. It does not specify which parts of the example are required and which are optional depending on GRANT settings. Just as one could reasonably suspect, MySQL is perfectly capable of using a SSL secured communications link and leaving the client authentication to something other than a client side certificate. It is just that stinking example in the reference manual that makes MySQL users think otherwise. ;) Mike OT: I wonder how many other products have now aim at your foot directions? On another note, something still seems fundamentally wrong with your approach. Since every customer has a username/password, and you don't trust your customers, you still cannot allow someone to mess with an arbitrary data just because he has a valid username/password. We've hashed this part out already, let's not go there again. __ 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
David Schwartz wrote: I can understand your summary quite clearly. Great. Suppose the server encrypts data it sends to the client and the client needs to decrypt that data. This is the case when my client SELECTs data from the MySQL database. Does this need a different sequence than the sequence mentioned above, where the client sends the server the client's public key so that the server uses it to encrypt data before sending it to the client who decrypts it using the client's private key ? Or can the same server public-private key be used as you originally specified ? Once session establishment is completed, the client and the server have a shared secret. This is some chunk of data that only the server and the client know. Each side can use the shared secret to encrypt data that only the other side can decrypt. They typically do so using a symmetric encryption algorithm such as AES or RC4. OK, I understand this now. The original public key-private key is only used for session establishment, after which the 'shared secret' is always used to encrypt/decrypt data. The reason I ask this is that MySQL, in setting up certificates, specifies a public key-private key pair for both the server and any given client. My original thought on seeing this is that this is necessary because both the client and the database server may encrypt/decrypt data. No, that's not why. That would simply be to allow the server to identify the client. If you have no need to do this, and already authenticate the client by some other means (such as username/password) you can probably not specify a client certificate. (It would be fairly unusual to absolutely require one in a case where there is some other way to authenticate the client.) MySQL does use a username/password to access the database server. So it sounds like the entire client certificate in MySQL should be unnecessary, although optional. But others seem to imply that only the server public key-private key pair is necessary. That would be the usual situation. In which case if this is true, when the server sends encrypted data to the client which the client must decrypt, the data must be encryoted with the server's private key and decrypted by the client with the server's public key, therefore reversing the role of the public key-private key for encrypting/decrypting data you mention above. No. That would be hideously inefficient. The public/private keys are only used during session establishment. Thanks for the information. Evidently MySQL works with both the server and a given client both having a public key-private key pair. In using the MySQL client library API I must pass the paths to my client certificates as SSL options to a client library connection object before making a SSL connection to the server. After that everything works automatically to encrypt/decrypr data between the client and the database server. Really? It absolutely requires a client certificate? Why not just have the client make up a self-signed certificate then? I just did some research, yes, you are correct. This is a known deficiency of MySQL's SSL support, first reported in 2003! Bug number 2233. From reading this bug and related bugs, there appears to be a lot of weirdness in MySQL's usage of OpenSSL to perform transport encryption. I wonder if there has been any kind of security review. Perhaps your seeing this shows why I was at least nominally concerned about the MySQL client having its own public key-private key certificates. I have tried to find out what actual use the client's public key-private key has in MySQL, from either the client or the server's point of view, but to no avail since no one involved with MySQL answers questions about SSL and the documentation that comes with MySQL does not explain the use MySQL may have for the client certs. Evidently the only way to get any answers about MySQL and SSL is to pay Sun for the Enterprise version rather than use the free version. My employer is considering this. Thanks for all your patient help. I will report to my employer what I have learned in this NG and I will investigate cryptography and certificates further via the books others have recommended. __ 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 Thu January 1 2009, Edward Diener wrote: Perhaps your seeing this shows why I was at least nominally concerned about the MySQL client having its own public key-private key certificates. I have tried to find out what actual use the client's public key-private key has in MySQL, from either the client or the server's point of view, but to no avail since no one involved with MySQL answers questions about SSL and the documentation that comes with MySQL does not explain the use MySQL may have for the client certs. Evidently the only way to get any answers about MySQL and SSL is to pay Sun for the Enterprise version rather than use the free version. My employer is considering this. Ah, but Google knows the answer. ;) (Try the on-line Reference Manual) [quoting 5.5.7.1] As for using certificates to replace passwords, yes, it can be done. Following the instructions in the Mysql documentation for GRANT options, do something like the following: GRANT SELECT, INSERT, UPDATE ON database.* TO new_user@'hostname' REQUIRE X509; [/quote] Although not clear there, digging deeper finds that it is the REQUIRE X509 option that makes the client side certificate required. There are other options which do not; I did not run those references down myself. To increase the confusion, the reference manual on setting up SSL (using openSSL) gayly trips right along and has the reader create the _client side_ key pair - - Rhetorical: What part of Private do the reference manual authors not understand? So I would suggest digging into the MySQL documentation, find GRANT options that give you the control you want and possibly even skip the entire question of client-side things to hide from the client. ;) Mike __ 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 Thu January 1 2009, Michael S. Zick wrote: http://dev.mysql.com/doc/refman/5.1/en/grant.html On Thu January 1 2009, Edward Diener wrote: Perhaps your seeing this shows why I was at least nominally concerned about the MySQL client having its own public key-private key certificates. I have tried to find out what actual use the client's public key-private key has in MySQL, from either the client or the server's point of view, but to no avail since no one involved with MySQL answers questions about SSL and the documentation that comes with MySQL does not explain the use MySQL may have for the client certs. Evidently the only way to get any answers about MySQL and SSL is to pay Sun for the Enterprise version rather than use the free version. My employer is considering this. Ah, but Google knows the answer. ;) (Try the on-line Reference Manual) [quoting 5.5.7.1] As for using certificates to replace passwords, yes, it can be done. Following the instructions in the Mysql documentation for GRANT options, do something like the following: GRANT SELECT, INSERT, UPDATE ON database.* TO new_user@'hostname' REQUIRE X509; [/quote] Although not clear there, digging deeper finds that it is the REQUIRE X509 option that makes the client side certificate required. There are other options which do not; I did not run those references down myself. To increase the confusion, the reference manual on setting up SSL (using openSSL) gayly trips right along and has the reader create the _client side_ key pair - - Rhetorical: What part of Private do the reference manual authors not understand? So I would suggest digging into the MySQL documentation, find GRANT options that give you the control you want and possibly even skip the entire question of client-side things to hide from the client. ;) Mike __ 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
Edward Diener wrote: Perhaps your seeing this shows why I was at least nominally concerned about the MySQL client having its own public key-private key certificates. I have tried to find out what actual use the client's public key-private key has in MySQL, from either the client or the server's point of view, but to no avail since no one involved with MySQL answers questions about SSL and the documentation that comes with MySQL does not explain the use MySQL may have for the client certs. The ideal solution would be for you to issue each customer their own X.509 certificate signed by your own CA. You can then identify each customer just by certificate. This is how, I think, it was all intended to work. Using things the way they are intended to work means that you don't have any unique security issues, which is good. A more practical solution might be to just give every client the exact same certificate, public key, and 'private' key. Make no attempt to keep this a secret. Do not rely on it for anything. Just grant privileges by username/password, not by X.509 certificate. There are two potential risks with this approach: 1) You need someone to confirm that having a client use a known-compromised private key to authenticate over SSL is no worse than the client using no key at all. It seems to me like you'd almost have to try to make this a problem, but who knows -- maybe it's never been thought about. 2) You need someone to confirm that MySQL doesn't specifically have some odd issue with this non-standard setup. Alternatively, you can hack your own MySQL code to not require or request client authentication. To a lesser extent, you still have problem '2'. You could hack just your MySQL server not to request client authentication. Give the client's some garbage key/cert (just because the client library insists), but the server won't request it, so I don't think they'll use it at all. You can leave the MySQL client libraries alone. You could also put a proxy in front of your MySQL server. The proxy won't request any client authentication on the customer-facing SSL connections. Good luck. 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
Michael S. Zick wrote: On Thu January 1 2009, Edward Diener wrote: Perhaps your seeing this shows why I was at least nominally concerned about the MySQL client having its own public key-private key certificates. I have tried to find out what actual use the client's public key-private key has in MySQL, from either the client or the server's point of view, but to no avail since no one involved with MySQL answers questions about SSL and the documentation that comes with MySQL does not explain the use MySQL may have for the client certs. Evidently the only way to get any answers about MySQL and SSL is to pay Sun for the Enterprise version rather than use the free version. My employer is considering this. Ah, but Google knows the answer. ;) (Try the on-line Reference Manual) [quoting 5.5.7.1] As for using certificates to replace passwords, yes, it can be done. Following the instructions in the Mysql documentation for GRANT options, do something like the following: GRANT SELECT, INSERT, UPDATE ON database.* TO new_user@'hostname' REQUIRE X509; [/quote] I do not find the quote above in the 5.5.7.1 section of the MySQL documentation. I do see some links to the MySQL GRANT statement in sections under 5.5.7. Although not clear there, digging deeper finds that it is the REQUIRE X509 option that makes the client side certificate required. There are other options which do not; I did not run those references down myself. I see that in the MySQL GRANT statement it is possible to setup just a REQUIRE SSL rather than a REQUIRE X509. This might allow me to just pass the CA certificate issued to the client. I can try that. To increase the confusion, the reference manual on setting up SSL (using openSSL) gayly trips right along and has the reader create the _client side_ key pair - - Rhetorical: What part of Private do the reference manual authors not understand? So I would suggest digging into the MySQL documentation, find GRANT options that give you the control you want and possibly even skip the entire question of client-side things to hide from the client. ;) Thanks for pointing this out to me. I did read the 5.5.7 part of the manual but I did not make the connection between the client certs and the REQUIRE X509 option of the GRANT statement because I did not pursue the GRANT statement and its REQUIRE option. I do not know if programatically I can pass only the CA cert, if the GRANT statement only has a REQUIRE SSL, and still have an SSL connection work properly but at least I can try and see if this works. __ 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
David Schwartz wrote: Edward Diener wrote: Perhaps your seeing this shows why I was at least nominally concerned about the MySQL client having its own public key-private key certificates. I have tried to find out what actual use the client's public key-private key has in MySQL, from either the client or the server's point of view, but to no avail since no one involved with MySQL answers questions about SSL and the documentation that comes with MySQL does not explain the use MySQL may have for the client certs. The ideal solution would be for you to issue each customer their own X.509 certificate signed by your own CA. You can then identify each customer just by certificate. This is how, I think, it was all intended to work. Using things the way they are intended to work means that you don't have any unique security issues, which is good. This would be ideal if someone broke into the database to do disruptive things. Then I imagine it might be possible, via database logs, to determine who that person might be based on the individual client certs. I think this is what you mean by your second sentence above. A more practical solution might be to just give every client the exact same certificate, public key, and 'private' key. Make no attempt to keep this a secret. Do not rely on it for anything. Just grant privileges by username/password, not by X.509 certificate. This is what we are doing now. Admittedly it is a little less safe than the ideal solution above, since a disruptive hacker need only obtain the one common certificate, public key, private key in order to try to compromise the database if he could figure out the username/password. There are two potential risks with this approach: 1) You need someone to confirm that having a client use a known-compromised private key to authenticate over SSL is no worse than the client using no key at all. It seems to me like you'd almost have to try to make this a problem, but who knows -- maybe it's never been thought about. Whether a client private key is used or no client key at all, there is still the issue of figuring out the username/password. 2) You need someone to confirm that MySQL doesn't specifically have some odd issue with this non-standard setup. I have to test out whether I can pass just the CA cert as an SSL option to the connection object, and have this make an SSL connection if just the REQUIRE SSL option of the GRANT statement is used. Alternatively, you can hack your own MySQL code to not require or request client authentication. To a lesser extent, you still have problem '2'. See just above. You could hack just your MySQL server not to request client authentication. Give the client's some garbage key/cert (just because the client library insists), but the server won't request it, so I don't think they'll use it at all. You can leave the MySQL client libraries alone. Granted, but hacking MySQL server is not my idea of fun programming g. You could also put a proxy in front of your MySQL server. The proxy won't request any client authentication on the customer-facing SSL connections. This also seems like much work. Thanks for the suggestions. __ 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 Thu January 1 2009, Edward Diener wrote: Michael S. Zick wrote: On Thu January 1 2009, Edward Diener wrote: Perhaps your seeing this shows why I was at least nominally concerned about the MySQL client having its own public key-private key certificates. I have tried to find out what actual use the client's public key-private key has in MySQL, from either the client or the server's point of view, but to no avail since no one involved with MySQL answers questions about SSL and the documentation that comes with MySQL does not explain the use MySQL may have for the client certs. Evidently the only way to get any answers about MySQL and SSL is to pay Sun for the Enterprise version rather than use the free version. My employer is considering this. Ah, but Google knows the answer. ;) (Try the on-line Reference Manual) [quoting 5.5.7.1] As for using certificates to replace passwords, yes, it can be done. Following the instructions in the Mysql documentation for GRANT options, do something like the following: GRANT SELECT, INSERT, UPDATE ON database.* TO new_user@'hostname' REQUIRE X509; [/quote] I do not find the quote above in the 5.5.7.1 section of the MySQL documentation. I do see some links to the MySQL GRANT statement in sections under 5.5.7. I was reading that in the version 5.0 on-line document, but did not check the other versions. The link that I did post has a buried link in the page to the 5.5.7.1 section I quoted. Although not clear there, digging deeper finds that it is the REQUIRE X509 option that makes the client side certificate required. There are other options which do not; I did not run those references down myself. I see that in the MySQL GRANT statement it is possible to setup just a REQUIRE SSL rather than a REQUIRE X509. This might allow me to just pass the CA certificate issued to the client. I can try that. That is the way I read the manual also - Note the 'ssl' option only requires the --ssl-ca client option; and that the 'x509' option is very explicitly different. But that is one long page - you may wear out your 'page down' button. ;) I suspect that manual section on setting up SSL using the openSSL tool, where it just falls into making the client side stuff without mentioning that part is optional (depending on GRANT options) has confused the subject. To increase the confusion, the reference manual on setting up SSL (using openSSL) gayly trips right along and has the reader create the _client side_ key pair - - Rhetorical: What part of Private do the reference manual authors not understand? So I would suggest digging into the MySQL documentation, find GRANT options that give you the control you want and possibly even skip the entire question of client-side things to hide from the client. ;) Thanks for pointing this out to me. I did read the 5.5.7 part of the manual but I did not make the connection between the client certs and the REQUIRE X509 option of the GRANT statement because I did not pursue the GRANT statement and its REQUIRE option. I do not know if programatically I can pass only the CA cert, if the GRANT statement only has a REQUIRE SSL, and still have an SSL connection work properly but at least I can try and see if this works. According to my browsing, that is what 'ssl' does, enable encrypted connection and leaves it up to some other method (username/password) to ident the user. (Think: https access to a site, and basic user/pass identification on a page.) Should work just like what I think you want. But I admit I am guessing. ;) Mike __ 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
Edward Diener wrote: 1) You need someone to confirm that having a client use a known-compromised private key to authenticate over SSL is no worse than the client using no key at all. It seems to me like you'd almost have to try to make this a problem, but who knows -- maybe it's never been thought about. Whether a client private key is used or no client key at all, there is still the issue of figuring out the username/password. No, there isn't. If using a known-compromised client key compromises the SSL connection, then an attacker can get a username/password simply by reading it out of a compromised SSL connection. On another note, something still seems fundamentally wrong with your approach. Since every customer has a username/password, and you don't trust your customers, you still cannot allow someone to mess with an arbitrary data just because he has a valid username/password. Being able to find the guilty party after a compromise is certainly one part of security. But when you design a security system, it's more important to make compromise difficult. No sane person would argue, I don't need locks on my doors because I have a camera pointing at it. 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
On Thu, Jan 01, 2009 at 06:26:49PM -0800, David Schwartz wrote: Edward Diener wrote: 1) You need someone to confirm that having a client use a known-compromised private key to authenticate over SSL is no worse than the client using no key at all. It seems to me like you'd almost have to try to make this a problem, but who knows -- maybe it's never been thought about. Whether a client private key is used or no client key at all, there is still the issue of figuring out the username/password. No, there isn't. If using a known-compromised client key compromises the SSL connection, then an attacker can get a username/password simply by reading it out of a compromised SSL connection. No such compromise happens, so this is not relevant. Compromised client keys don't compromise SSL provided the server key is secured and the server does not rely on client certificates for client authentication. On another note, something still seems fundamentally wrong with your approach. Since every customer has a username/password, and you don't trust your customers, you still cannot allow someone to mess with an arbitrary data just because he has a valid username/password. We've hashed this part out already, let's not go there again. -- 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
Edward Diener el...@tropicsoft.com writes: [...] In this last case I do not understand how the client can encrypt data going to the server if it has no private key of its own. Each combination of algorithms that can be used when only one party has a key must provide some way to do this. When RSA is used and only one party has a private key, the party without the key (usually the client) generates a secret, then sends it to the server using its public key. The client knows the secret because it made it up. The server knows the secret because it can decrypt it with its private key. But an observer cannot figure out the secret, so it is secure. This secret is used as part of the key generation process, and the generated key can be used with a conventional symmetric cipher (like DES or AES) to communicate securely. Alternately, the Diffie-Hellman(-Merkle) key-exchange protocol can be used to establish a shared secret. See the Wikipedia entry: http://en.wikipedia.org/wiki/Diffie-Hellman These are the two most commonly used ways. [...] For what books do I look to specifically understand how these certificates work with public key-private key pairs ? SSL books ? Cryptography public key-private key books ? For a general understanding of cryptography, I learned from Bruce Schneier's Applied Cryptography. That provided enough basic background information to get me by for a number of years. Recently I'm having to understand more of the details, and I'm reading Eric Rescorla's SSL and TLS: Designing and Building Secure Systems to learn about the SSL protocol, and the O'Reilly book Network Security with OpenSSL to learn about the OpenSSL library and its API. Hope that helps! Scott. __ 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
Edward Diener wrote: In this last case I do not understand how the client can encrypt data going to the server if it has no private key of its own. Your question is kind of puzzling. Why would the client needs its own private key in order to encrypt data going to the server? In general, private keys are used for decrypting. During the SSL session establishment phase, the client can encrypt data using the server's public key. Basically, it goes like this: 1) The client connects to the server. 2) The server sends the client its public key and certificate(s). 3) The client validates the certificates and public key and confirms that it has reached the correct server. At this point, the client has the server's public key and knows that it has the public key of the server it wishes to talk to. So it can encrypt data using that public key and send it securely to the server. Since only the appropriate server has the corresponding private key (that's what the CA has attested to, at least), the client knows that only its intended recipient can decrypt what it sends. This completes the first phase of the session establishment. Logically the phases are (assuming a typical SSL use -- a browser connects to a secure web server with a certificate issued by a typical CA): 1) The client connects to the server. 2) The server sends the client the server's public key and certificate. 3) The client verifies the certificate's validity and appropriateness: Is it for the web site we intended to reach? Was it issued by a CA we trust? Does the public key given match the certificate? 4) The client challenges the server to decrypt something that the client has encrypted using the server's public key. 5) The server proves to the client that it can decrypt what the client sent and establishes a shared secret with the client. The client now knows that it is talking to an entity that owns the private key correspondending to the public key it knows belongs to the server it wishes to talk to. 6) The client and server use the new shared secret to converse securely using a symmetric encryption scheme. Note that the server has no idea who it is talking to. Typically, the client will validate its identity using a username and password sent over the secure connection. But SSL does support the client sending its own certificate and proving that it owns the private key corresponding to the public key in the client's certificate (using more or less the same process used above). In that case, each party knows who it is speaking to when session establishment completes. 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
David Schwartz wrote: Edward Diener wrote: In this last case I do not understand how the client can encrypt data going to the server if it has no private key of its own. Your question is kind of puzzling. Why would the client needs its own private key in order to encrypt data going to the server? In general, private keys are used for decrypting. That was my misunderstanding. You are correct. During the SSL session establishment phase, the client can encrypt data using the server's public key. Basically, it goes like this: 1) The client connects to the server. 2) The server sends the client its public key and certificate(s). 3) The client validates the certificates and public key and confirms that it has reached the correct server. At this point, the client has the server's public key and knows that it has the public key of the server it wishes to talk to. So it can encrypt data using that public key and send it securely to the server. Since only the appropriate server has the corresponding private key (that's what the CA has attested to, at least), the client knows that only its intended recipient can decrypt what it sends. This completes the first phase of the session establishment. Logically the phases are (assuming a typical SSL use -- a browser connects to a secure web server with a certificate issued by a typical CA): 1) The client connects to the server. 2) The server sends the client the server's public key and certificate. 3) The client verifies the certificate's validity and appropriateness: Is it for the web site we intended to reach? Was it issued by a CA we trust? Does the public key given match the certificate? 4) The client challenges the server to decrypt something that the client has encrypted using the server's public key. 5) The server proves to the client that it can decrypt what the client sent and establishes a shared secret with the client. The client now knows that it is talking to an entity that owns the private key correspondending to the public key it knows belongs to the server it wishes to talk to. 6) The client and server use the new shared secret to converse securely using a symmetric encryption scheme. I can understand your summary quite clearly. Suppose the server encrypts data it sends to the client and the client needs to decrypt that data. This is the case when my client SELECTs data from the MySQL database. Does this need a different sequence than the sequence mentioned above, where the client sends the server the client's public key so that the server uses it to encrypt data before sending it to the client who decrypts it using the client's private key ? Or can the same server public-private key be used as you originally specified ? The reason I ask this is that MySQL, in setting up certificates, specifies a public key-private key pair for both the server and any given client. My original thought on seeing this is that this is necessary because both the client and the database server may encrypt/decrypt data. But others seem to imply that only the server public key-private key pair is necessary. In which case if this is true, when the server sends encrypted data to the client which the client must decrypt, the data must be encryoted with the server's private key and decrypted by the client with the server's public key, therefore reversing the role of the public key-private key for encrypting/decrypting data you mention above. Note that the server has no idea who it is talking to. Typically, the client will validate its identity using a username and password sent over the secure connection. But SSL does support the client sending its own certificate and proving that it owns the private key corresponding to the public key in the client's certificate (using more or less the same process used above). In that case, each party knows who it is speaking to when session establishment completes. Thanks for the information. Evidently MySQL works with both the server and a given client both having a public key-private key pair. In using the MySQL client library API I must pass the paths to my client certificates as SSL options to a client library connection object before making a SSL connection to the server. After that everything works automatically to encrypt/decrypr data between the client and the database server. __ 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
Scott Gifford wrote: Edward Diener el...@tropicsoft.com writes: [...] [...] For what books do I look to specifically understand how these certificates work with public key-private key pairs ? SSL books ? Cryptography public key-private key books ? For a general understanding of cryptography, I learned from Bruce Schneier's Applied Cryptography. That provided enough basic background information to get me by for a number of years. Recently I'm having to understand more of the details, and I'm reading Eric Rescorla's SSL and TLS: Designing and Building Secure Systems to learn about the SSL protocol, and the O'Reilly book Network Security with OpenSSL to learn about the OpenSSL library and its API. Thanks for the list of books. O'Reilly only lists the last of the three you mentioned so I will look for the other two elsewhere online. __ 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
I can understand your summary quite clearly. Great. Suppose the server encrypts data it sends to the client and the client needs to decrypt that data. This is the case when my client SELECTs data from the MySQL database. Does this need a different sequence than the sequence mentioned above, where the client sends the server the client's public key so that the server uses it to encrypt data before sending it to the client who decrypts it using the client's private key ? Or can the same server public-private key be used as you originally specified ? Once session establishment is completed, the client and the server have a shared secret. This is some chunk of data that only the server and the client know. Each side can use the shared secret to encrypt data that only the other side can decrypt. They typically do so using a symmetric encryption algorithm such as AES or RC4. The reason I ask this is that MySQL, in setting up certificates, specifies a public key-private key pair for both the server and any given client. My original thought on seeing this is that this is necessary because both the client and the database server may encrypt/decrypt data. No, that's not why. That would simply be to allow the server to identify the client. If you have no need to do this, and already authenticate the client by some other means (such as username/password) you can probably not specify a client certificate. (It would be fairly unusual to absolutely require one in a case where there is some other way to authenticate the client.) But others seem to imply that only the server public key-private key pair is necessary. That would be the usual situation. In which case if this is true, when the server sends encrypted data to the client which the client must decrypt, the data must be encryoted with the server's private key and decrypted by the client with the server's public key, therefore reversing the role of the public key-private key for encrypting/decrypting data you mention above. No. That would be hideously inefficient. The public/private keys are only used during session establishment. Thanks for the information. Evidently MySQL works with both the server and a given client both having a public key-private key pair. In using the MySQL client library API I must pass the paths to my client certificates as SSL options to a client library connection object before making a SSL connection to the server. After that everything works automatically to encrypt/decrypr data between the client and the database server. Really? It absolutely requires a client certificate? Why not just have the client make up a self-signed certificate then? I just did some research, yes, you are correct. This is a known deficiency of MySQL's SSL support, first reported in 2003! Bug number 2233. From reading this bug and related bugs, there appears to be a lot of weirdness in MySQL's usage of OpenSSL to perform transport encryption. I wonder if there has been any kind of security review. 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 Mon, Dec 29, 2008 at 12:55:14AM -0500, Edward Diener wrote: My assumptions from what I could glean from the certificates distributed is that the CA-cert.pem is the same for client and server, while the server-cert.pem is a public key corresponding to the private client-key.pem, and the server-key is a private key corresponding to the public client-cert. When I say corresponding I mean that they form a public-private key pair. No it is simpler than that: For each (one or a few) server: - a server-cert.pem corresponds to a server-key.pem - in some deployments all servers share the same server cert and key - best practice is to generate the server keys on the server, and then obtain a CA cert for the public key (certificate request). For each (often many) clients: - a client-cert.pem corresponds to a client-key.pem - each and every client key and corresponding certificate pair are distinct from all other such pairs. - best practice is to generate the client keys on each client, and then obtain a CA cert for the public key (certificate request), you need to bootstrap secure (authenticated) delivery of the client CSR from the client to signing CA. The CA need not be a public CA, there is often little value in using a public CA in this context. - Client certificates are OPTIONAL. You can just encrypt the connection to the server and login with username/password. Makes sense. Thanks for the info. In fact from all the noise in this thread, it seems that simplicity is a major win whenever complexity is confusing, so dispense with the client certs entirely and go with username/password. TLS will just encrypt the login session and authenticate the server. In this last case I do not understand how the client can encrypt data going to the server if it has no private key of its own. If this is true then my client has a private key in its client-key.pem certificate. The premise is badly mangled, so it is difficult to comment on the conclusion. Your confusion is not OpenSSL confusion, it is basic lack of experience with public/private key security protocols and the roles the various keys play. Neither OpenSSL users, nor GnuTLS users, nor Microsoft CryptoAPI users, ... are specifically the right people to burden with your question. Are these certificates specifically SSL certificates or are they more broadly public key-private key certificates ? This is a general question about communication's security and requires independent research via books or a general security help forum. For what books do I look to specifically understand how these certificates work with public key-private key pairs ? SSL books ? Cryptography public key-private key books ? I am perfectly willing to learn, since I am a very fast learner, but I need to know where specifically to look. I do not want to have to learn all the details about computer security and cryptography, although that might be interesting in and of itself, but I do want to understand all the details about public key-private key and certificates. Unfortunately the MySQL documenation offers very little, which was the main reason for my OP on this NG. __ 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 Tue, Dec 30, 2008 at 02:26:20PM -0500, Edward Diener wrote: Victor Duchovni wrote: On Mon, Dec 29, 2008 at 12:55:14AM -0500, Edward Diener wrote: My assumptions from what I could glean from the certificates distributed is that the CA-cert.pem is the same for client and server, while the server-cert.pem is a public key corresponding to the private client-key.pem, and the server-key is a private key corresponding to the public client-cert. When I say corresponding I mean that they form a public-private key pair. No it is simpler than that: For each (one or a few) server: - a server-cert.pem corresponds to a server-key.pem - in some deployments all servers share the same server cert and key - best practice is to generate the server keys on the server, and then obtain a CA cert for the public key (certificate request). For each (often many) clients: - a client-cert.pem corresponds to a client-key.pem - each and every client key and corresponding certificate pair are distinct from all other such pairs. - best practice is to generate the client keys on each client, and then obtain a CA cert for the public key (certificate request), you need to bootstrap secure (authenticated) delivery of the client CSR from the client to signing CA. The CA need not be a public CA, there is often little value in using a public CA in this context. - Client certificates are OPTIONAL. You can just encrypt the connection to the server and login with username/password. Makes sense. Thanks for the info. In fact from all the noise in this thread, it seems that simplicity is a major win whenever complexity is confusing, so dispense with the client certs entirely and go with username/password. TLS will just encrypt the login session and authenticate the server. In this last case I do not understand how the client can encrypt data going to the server if it has no private key of its own. And yet it is possible, read up on Diffie-Hellman key-exchange. And learn more about SSL/TLS. You browse https websites with no private key of your own... Your confusion is not OpenSSL confusion, it is basic lack of experience with public/private key security protocols and the roles the various keys play. Neither OpenSSL users, nor GnuTLS users, nor Microsoft CryptoAPI users, ... are specifically the right people to burden with your question. Are these certificates specifically SSL certificates or are they more broadly public key-private key certificates ? SSL != OpenSSL. And X.509 certificates are applicable more broadly than OpenSSL (e.g. IPSec and S/MIME). This is a general question about communication's security and requires independent research via books or a general security help forum. For what books do I look to specifically understand how these certificates work with public key-private key pairs ? SSL books ? Cryptography public key-private key books ? I am perfectly willing to learn, since I am a very fast learner, but I need to know where specifically to look. I do not want to have to learn all the details about computer security and cryptography, although that might be interesting in and of itself, but I do want to understand all the details about public key-private key and certificates. Unfortunately the MySQL documenation offers very little, which was the main reason for my OP on this NG. This mailing list is primarly for programmers developing applications that incorporate the OpenSSL APIs. Users of SSL-enabled products should generally seek help elsewhere, unless there is a specific issue with OpenSSL tools used in conjunction with said SSL-enabled products. The list is called OpenSSL-users, not SSL-users. -- 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 Fri, Dec 26, 2008 at 7:28 PM, Edward Diener el...@tropicsoft.com wrote: If I can get a little finicky, the application needs access to the database/server. Nobody else should be accessing it. But I am sure that is what you meant. The clients are to be trusted using the application. My employer, not I, felt that putting the certificates where a client, who might be a destructive hacker, could easily access them, might be a security risk. He was told this by a Sun rep whom he knows, so naturally he wanted me to find out if this was the case. I come on this forum to ask, and what I get, not from you, is some good information mixed with a bunch of heavy ego which wants to tell me that only security experts are qualified to understand the deep issues involved and that since I have not proved myself a security expert simply by asking my question I should not even be dealing in any way with security problems, much less this current simple one. Well, on the surface it may look like that, but it isn't an attempt to cut you down. I've been lurking on this list for a decade and only recently decided I'm (ahem) 'qualified' to answer simple questions. The same folks who answered you have, directly and indirectly, taught me a lot over the years. I don't know how to explain this in 'layman terms', but security/cryptography is a peculiar field of engineering, which I might compare to space/aeronautics engineering (I have a mech. engineering background myself, but that was a previous [short] life). Mechanical engineers are aware they can screw up, just like software engineers, and they 'fix' this by introducing 'safety margins': steel a little thicker, a bigger hammer than really necessary, that sort of thing. 'Slack' (though everyone uses different terms for it, as 'slack' doesn't sound really engineery, you see? ;-) ) Anyway, aeronautics engineers, like crypto securirty engineers, simply are not allowed 'slack'. Ever. If you fail, as a software engineer, it's a 'bug'. In the design, or somewhere else. No big fuss, compared to a little 'bug' in a rocket or space shuttle going up. It's instant death (we have seen that) or at least huge losses and delays, due to a little flaw. Same with security: you can't 'fix' it with a little chewing gum; it has to be _right_ from the get go. Hence, 'dabbling' in security or crypto (which quite a few folks are doing when they visit this list with their questions) raises some serious concerns with the folks who know their stuff. This is a field where you can't 'learn by doing' but have to learn through watching and listening. The advise to 'hire a security expert' is very well meant: it's the above verbiage, and then some, boiled down into a single line: this kind of stuff requires another pair of eyes on the spot; a pair of eyes attached to a brain which knows this stuff inside and out. It's an expensive piece of advice and it headbutts all kinds of egos, but anything less is equivalent to still using a rubber ring which should have been discarded as overaged, while saying, aw, shucks, it's all right! See, no cracks! And still stretches like it ought to! The mechanic saying that won't feel the hurt, but you can bet your behind in a little while that plane will make an unauthorized drop out of the sky and some other folks will have some unscheduled catching up to do at St. Peter's. Security is like that: if you don't do your stinkin' best and use the best tools and practices you can get, you might as well not bother at all. [...] If the client loses, ie. destroys or changes, the certs, the application will not work. That is fine by my employer since it is much the same as the client destroying a DLL distributed with the application. The client has messed up and does not deserve a working application. Hm, you have me wondering how I can make you see. (Besides, with 'losing' I meant: a colleague, friend, acquaintance, whoever else, stumbles across his keys, intentionally or not.) Say you want to protect your database, as a system. I.e. you want to ensure the database will remain acting predictable, according to your decisions, plus it's data must not be 'damaged' by having someone put data in there which you did not authorize, nor alter any bit of data in an unauthorized way. Your hypothetical goal here: keep the database functioning as best as possible AND making sure the data in there is as unpoluted as possible as well. (Note: I do not mention 'unauthorized data retrieval' here as part of the example; that adds some important additional requirements, which complicate matters quite a bit. Let's stick with this example: no system damage; no data polution.) Security-wise -- and please note that I am not a security expert; that means I'll probably miss a few important bits here -- it goes like this: the database/server is the piece you wish to protect. So you sit yourself in that machine and look out. What and who do you see? First off all, you should only
Re: Where to store client PEM certificates for an application
On Sun December 28 2008, Ger Hobbelt wrote: And all that fuss, just because you've woken up and inquired about security / protection technology, instead of ignoring the subject and waiting for a nasty surprise down the road. Dang! ;-)) You did well to ask, indeed. Even if the result might have been similar to someone accidentally stepping onto a fire ant hill. ;) Each poster has attempted to give you information, each in their own way - regardless of how it may have read to your eyes. And on an openSSL mailing list, when you don't even use openSSL. Myself, I rarely post here, just read along - - Will probably go back to doing that after this thread. Probably should. ;) But my background (in a long ago, prior lifetime) was that of a Communications Security Account Custodian for a government account. Don't be impressed by the title - it just designates the person they take out back and shoot when things go wrong. But from that background, I have to prod your thinking a bit further - - These are rhetorical questions: Can an Authorized User display data that they did not enter? (I.E: Data that someone else entered.) Can they transfer (even if only to paper) that information? If so, how is the distribution and custody of that paper representation handled and controlled? How about the similar activities on the input side - Is the data being entered previously transcribe somehow, in some form? Who has access to the prior data entry format and how is that handled and controlled? Remember: You _must_ consider the system from end-to-end (paper-to-paper?). You _may_ decide that a particular risk is not worth avoiding, but you _must_ consider it. Those questions are from an environment where _both_ sides of a piece of paper had to be inspected, inventoried, signed for, and accounted for during its entire physical existence. Same with its destruction. No: I shredded and burned side 1, surely I shredded and burned side 2 also allowed. _Both sides_ No. I am not joking. _Both sides_ (I once asked about the edges; of the wrong person! That was an education.) Hope you enjoyed Christmas anyhow. Merry Christmas. Next year's will be better than this one turned out. ;) Mike Cheers, Ger __ 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
Ger Hobbelt wrote: On Fri, Dec 26, 2008 at 7:28 PM, Edward Diener el...@tropicsoft.com wrote: I appreciate all the information you presented which I have snipped out in giving my response below. Money may be less of an issue than ease of use. This is a commercial application which however needs good security to protect the database data. There is no way the application is going to be sold to the public with some type of hardware security mechanism. I thought such mechanisms went out with the dinosaurs. 'good' is a 'taste' word; not a hard, measurable quantity. For a given level of 'good', one can tailor his processes and security around and inside those processes. All it takes is answering questions such as can we tolerate data corruption / pollution? System failure? Data loss? How 'public' is our data: who do we tolerate looking at our data? What can possibly go wrong, by accident or intention? And do we wish to survive such scenarios, which ones, and how uch effort are we willing to expend, before, during and after? And, funnily, during that QA process you will also discover what your (company's) actual desired definition of 'good' really is. And regarding dinosaurs: boy, are you in for a surprise! T.Rex is ruling. It's just that those serial/parallel port dongles have moved up in the world along with anything else computing; now we've got USB and, dear sir, we use it! ;-) Nowadays it looks to me like it's less 'per application' as more 'per use' security; single-sign-on being a big item, for example. But given ever-cheaper smartcards and tokens, contact and contact-less, the number of corporations using this tech is ever increasing. Anyway... Minimum book to read would be Schneier (applied Crypto); probably O'Reilly OpenSSL as well; after reading, reread the other responses in this thread for additional insight (I've been skimming the surface only and it's rather more hopping than surfing) and, yes, this will take some time and effort for you to do. I know of Schneier, although I have not read his books. I will also get the O'Reilly OpenSSL book, as the official OpenSSL documentation is not understandable by me. For now, in final closing, I'd say: - the only thing worth protecting is the private key of the client as it is the only 'secret' in the collection you distribute. The MySQL documentation about the certificates needed for SSL is really limiting and no question I have asked about what the certificates actually entail was ever answered on MySQL NGs/forums. My assumptions from what I could glean from the certificates distributed is that the CA-cert.pem is the same for client and server, while the server-cert.pem is a public key corresponding to the private client-key.pem, and the server-key is a private key corresponding to the public client-cert. When I say corresponding I mean that they form a public-private key pair. If this is true then my client has a private key in its client-key.pem certificate. - take the suggestion from elsewhere in this thread, since you already indicate 'tokens' are out, for user friendly reasons (I think you should check that reasoning again, but that's just me): distribute or otherwise 'derive' the passphrase required to decode that private key in software. I have to learn more about what these certificates contain. In MySQL I am doing nothing more than pointing to where these certificates exist in the application in order to connect. I do not attempt to manipulate the certificates themselves in any way, before passing them to MySQL, which is what you seem to be suggesting. If I need to know about passphrase and how to do what I am now doing to derive the passphrase on the fly, I have to go deeper into certificates, SSL, and OpenSSL. I am perfectly willing to do so but I must educate myself first. - accept that anyone with any access to that client machine is going to have client-level access to your server; from anywhere on the globe. Take measures to protect your server internally (damage prevention) by thoroughly checking user access limits The user in the case of MySQL is just my application, ie, whatever username/password is used to access the database whic I am hiding pretty well and is not in plaintext. It may of course be very possible to generate a hidden separate username/password for each end-user who registers the application, while at the same time adding that username/password to the database server, but at the present time that is not being done. It may of course be very possible to generate a separate set of client certificates for each user of the application, as someone has suggested but again I would have to study this because the server only has a single set of server certificates which communicate with all clients. Other than the username/password and the client/server certificates which ensure the SSL encryption/decryption of data, from the database server's perspective
Re: Where to store client PEM certificates for an application
On Mon, Dec 29, 2008 at 12:55:14AM -0500, Edward Diener wrote: My assumptions from what I could glean from the certificates distributed is that the CA-cert.pem is the same for client and server, while the server-cert.pem is a public key corresponding to the private client-key.pem, and the server-key is a private key corresponding to the public client-cert. When I say corresponding I mean that they form a public-private key pair. No it is simpler than that: For each (one or a few) server: - a server-cert.pem corresponds to a server-key.pem - in some deployments all servers share the same server cert and key - best practice is to generate the server keys on the server, and then obtain a CA cert for the public key (certificate request). For each (often many) clients: - a client-cert.pem corresponds to a client-key.pem - each and every client key and corresponding certificate pair are distinct from all other such pairs. - best practice is to generate the client keys on each client, and then obtain a CA cert for the public key (certificate request), you need to bootstrap secure (authenticated) delivery of the client CSR from the client to signing CA. The CA need not be a public CA, there is often little value in using a public CA in this context. - Client certificates are OPTIONAL. You can just encrypt the connection to the server and login with username/password. In fact from all the noise in this thread, it seems that simplicity is a major win whenever complexity is confusing, so dispense with the client certs entirely and go with username/password. TLS will just encrypt the login session and authenticate the server. If this is true then my client has a private key in its client-key.pem certificate. The premise is badly mangled, so it is difficult to comment on the conclusion. Your confusion is not OpenSSL confusion, it is basic lack of experience with public/private key security protocols and the roles the various keys play. Neither OpenSSL users, nor GnuTLS users, nor Microsoft CryptoAPI users, ... are specifically the right people to burden with your question. This is a general question about communication's security and requires independent research via books or a general security help forum. 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 Fri December 26 2008, Edward Diener wrote: Michael S. Zick wrote: On Fri December 26 2008, Edward Diener wrote: By 'dongle' do you mean a hardware 'dongle'. If it is a software dongle you need to spell out for me what you mean. There are a lot of devices being marketed for this purpose, but as an example that it needs to be neither complicated programming or an expensive solution: http://pdfserv.maxim-ic.com/en/an/app190.pdf The basics (no insult intended): Your client (or your application, on the client's behalf) generates a public/private key pair - The public part goes through the certification request process (with your server) that you are familiar with - The private part is never seen other than on the client machine during generation - The private part (or the key to its protective encryption) is stored in one (or more) of those shirt button devices. Once written and locked, short of peeling the silicon a few microns at a time under an electron microscope - it isn't ever going to be read. Some makes/models even have the stored data AES-256 encrypted, so even if peeled... The client can record _their_ private part in as many devices as they desire - and now they have a physical thing that any business knows how to protect from loss. Businesses well know how to protect something they can touch. I am not trying to push a specific product, only giving an example, even that one manufacturer makes a selection of products. Bottom line - you might be adding $20-$50 per button the client wants to have - you ship them blank - their software driver can write and lock them once the client has their private part ready. Note: There are laptops and desktops made that already read these 1-wire devices, or a USB based reader can be added to existing machines. Thanks for the information on these devices. I will mention this to the person for whom I work. The practical situation is that the device must be distributed to all end users who buy the application and they must install such a device on their computers. I do not think this is a viable solution for our application but I do understand that some people companies may use it for their application. They have to install your application also. Let the installation and/or registration process write the button also. You can't write the button for the client, you don't have the client's private key (the only thing worth protecting). The topic of the thread was where to store the client side security information; the answer is: in a hardware token. If your application handles financial, medical or medical billing information - perhaps for the work at home industry in my country; nothing less than a hardware token will do for the approval process. The application note was on an authentication device, but troll the product catalog, they make models for storing/protecting private keys. Or, you can find people who do the trolling and decision making for-hire. Mike __ 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 Sat, Dec 27, 2008 at 07:33:19AM -0600, Michael S. Zick wrote: They have to install your application also. Let the installation and/or registration process write the button also. You can't write the button for the client, you don't have the client's private key (the only thing worth protecting). The topic of the thread was where to store the client side security information; the answer is: in a hardware token. One answer is in a hardware token, but this is not the only answer. Let's not get too hung up on the details of the private key store. The OP has more important architectural issues to resolve first. Once those are dealt with, perhaps the security model will make it attractive to shield keys from disclosure via storage in hardware tokens, or perhaps the risk of compromise will not warrant the cost of hardware tokens. -- 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 Sat December 27 2008, Michael S. Zick wrote: The application note was on an authentication device, but troll the product catalog, they make models for storing/protecting private keys. Or, you can find people who do the trolling and decision making for-hire. Start here: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2822 Less than $6 each in quantity, about the size of a US Nickel. Of course, the ones shipped with your application need a 10x markup. ;) Enjoy. __ 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
Edward Diener: But other than vague remonstrances about security planning, and that I was not qualified as a mere programmer to handle security issues from people who have no idea about my ability, I have yet to receive any specifics from others about what they would do in this very common scenario to implement security for the data in the server database. First, it has nothing to do with you being a mere programmer. It has to do with the questions you are asking. If a person asks you what characteristics are important in a bridge building material, they should not be the person currently in charge of designing and building a traffic suspension bridge. As a programmer, you probably know that there are a large number of common errors that people frequently make the first time they do something. Well, the security field is an area particularly rich with such mistakes. You made two very serious ones just in the example code you posted. One of them would have caused your code to appear to work but not actually provide any security. I am a very experienced programmer/designer/architect and vague talk about security does not really impress me very much. Of course if you or others would like to get technical and mention what you feel are good technical solutions to any problems which entail private-key/public-key encryption, I am willing to listen and learn about things which I do not fully know or understand. Security doesn't work that way. It's part of system design, not the implementation of one small piece of a system. Once again the specific issue is that the MySQL server database has a certificate from a CA authority with a server public-private key and my client application was issued the same certificate from the CA authority with a a client public-private key. I need to pass the file location of the client CA certificate/public-key/private-key to the client side library in order to have an SSL connection to the database server where data passing between the client application and the server database is encrypted both ways. I told my employer that we should simply distribute the client CA certificate/public-key/private-key in the same application directory in which the rest of our modules reside. He had been told by someone from Sun that this was inherently bad security and, despite my arguing that this was not the case and that without the username/password to the database nothing could be accomplished even with the client side certs by a destructive hacker, he wanted me to investigate the issue. You have one private key that you distribute to all customers? And this is the private key on which a CA certificate was issued? Is that really what you're saying? I really hope I'm misunderstanding you and you mean something else by client CA certificate. From what others have written, I feel that I am right and coming up with elaborate schemes of hiding the client certs from the end-user until thay are actually going to be used by client application code in making the connection is largely a waste of time. Instead we should be ensuring that the server database and its data are protected from the prying eyes of a destructive hacker. You should ensure that if you give a user credentials, those credentials cannot be used to do anything the user should not be allowed to do. That way, there is no harm if a user compromises his own credentials, either accidentally or intentionally. You should not ever give a normal user anything that can be used to compromise either the server or another user's data. If you do not follow this, you are screwed no matter what you do. If you do follow this, you should have no need to hide a user's credentials from that user. 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
Mr Diener: This is, incidentally, why I call it security theater -- you're not gaining anything from the actions that you're going through, except warm and fuzzies of the people you're entertaining with it (in this case, your boss). You need to fix your server architecture, which is likely going to involve a lot of work -- work that you're not doing while you're searching for ways to hide authentication credentials which are subject to attack. Yes, it might prevent the casual user from doing it, but the casual user is also unlikely to know what to do with the credentials that he sees anyway. The advanced user will be able to find the credentials, and is more likely going to know how to write SQL to abuse the credentials than the casual user. The practical upshot of this is that you're protecting your infrastructure from people who wouldn't know how to attack it. This is more likely than not going to lead to your company feeling warm and fuzzy, that the system is safe from attack -- which is (ironically) going to lead to more security vulnerabilities that your company is not going to be on the lookout for. This could lead to catastrophic data loss and downtime while you try to figure out how the data in the tables managed to disappear out from under you -- and if the data is of sufficiently high value, it will more likely lead to the data being sucked down by attackers using the credentials. Since you have admitted that you don't have visibility with MySQL directly as to the queries it's receiving and processing, your company is a sitting duck against these types of attacks. If your company hires a security consultant, s/he will state the same thing. -Kyle H On Thu, Dec 25, 2008 at 6:49 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Dec 24, 2008 at 10:06:59PM -0500, Edward Diener wrote: 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 ? No, I am saying that applications where you don't trust the user are DRM problems. If you trust the user (not abuse, modify or replace) your application, then you don't need DRM, just authenticate trusted users by giving each user appropriate credentials (possibly a per-user private key, delivered separately from the application, via a secure enrollment process). -- Viktor. __ 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 your company hires a security consultant, s/he will state the same thing. -Kyle H The fundamental problem is this: You have one door. Every customer must walk through it. However, you don't want a customer to run amuck once he gets through the door. Your solution is to put more and more locks on the door, and give the customer the key to each one. All of these locks only keep people from going through the door. But the very people who you need to let through the door are the same ones you need to keep from running amuck once they get through the door. No amount of additional locks on the door will do this. You cannot give a person a credential that allows them to do things you must prevent them from doing. You must make it so that their credentials only allow them to do things you would like them to be able to do. It is unfortunate that you are in the position you are in, as it is a nearly hopeless one. Security cannot be added as an afterthought. It must be designed in from the very beginning. You must construct a threat model, state security requirements, and build into the design a way to meet those requirements and defeat all plausible threat models. Honestly, the type of schemes you are considering as band-aids are unlikely to slow down a determined attacker very long. I would bet dollars to donuts that the end result will take less than a day to break. Your scheme requires you to put the credentials where an attacker can get them in unencrypted form. All an attacker need do is terminate your process as soon as it attempts a network connection (or intercept its filesystem calls and snapshot every file before it is deleted or overwritten). Your scheme requires these credentials to be sufficient for someone to do harm. Bluntly, your scheme is hopeless from a security standpoint. 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
Kyle Hamilton wrote: Mr Diener: This is, incidentally, why I call it security theater -- you're not gaining anything from the actions that you're going through, except warm and fuzzies of the people you're entertaining with it (in this case, your boss). You need to fix your server architecture, which is likely going to involve a lot of work -- work that you're not doing while you're searching for ways to hide authentication credentials which are subject to attack. Please suggest ways to do so. The server is no different from any other server database. It accepts a username/password to prevent unauthorized users from accessing its data. I am perfectly willing to listen to other server techniques which involve security, or read about such techniques, but I need to be pointed to such things. Just generally saying what you say is not going to help me. I am open to specific suggestions if you want to give them. Yes, it might prevent the casual user from doing it, but the casual user is also unlikely to know what to do with the credentials that he sees anyway. The advanced user will be able to find the credentials, and is more likely going to know how to write SQL to abuse the credentials than the casual user. The practical upshot of this is that you're protecting your infrastructure from people who wouldn't know how to attack it. This is more likely than not going to lead to your company feeling warm and fuzzy, that the system is safe from attack -- which is (ironically) going to lead to more security vulnerabilities that your company is not going to be on the lookout for. This is not the psychology of the company for which I am working. This could lead to catastrophic data loss and downtime while you try to figure out how the data in the tables managed to disappear out from under you -- and if the data is of sufficiently high value, it will more likely lead to the data being sucked down by attackers using the credentials. Since you have admitted that you don't have visibility with MySQL directly as to the queries it's receiving and processing, your company is a sitting duck against these types of attacks. Why do you say Since you admitted... etc. ? The server database is accessible and manipulatable in whatever ways we want to manipulate it. If your company hires a security consultant, s/he will state the same thing. Thanks for your help but right now I am the programmer and security consultant, and therefore I must come up with security answers. Nonetheless I will mention to my employer that he might want to hire another person as a security consultant to deal with server side security issues. -Kyle H On Thu, Dec 25, 2008 at 6:49 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Dec 24, 2008 at 10:06:59PM -0500, Edward Diener wrote: 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 ? No, I am saying that applications where you don't trust the user are DRM problems. If you trust the user (not abuse, modify or replace) your application, then you don't need DRM, just authenticate trusted users by giving each user appropriate credentials (possibly a per-user private key, delivered separately from the application, via a secure enrollment process). -- Viktor. __ 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 __ 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
David Schwartz wrote: Kyle Hamilton wrote: If your company hires a security consultant, s/he will state the same thing. -Kyle H The fundamental problem is this: You have one door. Every customer must walk through it. However, you don't want a customer to run amuck once he gets through the door. Your solution is to put more and more locks on the door, and give the customer the key to each one. All of these locks only keep people from going through the door. But the very people who you need to let through the door are the same ones you need to keep from running amuck once they get through the door. No amount of additional locks on the door will do this. You cannot give a person a credential that allows them to do things you must prevent them from doing. You must make it so that their credentials only allow them to do things you would like them to be able to do. It is unfortunate that you are in the position you are in, as it is a nearly hopeless one. Security cannot be added as an afterthought. It must be designed in from the very beginning. You must construct a threat model, state security requirements, and build into the design a way to meet those requirements and defeat all plausible threat models. Honestly, the type of schemes you are considering as band-aids are unlikely to slow down a determined attacker very long. I would bet dollars to donuts that the end result will take less than a day to break. Your scheme requires you to put the credentials where an attacker can get them in unencrypted form. All an attacker need do is terminate your process as soon as it attempts a network connection (or intercept its filesystem calls and snapshot every file before it is deleted or overwritten). Your scheme requires these credentials to be sufficient for someone to do harm. Bluntly, your scheme is hopeless from a security standpoint. So any scheme which relies on client-server certificates (aka private-public key encryption) and encrypted data is hopeless from a security standpoint ? Care to suggest what is not hopeless from a security standpoint, which is actually programmable ? __ 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
Edward Diener wrote: Please suggest ways to do so. The server is no different from any other server database. It accepts a username/password to prevent unauthorized users from accessing its data. I am perfectly willing to listen to other server techniques which involve security, or read about such techniques, but I need to be pointed to such things. Just generally saying what you say is not going to help me. I am open to specific suggestions if you want to give them. If the username/password prevents unauthorized users from accessing the data, and a user can only do what he or she is allowed to do, what is the rationale for trying to protect the certificates? (From what you've said previously, it seems to be, that will give my boss a warm fuzzy feeling.) What you are doing is putting a screen door on your safe. If the safe's existing door is not adequate, the screen door sure as hell isn't going to be. If protecting the certificates is necessary, it is inadequate. Therefore, you must design your system such that protecting the certificates is not necessary. 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
Edward Diener Your scheme requires you to put the credentials where an attacker can get them in unencrypted form. All an attacker need do is terminate your process as soon as it attempts a network connection (or intercept its filesystem calls and snapshot every file before it is deleted or overwritten). Your scheme requires these credentials to be sufficient for someone to do harm. Bluntly, your scheme is hopeless from a security standpoint. So any scheme which relies on client-server certificates (aka private-public key encryption) and encrypted data is hopeless from a security standpoint ? No. Any scheme that relies on giving credentials to the same people it is trying to keep them from is hopeless from a security standpoint. Care to suggest what is not hopeless from a security standpoint, which is actually programmable ? A scheme which gives agents only credentials that permit them to do what they are supposed to do and which has no need to hide credentials from their owners. Again, you are trying to hide a customer's credentials from that customer himself. Let me use an analogy. Good: Two houses. Each has a key. People who are allowed into house 1 only get key 1. They cannot get into house 2 because they do not have the key. Bad: Two houses, with a door between them that is always open. People who are only supposed to be in house one get the key to house one, and we try to make it hard for them to find the door between the houses. Maybe, we put it behind some drapes. Or maybe we don't tell them they have a key and they won't notice they're in a house. No proper use of certificates or keys involves hiding the certificates or keys from the very agents who are going to use them. The reason public-key encryption works is because the private keys are not given to those who are not supposed to have them. Not because they are sort of given but sort of hidden. I cannot impersonate 'www.amazon.com' because I do not have their private key. It is not hidden somewhere in my computer where I might be able to find it. It is not obscured from me. It never leaves Amazon's servers, because Amazon is supposed to have it, not me. 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
On Fri December 26 2008, Edward Diener wrote: Kyle Hamilton wrote: If your company hires a security consultant, s/he will state the same thing. Thanks for your help but right now I am the programmer and security consultant, and therefore I must come up with security answers. Nonetheless I will mention to my employer that he might want to hire another person as a security consultant to deal with server side security issues. And that is one of the problems which people are trying to describe. Where the application coding can be split between server and client side coding - (and evidently has been, you have the client side chore). The system security plan can not be split, it must encompass the application as a whole, end-to-end. Note I write: plan - the coding that implements the plan can be split, just the plan can not be. And unfortunately for yourself, you can't fix things from the client side only. ;) - - - - From a business stand point, there is another significant problem lurking here - If the system was sold along the lines of argument: Buy our xyz and you can be sure the information in the system is secure. The the customer can reasonably expect the firm making the sale under such logic to be responsible for any security failures. Now consider some scheme that involves a client-side private key - - Perhaps, the application generates a key-pair, has the server sign the certificate request - something, anything, that results in a client side, private key - - If any of the clients fail to preserve and protect that client side private key - Then the information stored by the application is subject to compromise. I.E: the actual failure point is on the client side - But the liability remains with the provider of the system. Ouch. (You can't ask the Fox to protect the Chicken House.) A similar case can be made for a system that does not use a client side private key but requires protection of the public key materials on the client side. We can all hope that the legal department did a better job of drawing up the sales contract than that done by the application security planner. ;) Mike -Kyle H __ 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 Fri December 26 2008, Edward Diener wrote: Kyle Hamilton wrote: If your company hires a security consultant, s/he will state the same thing. Thanks for your help but right now I am the programmer and security consultant, and therefore I must come up with security answers. Nonetheless I will mention to my employer that he might want to hire another person as a security consultant to deal with server side security issues. And that is one of the problems which people are trying to describe. Where the application coding can be split between server and client side coding - (and evidently has been, you have the client side chore). While I have programmed the client side, I am not precluded from working on the server side code/scripts nor from accessing the server side database. The system security plan can not be split, it must encompass the application as a whole, end-to-end. Note I write: plan - the coding that implements the plan can be split, just the plan can not be. And unfortunately for yourself, you can't fix things from the client side only. ;) See above. - - - - From a business stand point, there is another significant problem lurking here - If the system was sold along the lines of argument: Buy our xyz and you can be sure the information in the system is secure. The the customer can reasonably expect the firm making the sale under such logic to be responsible for any security failures. Now consider some scheme that involves a client-side private key - - Perhaps, the application generates a key-pair, has the server sign the certificate request - something, anything, that results in a client side, private key - - If any of the clients fail to preserve and protect that client side private key - Then the information stored by the application is subject to compromise. I.E: the actual failure point is on the client side - But the liability remains with the provider of the system. Ouch. (You can't ask the Fox to protect the Chicken House.) A similar case can be made for a system that does not use a client side private key but requires protection of the public key materials on the client side. Well I asked whether protection for the client side certs were needed, and how this might be done, and I was told I was barking up the wrong tree, so to speak. I felt this way from the very beginning but my employer wanted to get other opinions. But other than vague remonstrances about security planning, and that I was not qualified as a mere programmer to handle security issues from people who have no idea about my ability, I have yet to receive any specifics from others about what they would do in this very common scenario to implement security for the data in the server database. I am a very experienced programmer/designer/architect and vague talk about security does not really impress me very much. Of course if you or others would like to get technical and mention what you feel are good technical solutions to any problems which entail private-key/public-key encryption, I am willing to listen and learn about things which I do not fully know or understand. Once again the specific issue is that the MySQL server database has a certificate from a CA authority with a server public-private key and my client application was issued the same certificate from the CA authority with a a client public-private key. I need to pass the file location of the client CA certificate/public-key/private-key to the client side library in order to have an SSL connection to the database server where data passing between the client application and the server database is encrypted both ways. I told my employer that we should simply distribute the client CA certificate/public-key/private-key in the same application directory in which the rest of our modules reside. He had been told by someone from Sun that this was inherently bad security and, despite my arguing that this was not the case and that without the username/password to the database nothing could be accomplished even with the client side certs by a destructive hacker, he wanted me to investigate the issue. From what others have written, I feel that I am right and coming up with elaborate schemes of hiding the client certs from the end-user until thay are actually going to be used by client application code in making the connection is largely a waste of time. Instead we should be ensuring that the server database and its data are protected from the prying eyes of a destructive hacker. __ 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
Mr. Diener, What the folks here are saying is that your current scenario is a catch22: unless at least one part of the requirements (as perceived by your client) is changed, there is no way out. Put in other words used in the discussion so far: this fact turns any answer into a security theater. Let me try my hand at explaining this, based on your original scenario description: On Wed, Dec 24, 2008 at 1:54 PM, 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. [...+...] 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. The above is why Victor points out this is a DRM problem. Your risk model says: the clients are not to be trusted. Meanwhile, your business model (the software you are selling them) requires those 'untrustworthy individuals' have access to your database/server - or the application you are creating/have created won't work. That is a clear cut case of catch22. Sorry for the 'general response' now - I'll get a bit more detailed further down: You have basically two ways out of here: 1) you can state that you trust your clients. (Thus replacing your risk model.) Consequences: a) Assuming your clients are to be trusted (I wouldn't do business with untrustworthy ones, right? ;-) ), the risks are that, through inability, accident or neglect, Bad Crackers(tm) gain access to those client certificates and thus -- assuming, as we should, that Bad Crackers know your system throughout -- can access your server and do /anything/ the (now compromised client) could do as well. Extremely Clever Bad Crackers might even be able to gain additional server-side access if server-side protection is not up to snuff. b) You can distribute those client certificates with the software as you were planning before. Hence the issue becomes the question: how can we make sure the client cannot accidentally 'loose his keys'? Which, in a way, makes this a variant of #2 here: 2) You can treat the scenario as a DRM issue -- the question is, after all, very similar to: how can I sell software without having pirated copies floating around the net within X days? (Note the 'X': putting a number there is a strategic management decision as it directly translates to the amount of (known fallible) DRM/protection effort you are willing to spend. Possible answer: give the client keys enclosed in dedicated hardware. As not trusting the user to not lose his marbles is (almost) identical to the client machine being a source of trouble. Which, broadly speaking, is very similar to 'not trusting your client'. For software protection, the higher end keyword is 'dongles'; the same keyword applies here: store all client-private keys in a dongle (which is quite closely related to OpenSSL 'engines'! ;-) ) And most importantly: all 'private key'-related operations should be performed in such 'secure hardware' -- that's where the OpenSSL engines come in. (Because once a private client key travels outside that secure hardware, it is, de facto, 'compromised'. i.e. Bad Crackers will be able to steal it. Before you run off (I did not give you a sufficient answer, despite the looks of it ;-) ), consider a few things here: - as I said, anything 'private key related' (that is: data PLUS calculations) should ultimately be executed in secure hardware. Anything less is knowingly fudging it and thus inherently flawed. (See few notes below for comparative thought) - Any 'public key' material, e.g. the CA and other certs for your server are fine in public storage. After all, that's what public keys and certificates are
Re: Where to store client PEM certificates for an application
Edward Diener wrote: Well I asked whether protection for the client side certs were needed, and how this might be done, and I was told I was barking up the wrong tree, so to speak. I felt this way from the very beginning but my employer wanted to get other opinions. You are either unclear on the concepts that others are trying to convey, or are abusing the terminology. Certs don't require protection, they don't contain any private data, etc. Once again the specific issue is that the MySQL server database has a certificate from a CA authority with a server public-private key and my client application was issued the same certificate from the CA authority with a a client public-private key. No, it wasn't issued the same certificate. Such an assertion is absurd. I need to pass the file location of the client CA certificate/public-key/private-key ... client CA certificate/public-key/private-key is an indication you should stop talking and start listening. It's clear that there are fundamental concepts here that you have yet to grasp, and yet in response to attempts by others to instruct you, you just keep telling us how smart you are, while demonstrating the opposite. Anyone who talks of hiding the client certs is clueless. __ 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 Fri December 26 2008, Edward Diener wrote: From what others have written, I feel that I am right and coming up with elaborate schemes of hiding the client certs from the end-user until thay are actually going to be used by client application code in making the connection is largely a waste of time. Instead we should be ensuring that the server database and its data are protected from the prying eyes of a destructive hacker. Yes, we are all on that same page. Sorry if my choice of words may have sounding insulting, it was not my intent. Presume the worst case, that all _communications_ security has failed - Now, look at what you can do in the environment you control, the server(s), to keep the information stored secure - whatever secure means in your application of an information storage system. If not already part of your delievered application, plan on some sort of client-awareness guide to policies they should implement at their end. End-to-end security always includes good client polices and practices. I can't be anything other than general, since I don't have the specifics. Again, I do not intend to be insulting by being general. Mike __ 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
Ger Hobbelt wrote: Mr. Diener, What the folks here are saying is that your current scenario is a catch22: unless at least one part of the requirements (as perceived by your client) is changed, there is no way out. Put in other words used in the discussion so far: this fact turns any answer into a security theater. Let me try my hand at explaining this, based on your original scenario description: On Wed, Dec 24, 2008 at 1:54 PM, 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. [...+...] 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. The above is why Victor points out this is a DRM problem. Your risk model says: the clients are not to be trusted. Meanwhile, your business model (the software you are selling them) requires those 'untrustworthy individuals' have access to your database/server - or the application you are creating/have created won't work. That is a clear cut case of catch22. If I can get a little finicky, the application needs access to the database/server. Nobody else should be accessing it. But I am sure that is what you meant. The clients are to be trusted using the application. My employer, not I, felt that putting the certificates where a client, who might be a destructive hacker, could easily access them, might be a security risk. He was told this by a Sun rep whom he knows, so naturally he wanted me to find out if this was the case. I come on this forum to ask, and what I get, not from you, is some good information mixed with a bunch of heavy ego which wants to tell me that only security experts are qualified to understand the deep issues involved and that since I have not proved myself a security expert simply by asking my question I should not even be dealing in any way with security problems, much less this current simple one. Sorry for the 'general response' now - I'll get a bit more detailed further down: You have basically two ways out of here: 1) you can state that you trust your clients. (Thus replacing your risk model.) Consequences: a) Assuming your clients are to be trusted (I wouldn't do business with untrustworthy ones, right? ;-) ), the risks are that, through inability, accident or neglect, Bad Crackers(tm) gain access to those client certificates and thus -- assuming, as we should, that Bad Crackers know your system throughout -- can access your server and do /anything/ the (now compromised client) could do as well. Extremely Clever Bad Crackers might even be able to gain additional server-side access if server-side protection is not up to snuff. b) You can distribute those client certificates with the software as you were planning before. Hence the issue becomes the question: how can we make sure the client cannot accidentally 'loose his keys'? If the client loses, ie. destroys or changes, the certs, the application will not work. That is fine by my employer since it is much the same as the client destroying a DLL distributed with the application. The client has messed up and does not deserve a working application. Which, in a way, makes this a variant of #2 here: 2) You can treat the scenario as a DRM issue -- the question is, after all, very similar to: how can I sell software without having pirated copies floating around the net within X days? (Note the 'X': putting a number there is a strategic management decision as it directly translates to the amount of (known fallible) DRM/protection effort you are willing to spend. We do have registration protection which is another issue but which should prevent
Re: Where to store client PEM certificates for an application
On Fri, Dec 26, 2008 at 01:28:27PM -0500, Edward Diener wrote: If I can get a little finicky, the application needs access to the database/server. Nobody else should be accessing it. But I am sure that is what you meant. You trust your application, but not its users. This always because, the security controls that you need are in the application that is in the hands of the users, and not on the server. Sometimes this situation is unavoidable (media players, ...), other times this a design flaw, that can be fixed by beefing up server controls in a 3-tier design with the middle tier (server) applying the necessary controls. If the need for client-side security controls (trusted application) is unavoidable, this is a DRM problem. DRM is an interesting problem, but the OpenSSL users group is not the right place to explore it. The clients are to be trusted using the application. In other words you only trust the application, and not the users who with the application's credentials in hand are able to do things you must prevent them from doing. Still sounds like DRM. My employer, not I, felt that putting the certificates where a client, who might be a destructive hacker, could easily access them, might be a security risk. He was told this by a Sun rep whom he knows, so naturally he wanted me to find out if this was the case. The phrase Security risk only has meaning in the context of a threat model. If you take the time to write down that risk model and analyze it you will find out whether it is possible to put controls on the server side, and remove the need to hide the client credentials from the client. Or you may find that client controls are inevitable, and you have a DRM problem. I come on this forum to ask ... Well, you have not really explained the nature of the risks (threat model) you are trying to mitigate. Perhaps you can't do that in a public forum. Still, without a detailed explanation of the requirements, only general advice is possible. Your first task is to determine what type of security problem you are solving: - Trusted client-side app, untrusted user = DRM - Trusted users, restricted access via any app = User auth management - Users face potentially hostile servers = Server auth - ... b) You can distribute those client certificates with the software as you were planning before. This makes no sense in a non-DRM context. Code is distributed separately from user credentials. Credentials are obtained via a separate enrollment process. In a DRM context, where the application is trusted, but the users are not, one tries to hide credentials in the app. This forum is not the right place to seek help with DRM designs, and such designs have nothing to do with OpenSSL. 2) You can treat the scenario as a DRM issue -- the question is, after all, very similar to: how can I sell software without having pirated copies floating around the net within X days? (Note the 'X': putting a number there is a strategic management decision as it directly translates to the amount of (known fallible) DRM/protection effort you are willing to spend. Piracy of the software does not matter if this an on-line application, and it only works when the user has the right credentials. At that point what matters is the user's credentials. If these protect something of value to the user (user's bank account, user's credit card enrolled to buy more services, ...) the users won't want to share their credentials. If the credentials protect content of value to the provider, but the user has no direct interest in protecting the credentials, we are back to DRM, unless the design can be changed to make the user want to protect their credentials. Possible answer: give the client keys enclosed in dedicated hardware. As not trusting the user to not lose his marbles is (almost) identical to the client machine being a source of trouble. Which, broadly speaking, is very similar to 'not trusting your client'. Distribute keys via an enrollment process, separate from software download. The CA authority issued a CA certificate, server key, and server certificate to the MySQL database server to use when it starts up. This is public information, and requires no protection. The server's private key was never seen by the CA, and resides only on the MySQL server. In fact this cannot be protected, since every TLS connection to the server provides the server's certificate to the client up-front before any client credentials are presented. If you tell me your server's IP address and service port, I'll email you the cert, it CAN'T be hidden. This cert should be distributed together with the software, it will be used by the client server to ensure the server is legitimate. There is no need to hide/protect this cert, it is not possible or necessary to do this. My client software was issued a CA certificate, a client key, and a client certificate to use in establishing a connection to
Re: Where to store client PEM certificates for an application
On Fri December 26 2008, Edward Diener wrote: By 'dongle' do you mean a hardware 'dongle'. If it is a software dongle you need to spell out for me what you mean. There are a lot of devices being marketed for this purpose, but as an example that it needs to be neither complicated programming or an expensive solution: http://pdfserv.maxim-ic.com/en/an/app190.pdf The basics (no insult intended): Your client (or your application, on the client's behalf) generates a public/private key pair - The public part goes through the certification request process (with your server) that you are familiar with - The private part is never seen other than on the client machine during generation - The private part (or the key to its protective encryption) is stored in one (or more) of those shirt button devices. Once written and locked, short of peeling the silicon a few microns at a time under an electron microscope - it isn't ever going to be read. Some makes/models even have the stored data AES-256 encrypted, so even if peeled... The client can record _their_ private part in as many devices as they desire - and now they have a physical thing that any business knows how to protect from loss. Businesses well know how to protect something they can touch. I am not trying to push a specific product, only giving an example, even that one manufacturer makes a selection of products. Bottom line - you might be adding $20-$50 per button the client wants to have - you ship them blank - their software driver can write and lock them once the client has their private part ready. Note: There are laptops and desktops made that already read these 1-wire devices, or a USB based reader can be added to existing machines. Mike __ 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
First: I have suggested such, in the message where I stated that many hotels don't allow connections on port 3306 (which is MySQL's standard data port). Create a proxy that sits on a webserver, using XML-RPC to accept requests from the client. Perform whatever logic checking you need there, and log every access. Second: You can manipulate the database, but can you look back and audit the manipulations you make to the database? You stated that you don't think that you have the ability at the MySQL layer to see what the clients are doing, much less what they have done. Third: If you're the security consultant, why should I have to provide free consulting for you to be able to profit from? There's a LOT of books on the topic, and I would recommend that you read them. Basically, at every step, do whatever you have to to mitigate the damage that an attacker can do. Don't allow DELETE access from critical tables to your users, add a boolean column that states whether the record has been deleted, and only after you have ensured that those records are backed up should you purge them (which can be done from a user account which does have DELETE access: 'delete from table where (backedup == true and deleted == true)'. You must model the security threats against your database, and find ways to mitigate them and identify people responsible for attempts to breach security so that their ability to threaten your database can be removed. Without details (and money for my time :P) I can't perform this analysis for you. -Kyle H On Fri, Dec 26, 2008 at 5:47 AM, Edward Diener el...@tropicsoft.com wrote: Kyle Hamilton wrote: Mr Diener: This is, incidentally, why I call it security theater -- you're not gaining anything from the actions that you're going through, except warm and fuzzies of the people you're entertaining with it (in this case, your boss). You need to fix your server architecture, which is likely going to involve a lot of work -- work that you're not doing while you're searching for ways to hide authentication credentials which are subject to attack. Please suggest ways to do so. The server is no different from any other server database. It accepts a username/password to prevent unauthorized users from accessing its data. I am perfectly willing to listen to other server techniques which involve security, or read about such techniques, but I need to be pointed to such things. Just generally saying what you say is not going to help me. I am open to specific suggestions if you want to give them. Yes, it might prevent the casual user from doing it, but the casual user is also unlikely to know what to do with the credentials that he sees anyway. The advanced user will be able to find the credentials, and is more likely going to know how to write SQL to abuse the credentials than the casual user. The practical upshot of this is that you're protecting your infrastructure from people who wouldn't know how to attack it. This is more likely than not going to lead to your company feeling warm and fuzzy, that the system is safe from attack -- which is (ironically) going to lead to more security vulnerabilities that your company is not going to be on the lookout for. This is not the psychology of the company for which I am working. This could lead to catastrophic data loss and downtime while you try to figure out how the data in the tables managed to disappear out from under you -- and if the data is of sufficiently high value, it will more likely lead to the data being sucked down by attackers using the credentials. Since you have admitted that you don't have visibility with MySQL directly as to the queries it's receiving and processing, your company is a sitting duck against these types of attacks. Why do you say Since you admitted... etc. ? The server database is accessible and manipulatable in whatever ways we want to manipulate it. If your company hires a security consultant, s/he will state the same thing. Thanks for your help but right now I am the programmer and security consultant, and therefore I must come up with security answers. Nonetheless I will mention to my employer that he might want to hire another person as a security consultant to deal with server side security issues. -Kyle H On Thu, Dec 25, 2008 at 6:49 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Dec 24, 2008 at 10:06:59PM -0500, Edward Diener wrote: 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 ? No, I am
Re: Where to store client PEM certificates for an application
Kyle Hamilton wrote: First: I have suggested such, in the message where I stated that many hotels don't allow connections on port 3306 (which is MySQL's standard data port). Create a proxy that sits on a webserver, using XML-RPC to accept requests from the client. Perform whatever logic checking you need there, and log every access. Second: You can manipulate the database, but can you look back and audit the manipulations you make to the database? You stated that you don't think that you have the ability at the MySQL layer to see what the clients are doing, much less what they have done. Third: If you're the security consultant, why should I have to provide free consulting for you to be able to profit from? There's a LOT of books on the topic, and I would recommend that you read them. Basically, at every step, do whatever you have to to mitigate the damage that an attacker can do. Don't allow DELETE access from critical tables to your users, add a boolean column that states whether the record has been deleted, and only after you have ensured that those records are backed up should you purge them (which can be done from a user account which does have DELETE access: 'delete from table where (backedup == true and deleted == true)'. You must model the security threats against your database, and find ways to mitigate them and identify people responsible for attempts to breach security so that their ability to threaten your database can be removed. Without details (and money for my time :P) I can't perform this analysis for you. Thanks for your suggestions about protecting the database itself. I do appreciate them and I am not asking for you or anyone to offer free consulting for me. We will look at things we can do on the database server side to protect the database using some of your suggestions. __ 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
Hi Edward: Ok - I'm going to reply, but I'm also going to top post, since doing a point by point discussion isn't going to help. The concept of Private/Public key cryptography (of which X.509 Certificates are one invocation), is that a single private key belongs to a single security principle. The security principle may have more than one private key, but a given private key is only attributable to a single security principle. Now, a security principle can be anything - a single person, a unique customer, a server, a space ship, an aeroplane, a ham sandwich (ok, maybe not the last :) But, the point is - what you are trying to do is to have a single private key associated with more than one customer - this breaks such a fundamental principle of private/public key cryptography that my colleagues on this list are having a difficult time expressing themselves :) In short - the right way to solve your problem is to have EACH customer have a unique set of credentials (such as a private/public key pair/certificate), and use that credential to authenticate themselves to the server, which, should, in turn, be also configured to only allow a given customer to only do what that customer SHOULD be allowed to do. To give all of your customers the same private key is working with a horrendously wrong security model, and offers nothing other than sprinkling magic crypto dust on your system in the hopes of making it secure (otherwise known as Security Theater). Each customer needs their own, unique private key and associated certificate, and they need to protect that private key according to whatever security model the environment you are working in requires (for instance, if you are working in a US Federal Class III environment, you probably need to have that private key on some form of hardware token). If you are working on the public internet, then you will have to do a proper threat analysis of the value and potential attackers that the data you are handling would attract. Have you done your threat tree yet??? I hope that I have helped you clear up any misconceptions - in short - what you are talking about doing - please don't - as others have said - that is a failed model of DRM, and you are only going to protect your system from those it doesn't need protecting from. Have fun. Patrick. Edward Diener wrote: Michael S. Zick wrote: On Fri December 26 2008, Edward Diener wrote: Kyle Hamilton wrote: If your company hires a security consultant, s/he will state the same thing. Thanks for your help but right now I am the programmer and security consultant, and therefore I must come up with security answers. Nonetheless I will mention to my employer that he might want to hire another person as a security consultant to deal with server side security issues. And that is one of the problems which people are trying to describe. Where the application coding can be split between server and client side coding - (and evidently has been, you have the client side chore). While I have programmed the client side, I am not precluded from working on the server side code/scripts nor from accessing the server side database. The system security plan can not be split, it must encompass the application as a whole, end-to-end. Note I write: plan - the coding that implements the plan can be split, just the plan can not be. And unfortunately for yourself, you can't fix things from the client side only. ;) See above. - - - - From a business stand point, there is another significant problem lurking here - If the system was sold along the lines of argument: Buy our xyz and you can be sure the information in the system is secure. The the customer can reasonably expect the firm making the sale under such logic to be responsible for any security failures. Now consider some scheme that involves a client-side private key - - Perhaps, the application generates a key-pair, has the server sign the certificate request - something, anything, that results in a client side, private key - - If any of the clients fail to preserve and protect that client side private key - Then the information stored by the application is subject to compromise. I.E: the actual failure point is on the client side - But the liability remains with the provider of the system. Ouch. (You can't ask the Fox to protect the Chicken House.) A similar case can be made for a system that does not use a client side private key but requires protection of the public key materials on the client side. Well I asked whether protection for the client side certs were needed, and how this might be done, and I was told I was barking up the wrong tree, so to speak. I felt this way from the very beginning but my employer wanted to get other opinions. But other than vague remonstrances about security planning, and that I was not qualified as a mere programmer to handle security issues from people who have no idea
Re: Where to store client PEM certificates for an application
Michael S. Zick wrote: On Fri December 26 2008, Edward Diener wrote: By 'dongle' do you mean a hardware 'dongle'. If it is a software dongle you need to spell out for me what you mean. There are a lot of devices being marketed for this purpose, but as an example that it needs to be neither complicated programming or an expensive solution: http://pdfserv.maxim-ic.com/en/an/app190.pdf The basics (no insult intended): Your client (or your application, on the client's behalf) generates a public/private key pair - The public part goes through the certification request process (with your server) that you are familiar with - The private part is never seen other than on the client machine during generation - The private part (or the key to its protective encryption) is stored in one (or more) of those shirt button devices. Once written and locked, short of peeling the silicon a few microns at a time under an electron microscope - it isn't ever going to be read. Some makes/models even have the stored data AES-256 encrypted, so even if peeled... The client can record _their_ private part in as many devices as they desire - and now they have a physical thing that any business knows how to protect from loss. Businesses well know how to protect something they can touch. I am not trying to push a specific product, only giving an example, even that one manufacturer makes a selection of products. Bottom line - you might be adding $20-$50 per button the client wants to have - you ship them blank - their software driver can write and lock them once the client has their private part ready. Note: There are laptops and desktops made that already read these 1-wire devices, or a USB based reader can be added to existing machines. Thanks for the information on these devices. I will mention this to the person for whom I work. The practical situation is that the device must be distributed to all end users who buy the application and they must install such a device on their computers. I do not think this is a viable solution for our application but I do understand that some people companies may use it for their application. __ 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: - - - snip - - - 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. That is what I meant, my own poor choice of words. Just wanted to be clear this scheme is not increasing the security as a communications security expert would use the phrase. 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. As others have posted, here is your major point of vulnerability - the direct SQL connection to the database. You really need to setup the system to connect to your server, and let the server proxy to the SQL database server, after very careful inspection, the request strings. With such a setup, then you have the system protection code running in your own, protected (the server) environment. Anything else is just asking the Fox if everything is OK in the chicken house. ;) 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. I am not addressing security as understood by the security professionals on this list - only the subjective reaction of your boss to bad advice. Which I called the warm and fuzzy test. But it reads as if you are already aware we are not talking security here just subjective impression. Mike 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, Dec 24, 2008 at 10:06:59PM -0500, Edward Diener wrote: 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 ? No, I am saying that applications where you don't trust the user are DRM problems. If you trust the user (not abuse, modify or replace) your application, then you don't need DRM, just authenticate trusted users by giving each user appropriate credentials (possibly a per-user private key, delivered separately from the application, via a secure enrollment process). -- 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 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
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 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 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
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
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
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
On Wed, Dec 24, 2008 at 1:27 PM, Edward Diener el...@tropicsoft.com 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 on
how important it is that the data be
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
Kyle Hamilton wrote:
On Wed, Dec 24, 2008 at 1:27 PM, Edward Diener el...@tropicsoft.com 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
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 made. This
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
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
