Re: proposal, library error codes for TLS failures

[Dmitri Pal <dpal@redhat.com>]

On 04/17/2012 05:21 PM, Howard Chu wrote:
> Jan Vcelak wrote:
>>>   About the -Z option (attempted TLS without verification):
>>
>> Actually this is not about -Z behavior. I just mentioned in the mail,
>> that it would be great if the library provided more information
>> about the type of the failure.
>
> Perhaps more context about where this perceived need is coming from
> would have helped the public discussion. Dmitri Pal @ Red Hat pointed
> me to a bug report that seems to have been the catalyst for this
> request. We exchanged a few responses and I thought it would be useful
> to re-join the public conversation.
>
> Dmitri Pal wrote:
> > On 04/17/2012 01:43 PM, Howard Chu wrote:
> >> Dmitri Pal wrote:
> >>> I did not say it is a major problem but we have seen multiple
> times on
> >>> our community lists people trying to setup TLS for SSSD (openssl
> or nss)
> >>> manually and getting the certificate problems that are hard to
> diagnose.
> >>> Here is one of them filed by our QE as we followed up on one of the
> >>> community threads: https://bugzilla.redhat.com/show_bug.cgi?id=640393
> >>> And as you see it is not on the NSS or openssl level. If the paths
> are
> >>> not configured properly (a typo in the path for example) you will
> get a
> >>> certificate error but it is actually a wrong path. Unfortunately the
> >>> lowest layer that knows about the issue is openldap not underlying
> >>> crypto module.
> >>> This is the kind of issue that we want to fix.
> >>
> >> This is exactly the kind of issue that NSS makes messy to fix.
> >> Normally we know that cacertdir and cacert must point to a directory
> >> and a file, respectively. It would be feasible to check access(path,
> >> R_OK) or something at the time that an app calls ldap_set_option() on
> >> them. But with NSS, these parameters might be something else entirely
> >> - a DB path and a cert name within the DB, and such pathname-based
> >> checks would give spurious failures.
> >>
> >> Because of NSS, nobody but the underlying crypto module knows what
> >> these parameters actually mean.
>
> I.e., it is not an OpenLDAP level issue, it is precisely an NSS issue.
>
> >> path not found/no permission is certainly a common failure condition,
> >> but running in debug mode makes that obvious, because the explicit
> >> error text is logged on stderr.
> >>
> >> If I configure slapd.conf with
> >> TLSCACertificateFile /some/bogus/path
> >>
> >> and try to start it, I get:
> >>
> >> TLS: could not load verify locations (file:`/some/bogus/path',dir:`').
> >> TLS: error:02001002:system library:fopen:No such file or directory
> >> bss_file.c:169
> >> TLS: error:2006D080:BIO routines:BIO_new_file:no such file
> bss_file.c:172
> >> TLS: error:0B084002:x509 certificate
> >> routines:X509_load_cert_crl_file:system lib by_file.c:274
> >> 4f8daa38 main: TLS init def ctx failed: -1
> >> 4f8daa38 slapd destroy: freeing system resources.
> >> 4f8daa38 slapd stopped.
> >> 4f8daa38 connections_destroy: nothing to destroy.
> >>
> >> It's quite obvious "No such file or directory".
> >>
> >> If the cause of failure isn't as obvious with NSS, then again I have
> >> to say, it seems to me that you're looking in the wrong place for a
> >> solution.
> >>
> >> It strikes me that it would benefit the community for this
> >> conversation to be public, e.g. on the openldap-devel mailing list.
> >
> > We can do it there. I sent a subscription request. Do you want to start
> > this conversation over there from the beginning?
> > There is already a thread that I wanted to draw you attention to and it
> > turned into this discussion. May be you can just cut and paste you
> > comments from this thread into the public thread and we take it from
> there?
>
> That's the on-topic bit, but I felt it's important to also address
> this side-note:
>
> > On the side note about NSS. I am kind of surprised a bit with your
> view.
> > The move to pluggable crypto modules is an industry trend not something
> > NSS team invented. And there is a big push for the ECC for example
> which
> > NSS does not support. So there will be other solutions and other crypto
> > modules. Creating a clean abstraction around it is a logical next step
> > so blaming that NSS destroyed a perfect world dominated by open SSL
> is a
> > bit strange. I agree that it is work and annoying but seems like the
> > right thing to do from the interoperability and flexibility point of
> > view. Isn't it the strength of the open source and community
> development
> > model?
>
> This is a much larger philosophical question; I'm pretty sure we've
> disagreed on this before in the past ;)  I am certainly not arguing
> against developing clean, modular abstractions.
>
>
> My perspective: life is short. I don't just write software for the
> sake of writing software. I write to create something Good and Free,
> because I believe it's important that the sum total of human knowledge
> is increased, and that people are able to learn from the work that has
> been done, and that the work is worthy of learning from.
>
> Coincidentally, in the landscape that existed when the OpenSSL and
> OpenLDAP Projects began, they were the only open source games in town.
> But my perspective didn't change when Mozilla became open source. (And
> that's not just mother duck syndrome either; I've been thru the
> Mozilla code base inside and out.)
>
> Good *and* free are my constraints. Simply being free is not
> interesting; there are many free projects out there that are drivel.
> GnuTLS is garbage.
>
> Like GnuTLS, MozNSS is inferior by design, and by designer mindset.
> OpenSSL may not be perfect, but it at least takes the correct attitude
> of being a toolkit, not a polished solution. Security is not a simple
> thing to acquire or deliver, it cannot be neatly shrink-wrapped.
>
> NSS takes the (demonstrably false) attitude that security *is* a
> neatly shrink-wrapped package. This is evident even from the outside,
> where its proponents brag that NSS is FIPS-validated, and that any app
> that uses it is also automatically FIPS-validated, whereas OpenSSL is
> claimed to be inferior because apps that rely on it must be
> individually FIPS-validated.
> [1]http://fedoraproject.org/wiki/FedoraCryptoConsolidation
>
> Anyone who knows anything about computer security can see the obvious
> fallacy here - security is not magic fairy dust that you can sprinkle
> on any application (i.e. link with NSS) and suddenly be secure. It
> must be carefully considered and taken as a whole.
>
> NSS takes the attitude that the NSS developers know everything and
> that app developers know nothing. And that secure computing can be
> isolated inside a single trusted base and applied uniformly to all
> applications. This might have been true when there was only one app to
> deal with, the Netscape browser, but it is not true in the Brave New
> World that RedHat has thrust it into.
>
> In the real world, different apps operate in different trust domains
> and have different requirements. I don't want my LDAP server to use
> the same trusted certificate store as my HTTP client. I don't want my
> LDAP client to trust the same certificates as my SMTP client.
>
> NSS developers started from the position of believing they know
> everything about how security must operate, and have created a library
> that only works one way. The OpenSSL developers started from the
> position of believing they know little, and have created a code base
> that can be used in myriad ways.
>
> Open source is not just an intellectual exercise, it's not just a
> vehicle for novice programmers to learn their craft. It is not just a
> vehicle for commercial enterprises to acquire new products at zero cost.
> We want to do useful work, as quickly as possible, so that we can
> leverage as much as possible and advance society as far as possible
> within our lifetimes. You don't get there by fragmenting the community
> and constantly re-treading the same path. You don't get there by
> constantly flogging the same horse that already died years ago. You
> pick the best technology and push it further, expanding the boundaries
> of human knowledge. The work we've done to support MozNSS and GnuTLS
> in OpenLDAP has been IMO a waste of time and energy, forcing us to
> re-tread well established paths instead of focusing on new capabilities.
>
> There's nothing gained by having two different ways to do exactly the
> same thing. There's something lost by having to support multiple ways
> of doing almost the same thing. Losses in time, mental energy, and
> overall efficiency, at least.
>


Oh well... This is a completely philosophical exercise.  I am not
necessarily in favor of NSS or OpenSSL or some other crypto solution.
They just exist and given. We would not have had so many kinds of cars
if there have not been a need. There is. It does not make sense to deny
a reality on the premises that in the past everything was OK.
Things change, life goes on.
 
I value everybody's time too and understand that creating a good
abstraction is a cost especially if single solution worked in the past.
So following the rules of the meritocracy it is completely reasonable to
expect that whoever has the need does the work. And this is the case
here. But we want to do the work in the least intrusive way and to
address as many concerns as possible. So the question was and is "can
you please let us know how we should implement it to make things work
for everybody?".

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/