Patrick Patterson wrote:
Peter:
On 29/03/10 1:15 AM, Peter Waltenberg wrote:
Sure - it works if you have a simple application, main -> OpenSSL
even main ->lib doing SSL -> OpenSSL still works.
What's giving us grief (and I suspect the person who first raised this
grief) is:
main -> lib that needs SSL to do client server comms -> OpenSSL
-> Another lib that does client server comms. ->OpenSSL
-> Another lib that does crypto ->OpenSSL
All the libraries of the big fat composite application expect to be able to
access OpenSSL's function, all were created independently - the top level
app doesn't do SSL or crypto. at all - it just uses libraries that need to
do SSL or crypto to function.
This is a rather specious argument - if an application uses SSL at the
lower layers, there has to be some method for that application to at
least tell OpenSSL which CA Certificates to use - and yes, it COULD have
a wrapper/higher level lib that sets up those locations (like I think
OpenLDAP can), but I would consider that a HORRIBLE design flaw of that
higher library to not expose SOME method to set the trust store (and
revocation information, etc.) globally for the application - otherwise,
in the situation that you mention, the poor admin COULD end up with an
application where it is almost impossible to troubleshoot why certain
connections are failing i.e.: Why do my LDAPS connections work, but my
HTTPS don't? (assuming that LDAP is provided by one lib, and HTTP by
another). So I would argue that it is the higher level libs problem to:
1: Set threading correctly and consistently on all of it's SUB library
dependencies with the model the higher level app tells it to.
2: Expose enough controls that allow for a higher level app to set keys,
cert stores, and revocation information locations.
If those libraries DON'T do both of the above (and OpenSSL can certainly
accommodate both today), then the bugs/feature requests to enable both
of these functionalities should be filed there.
I'm not one of the "core" devels, but this is just my 0.02 worth.
Since we're using OpenLDAP as an example, I'll note - libldap_r's original
raison'd'etre was to provide threading in slapd. It was never intended for use
by 3rd party code; there is no IETF specification for thread support in the
LDAP C API and we've never advertised or documented libldap_r as anything
other than an OpenLDAP-specific (i.e., non-standard) library. So yes, in this
case, libldap_r was written with certain assumptions (that the threading model
is known, that it won't be unloaded while running, etc...) and it's only known
to behave correctly within those assumptions.
To your point about providing APIs to set the trust store globally for the
application: in a word, No.
libldap provides APIs to set up all the required trust settings, for a
particular SSL_CONTEXT. It initializes a single context for itself, and
typically this single context was used implicitly by any application that used
libldap (including slapd). Nowadays slapd uses one context for its main
listener, and can use a separate context for each of several other cases -
proxy sessions, replication tasks, etc. The fact is that slapd is often used
as an LDAP gateway, between unsafe external networks and brain-damaged
internal LDAP servers that aren't robust enough to face a real network on
their own. In a situation where it must act as a server on one side and as a
client on the other side, you very often need separate and distinct trusts /
policies in each role.
So regarding your comment about ldaps sessions working, but https sessions not
- that may seem like a hassle, but it's as it should be. Each protocol and
each usage of the protocol has to be able to operate in its own distinct
context. They must be able to have their security policies configured
separately. The fact that OpenSSL supports this in its most common usage is
one of its real strengths. (It is still pretty much impossible to handle this
type of requirement using e.g. Mozilla NSS.)
* most basic example: when using certificate-based authentication, typically
a server only needs to trust a single CA - the one that issued its own cert
and all of the users' certs. On the flip side, clients tend to need to be able
to talk to multiple servers, in multiple authentication realms. As such they
tend to need to be configured with many trusted CAs. When you have a single
process that can take on both server and client roles simulataneously, OpenSSL
handles the situation easily. Other SSL libraries ... not so much...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
