Thanks for your response. Shipping my own version of openssl is ruled out. So I have to trust the system installed one. Think at least on some Unix systems, LD_LIBRARY_PATH is searched first. I worry Trojan horses hidden there. I am advised to zeroing-out this env variable before loading openssl. What else I can do?
Thanks. Yvonne -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: Friday, April 18, 2008 4:53 PM To: openssl-users@openssl.org Subject: RE: Openssl loading > I have an application that is dynamically linked with openssl. > I'd like to load system installed openssl at runtime. 1) "I'd like to use the system installed openssl rather than one I know is secure." > My application can only be as secure as the openssl loaded into the > process. What steps should I take to ensure my application doesn't > load a compromised openssl library that happens to be in front of the > system installed one in library search path? 2) "I'd like to use an openssl I know is secure rather than the system installed one." This seems inconsistent. If you have some heuristical way to know which is secure and which isn't, use them. For example, if you know that one installed in the system directory is secure, then open a library from the system directory directly. I would argue that in the vast majority of cases, option 2 is the correct one. If someone wants to compromise their own system, why stop them? And it's impossible in principle for application software to ensure secure operation on a compromised machine. Which of the following cases are you in? A) I trust some system things but not others. For example, I trust DLL's that are signed or that are stores in known-safe directories. But I don't trust my search path? (In which case, the solution is obvious, check the DLLs and open them by full path.) B) I trust the machine. If it's compromised, oh well, I can't operate safely on a well-compromised machine anyway. (In which case, just open the DLLs.) C) I don't trust the machine and my interests may be averse to the machine owner's interests (for example, a licensing application). (In which case, use only your own DLLs, checksum or sign them, probe for debuggers, and so on.) D) I have to meet explicit regulatory or project requirements, such as FIPS. (In which case, follow them. You will likely have to do most of what I said in case C.) E) Something else. (In which case, more details are needed before you will get useful advice.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]