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]

Reply via email to