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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org
