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