Re: [openssl-users] OPENSSL_VERSION_NUMBER representation
On 5/2/2018 8:30 AM, Tomas Mraz wrote: On Wed, 2018-05-02 at 08:19 -0400, Edward Diener wrote: The latest documentation for OPENSSL_VERSION_NUMBER at https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.h tml says that it is 9 hex digits, with the last nibble being a status identifier, while every use I have seen of it in header files treats it as 8 hex digits. Can anybody straighten me out on this ? Also the latest documentation give it as MNNFFPPS: major minor fix patch status where the examples in that documentation clearly show it as MMNNFFPPS: major minor fix patch status Can anybody straighten me out on this ? That's because 0x1 and 0x01 are the same numbers. For example version 1.1.0a: 0x01010001f == 0x1010001f Thanks ! I guess version 16 of openssl isn't planned for anytime soon . -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OPENSSL_VERSION_NUMBER representation
The latest documentation for OPENSSL_VERSION_NUMBER at https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.html says that it is 9 hex digits, with the last nibble being a status identifier, while every use I have seen of it in header files treats it as 8 hex digits. Can anybody straighten me out on this ? Also the latest documentation give it as MNNFFPPS: major minor fix patch status where the examples in that documentation clearly show it as MMNNFFPPS: major minor fix patch status Can anybody straighten me out on this ? I would like to use the OPENSSL_VERSION_NUMBER at compile time to choose between functionality for version 1.1.0 and version 1.0.x but the confusion in my mind of how OPENSSL_VERSION_NUMBER actually is specified is making that impossible. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate
On 11/22/2017 10:46 AM, Matt Caswell wrote: This is a bug in the docs. In the header files they are declared as const: int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, const unsigned char *in, int inl); int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, const unsigned char *in, int inl); Please file a bug report! I filed an issue. It is now the 333th open issue. Thanks for the information. I guess I should have looked myself. https://github.com/openssl/openssl/issues Matt On 22/11/17 14:42, Edward Diener wrote: When calling EVP_EncryptUpdate with some plaintext to be encrypted the parameter for the plaintext is a pointer to a non-const array of unsigned char, as in the function prototype: int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, unsigned char *in, int inl); Similarly when calling EVP_DecryptUpdate with some ciphertext to be decrypted the parameter for the ciphertext is a pointer to a non-const array of unsigned char, as in the function prototype: int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, unsigned char *in, int inl); I have taken both these function prototypes from the OpenSSL documentation at https://wiki.openssl.org/index.php/Manual:EVP_EncryptInit(3). Does this mean that the input array in both cases actually is modified in any way by the functions ? Or is this just an error in that if the input remains unmodified the functions do not specify the parameter as 'const unsigned char * in' instead ? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate
When calling EVP_EncryptUpdate with some plaintext to be encrypted the parameter for the plaintext is a pointer to a non-const array of unsigned char, as in the function prototype: int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, unsigned char *in, int inl); Similarly when calling EVP_DecryptUpdate with some ciphertext to be decrypted the parameter for the ciphertext is a pointer to a non-const array of unsigned char, as in the function prototype: int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, unsigned char *in, int inl); I have taken both these function prototypes from the OpenSSL documentation at https://wiki.openssl.org/index.php/Manual:EVP_EncryptInit(3). Does this mean that the input array in both cases actually is modified in any way by the functions ? Or is this just an error in that if the input remains unmodified the functions do not specify the parameter as 'const unsigned char * in' instead ? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
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 . 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
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: 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
Scott Gifford wrote: Edward Diener 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
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
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
Ger Hobbelt wrote: On Fri, Dec 26, 2008 at 7:28 PM, Edward Diener 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 Q&A 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 commu
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
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
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 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
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
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
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 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
Victor Duchovni wrote: On Wed, Dec 24, 2008 at 03:59:13PM -0500, Edward Diener wrote: I am working for an employer who will be selling a product to end users. The risk model is that my employer feels it would be bad if a hacker were able to easily understand where the client certs reside in the end user application and were able to use the client certs to communicate to the server, ie. if someone who buys the product were able to use the client certs in a destructive way. My employer has also been told by a Sun representative he knows that if the client certs are distributed in the directory of the application it is a serious security risk. So he has asked me to investigate alternative ways of distributing the client certs. It sounds like you are trying to implement DRM with an application that is running on untrusted hardware controlled by a potentially hostile user. You want to ensure that only your code has access to your server, and not modified or user developed code. This is a "whitebox" DRM problem. Are you saying that any application sold on the market which needs to ensure secure access to data on a server outside the client machine on which the application runs is a "whitebox" DRM problem ? Your problem is completely unrelated to SSL and certificates. You need a DRM professional. This is likey not the right forum for help with whitebox DRM. Unless you have trusted hardware, you need code obfuscation techqniques that hide key material in code visible to the attacker. There is some commercial software in this space, but none in OpenSSL. Good luck. Thanks for your input. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where to store client PEM certificates for an application
Michael S. Zick wrote: On Wed December 24 2008, Edward Diener wrote: Michael S. Zick wrote: On Wed December 24 2008, Edward Diener wrote: In a client application communicating with a MySQL server, I am using SSL to encrypt/decrypt data sent to and from the database. This requires me to have the PEMs for the CA, client key, and client certificate distributed as part of the application. Of course these certificates will not work except with the corresponding server certificates on the MySQL server to which I am communicating. My initial choice was to distribute the client certificates in the same directory as the application's modules, as they are easy to find at run-time there in order to make my SSL connection with the database. It has been suggested to me that this is inherently insecure. Nonetheless I must distribute them somewhere since the certificates have to exist in the file system when I make the call at run-time to create a SSL connection to the server. What are the best strategies to distribute these client certificates on the end-user's machine ? Should I be pre-encrypting these certificates, then decrypting them in memory before writing them to a temporary location, and then destroying the decrypted certificates from that temporary location after the connection is made, or is this overkill and a simpler/better way of distributing the client certificates as part of my application is possible ? Any suggestions, help, pointers would be much appreciated. It is a hard question to answer without some knowledge of your risk model. What are the risks that you are trying to minimize? What harm is done if the files are accessable to the people who already have your application? Is this even a concern? Should it be? I am working for an employer who will be selling a product to end users. The risk model is that my employer feels it would be bad if a hacker were able to easily understand where the client certs reside in the end user application and were able to use the client certs to communicate to the server, ie. if someone who buys the product were able to use the client certs in a destructive way. My employer has also been told by a Sun representative he knows that if the client certs are distributed in the directory of the application it is a serious security risk. So he has asked me to investigate alternative ways of distributing the client certs. My own feeling is that even with the client certs, nothing can be done unless the host-server/username/password/database were known to destructive hacker. But my employer is concerned and wants to make it more difficult for the end users to be able to ascertain where the client certs are once they install the application. Ah, so - Your risk model is: "Give the boss a warm and fuzzy feeling." No, my risk model is to simply ascertain whether distributing the certs as files in the application directory is a serious security risk or not and, if it is, what steps can make it less so. The suggestion of using the ACL protection, to protect from casual or accidental access sounds like a good one - if your platform supports it. Windows supports ACLs. But any registered end-user on the client machine can use the application and the installation of the application does not know at installation time who are the registered users on the client machine. So using ACLs is probably not a very effective solution. Use some light-weight, passphrase keyed, encryption to hide the contents. I can certainly do that. Consider using the "__from_memory" rather than the "__from_file" functions of openSSL so you don't have to write the "un-hidden" files back to the file system. That would be great if the MySQL API would allow the certs to be passed from memory. Unfortunately the client C/C++ API expects file names instead. So after encrypting the certs I need to decrypt them back to a files in order to use them. For the passphrase, use a simple little linear-feedback-shift register to select bytes from some part of the application. That way the passphrase isn't stored as a string in the application, that part of the application would have to be reverse-engineered. Or maybe checksum (crypto hash function, that is) a critical dll for the passphrase. Should be hard to find among all the other sha256sum and such like calls in the application. Yes, I already have a clever way of generating passphrases which keeps them from being stored in the application. This will not keep a cryptographer out of your application, but should pass the "warm and fuzzy" test. It may make it harder for a disruptive hacker. In general what I can do is store the certs in encrypted form as resources in the application and, each time I need them, read the resources into memory, decrypt them, write them out as temporary files, use the temporary files in the MySQL connect
Re: Where to store client PEM certificates for an application
Kyle Hamilton wrote:
On Wed, Dec 24, 2008 at 1:27 PM, Edward Diener wrote:
Kyle Hamilton wrote:
If you're on Windows, it does make sense to include the PEMs for the
CA (and chain) in the application directory. (See, for example, the
software distribution of Second Life, which has its own CA for TLS
authentication of its own grid servers.)
For client certificates, though, it depends. If it's a per-user
certificate, the certificate (and key) should go in the user's home
directory (in a folder not unlike, but also not, ~/.ssh) -- and should
have permissions which only allow the user access. If it's a
per-machine certificate, the certificate (and key) should go under
either /etc/ or /var/ (on *nix) or the application directory (on
Windows).
It is a per-machine cert in my case under Windows. But it is solely for the
use of a single application. I certainly can distribute the certs in the
common application directory under Windows but that complicates the issue
under Windows Vista protected mode, where certain directories are off-limits
to a running application unless the application runs with Administrator
rights, which is something not being required of the end user once the
application has been installed. Nonetheless it is a good idea to consider.
At least the certs are more hidden there than in the application directory.
If it's under Windows, you can place the certificate (and key) in your
app's registry. You could also use the so-called "native" API to
embed a NUL character ('\0') in the name of the key you place it in.
See http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx for
information on this (look for "Hidden Registry Keys" on the page);
however, be aware that many rootkit scanners will find and delete
these WinSDK-inaccessible entries.
My interpretation of using the Windows registry is that a very long
string should not be placed there, even if I could obfuscate the actual
key using the NUL character technique you mention above.
This is a red flag to most security-conscious hackers, though, and
many will do anything they can to figure out what's in there.
I fully agree.
Also, the host/port must be considered public information. They can
be easily derived with netstat.
You are right.
If I encrypt the cert files pre-installation I would use the the Windows
Crypto API library to do so, and then use the same library at run-time to
decrypt it and put it someplace temporarily in order to user the cert files.
I have already used the Crypto API successfully so I know it can be done
fairly easily.
If you're using CryptoAPI, why are you not using it for key storage as well?
According to the MySQL client documentation using the C/C++ API, I must
pass file names to the API where my CA, client certificate, and client
key reside.
Furthermore the CryptoAPI is not a storage mechanism, only an
encrypt/decrypt mechanism AFAIK.
I do not think I really need to scramble anything once the data is encrypted
as the "strings" are just totally encrypted sequences of byte information
once Crypto API encrypts them.
The openssl library (libeay) can do everything that cryptoAPI can do,
as well. It doesn't use the same API convention, though.
I am not using OpenSSL directly in my application, although I suppose I
could do so. I find the CryptoAPI pretty adequate and the doc for the
CryptoAPI which Microsoft supplies is quite good.
This is potentially a very good idea. At least I could keep everyone except
my application from easily viewing the certs.
No, since your application runs with the user's rights, the user must
be able to read the certs and key.
The user meaning my application. You are correct.
It is my employer who has been told that
distributing the certs so that an end user can easily view them is a
security risk.
This is absolute garbage. The idea behind certificates is that they
uniquely identify the consumer's public key (and thus the private key
they use with it), and they're signed by someone you trust. You can
also embed a critical extension in the certificate so that no other
X.509 application would or could use it. You don't have to put any
kind of private or confidential data in the certificate itself. (It
is the PRIVATE KEY which must be kept protected.)
I totally agree with you.
I'd like to know the name of the rep at Sun who told your employer
this, so I can go to Sun and say "you need to train your developer
liaisons better about X.509 and asymmetric cryptography."
I would gladly give it to you if my employer agreed to do it. I did not
think the Sun representative was right.
My own viewpoint is that the certs are useless without
host-name/username/password/database knowledge of the server database anyway
so there is little point really in inventing elaborate measures to hide the
certs
Re: Where to store client PEM certificates for an application
Kyle Hamilton wrote: If you're on Windows, it does make sense to include the PEMs for the CA (and chain) in the application directory. (See, for example, the software distribution of Second Life, which has its own CA for TLS authentication of its own grid servers.) For client certificates, though, it depends. If it's a per-user certificate, the certificate (and key) should go in the user's home directory (in a folder not unlike, but also not, ~/.ssh) -- and should have permissions which only allow the user access. If it's a per-machine certificate, the certificate (and key) should go under either /etc/ or /var/ (on *nix) or the application directory (on Windows). It is a per-machine cert in my case under Windows. But it is solely for the use of a single application. I certainly can distribute the certs in the common application directory under Windows but that complicates the issue under Windows Vista protected mode, where certain directories are off-limits to a running application unless the application runs with Administrator rights, which is something not being required of the end user once the application has been installed. Nonetheless it is a good idea to consider. At least the certs are more hidden there than in the application directory. If you encrypt the client key, you can place the decryption information into your client binary itself; if you do this, though, you should try to scramble it a bit (to prevent a simple 'strings' operation from seeing it), and you should statically link it and make it mode \111 (executable-only for owner, group, and world). If I encrypt the cert files pre-installation I would use the the Windows Crypto API library to do so, and then use the same library at run-time to decrypt it and put it someplace temporarily in order to user the cert files. I have already used the Crypto API successfully so I know it can be done fairly easily. I do not think I really need to scramble anything once the data is encrypted as the "strings" are just totally encrypted sequences of byte information once Crypto API encrypts them. If the filesystem you're on supports POSIX ACLs, you should include "everyone: deny read". For a Windows binary, you should apply the same ACL entry, along with SYSTEM: deny ACL modification. (This only provides a small modicum of security, since non-Windows NTFS drivers tend to completely ignore the access control list.) This is potentially a very good idea. At least I could keep everyone except my application from easily viewing the certs. Overall, it's important to recognize this: you are attempting to keep the user's computer from knowing what the key is unless it's within your process. This is, ultimately, a doomed endeavor. I fully agree with you. It is my employer who has been told that distributing the certs so that an end user can easily view them is a security risk. My own viewpoint is that the certs are useless without host-name/username/password/database knowledge of the server database anyway so there is little point really in inventing elaborate measures to hide the certs from the end users eyes. But he has asked me to investigate the ways it can be done nonetheless. Depending on how important it is that the data be secure, you may need to ensure that a given client key is only used from a specific IP address or IP range... It is an application to be sold to end users, so the 'from' IP address can not be pre-established. We do have ways from within the application to make sure that the client is a registered user which takes into account the client's machine. But of course a destructive hacker who could use the client certs along with the host-name/username/password/database knowledge to access the database is not running from within the application. and you may also need to be on the lookout for inappropriate access patterns (any 'select *', for example, if your application doesn't use that means of getting data out of the tables) -- and if you do see it, boot the connection from the server and invalidate the client authentication credentials. I do not know how I can 'see' such patterns from within the application itself. I do not think a destructive hacker can easily change the application, even knowing the client certs, but maybe there are ways and I am willing to be educated about them. Your threat model may or may not require this much; in most circumstances, I would consider it overkill. However, if you're under contractual obligation to ensure that the data remain confidential, you might need to take these steps -- and more. Thanks for your suggestions, especially about the ACLs, which can fairly easily be manipulated by the installation program. -Kyle H On Wed, Dec 24, 2008 at 4:54 AM, Edward Diener wrote: In a client application communica
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
Where to store client PEM certificates for an application
In a client application communicating with a MySQL server, I am using SSL to encrypt/decrypt data sent to and from the database. This requires me to have the PEMs for the CA, client key, and client certificate distributed as part of the application. Of course these certificates will not work except with the corresponding server certificates on the MySQL server to which I am communicating. My initial choice was to distribute the client certificates in the same directory as the application's modules, as they are easy to find at run-time there in order to make my SSL connection with the database. It has been suggested to me that this is inherently insecure. Nonetheless I must distribute them somewhere since the certificates have to exist in the file system when I make the call at run-time to create a SSL connection to the server. What are the best strategies to distribute these client certificates on the end-user's machine ? Should I be pre-encrypting these certificates, then decrypting them in memory before writing them to a temporary location, and then destroying the decrypted certificates from that temporary location after the connection is made, or is this overkill and a simpler/better way of distributing the client certificates as part of my application is possible ? Any suggestions, help, pointers would be much appreciated. Finally the client application runs on Windows and not LInux so if there are OS specific arguments as to how to distribute these client certificates you will know to what OS the application is targeted. Thanks ! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Using OpenSSL cryptographic functions in a multi-threaded application
John T. Cox wrote: I do not know if it does or not. But, as an experienced programmer, I can guarantee that even if it does not today, one day someone will do something that will cause it to need it and you will start to get failures that will take weeks to track down. Why can't people just do things right the first time? Oh yeah, management. :P I am all for doing the right thing but unfortunately there are many people who believe that because something is "working", the most important thing to do is not to change anything. Yes, management, but also other programmers who are afraid of change and the subsequent testing necessary to make sure that the change is correct. I, myself, am not one of those people and always look for the correct way of doing anything in programming so as to avoid future headaches. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Using OpenSSL cryptographic functions in a multi-threaded application
Bobby Krupczak wrote: Hi! The ORA Network Security with OpenSSL documents the few stubs you need to in order for openssl to work with pthreads as well as windows threads. You can even download the example code from the net. What is the link for the above ? http://www.oreilly.com/catalog/openssl/ Yes, sorry I neglected to post the URL. The book's website is: http://www.opensslbook.com The example code also includes code for generating your own keys, and certs in C so you can imbed it in your own programs. (This question comes up periodically on the mailing list) The book is definitely worth owning. The book may be worth owning but we need an immediate solution. I did find the code in crypto/threads/mttest.c and do understand it, so I know what needs to be done. Our situation is that we are using OpenSSL from a single Windows DLL in a multi-threaded Web Server application. The claim has been made by others in my programming group that our use of OpenSSL has been in place in a previous release of our product without noticable problems. We have not implemented the equivalent code similar to mttest.c to protect threads, nor have we put critical sections around our own use of OpenSSL in the single Windows DLL to make sure only one thread uses OpenSSL at a time. Our use of OpenSSL in our single DLL has been strictly in calls to EVP_ and HMAC_ functionality, but these calls can obviously be made by multiple threads of the web server application "simultaneously". Have we just been lucky not to have experienced problems in the past, without thread protection, or is it possible that the calls to the cryptographic functions for EVP_ and HMAC_ actually do not need multi-threaded protection as outlined in mttest.c ? Our own DLL which uses OpenSSL has itself no global data structures which need protection. BTW I am entirely in favor of providing the multi-threaded protection outlined in mttest.c above, but I have to convince others that it is absolutely needed else the inertia of others will just turn away from this problem. So if you, as an OpenSSL expert, tell me that our use of EVP_ and HMAC_ cryptographic functions needs multi-threaded protection, else crashes could occur, I can pass this on to the other people involved, since I can not enforce decisions although I am a C++ programming expert. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Using OpenSSL cryptographic functions in a multi-threaded application
Bobby Krupczak wrote: Hi! We are using only the OpenSSL cryptographic functionality, the EVP and HMAC functions, in a multi-threaded application. Do we need to do anything to ensure thread safety ? The documentation mentions CRYPTO_set_locking_callback() and CRYPTO_set_id_callback() but we are not calling these functions nor have we put critical sections in our own code before calling the cryptographic functions. We are experiencing some crashes and attempting to track them down and thought our use of OpenSSL may be faulty. Yes you need to do a few things. The ORA Network Security with OpenSSL documents the few stubs you need to in order for openssl to work with pthreads as well as windows threads. You can even download the example code from the net. What is the link for the above ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Using OpenSSL cryptographic functions in a multi-threaded application
We are using only the OpenSSL cryptographic functionality, the EVP and HMAC functions, in a multi-threaded application. Do we need to do anything to ensure thread safety ? The documentation mentions CRYPTO_set_locking_callback() and CRYPTO_set_id_callback() but we are not calling these functions nor have we put critical sections in our own code before calling the cryptographic functions. We are experiencing some crashes and attempting to track them down and thought our use of OpenSSL may be faulty. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
