Bug 816174 - creating a new TLS context always succeeds
creating a new TLS context always succeeds
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Synacek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-25 08:30 EDT by Jakub Hrozek
Modified: 2013-02-13 10:26 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 10:26:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a test program (3.62 KB, text/x-csrc)
2012-04-25 08:31 EDT, Jakub Hrozek
no flags Details

  None (edit)
Description Jakub Hrozek 2012-04-25 08:30:31 EDT
Description of problem:
According to discussion we had off-list, calling ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &flag) should force a check on the TLS parameters set.

Version-Release number of selected component (if applicable):
openldap-2.4.26-7.fc16.x86_64

Steps to Reproduce:
1. compile the attached test program
gcc ldap_tls.c -lpopt -lldap -o ldap_tls

2. run it and provide some random parameters
./ldap_tls --tls-req="hard" --cacert="/foo" --certfile="/bar" --keyfile="/baz"

Actual results:
everything succeeds:
----------------------------
tls_reqcert set to 'hard'
LDAP_OPT_X_TLS_CACERTFILE set to '/foo'
LDAP_OPT_X_TLS_CERTFILE set to '/bar'
LDAP_OPT_X_TLS_KEYFILE set to '/baz'
New context initialized
----------------------------

Expected results:
If I understood the intended usage correctly, creating a new TLS context should force some sanity checks on the parameters.
Comment 1 Jakub Hrozek 2012-04-25 08:31:23 EDT
Created attachment 580148 [details]
a test program
Comment 2 Jan Vcelak 2012-04-25 09:01:21 EDT
Unfortunatelly requesting a new TLS context does not mean initializing it.

OpenLDAP with Mozilla NSS uses deferred initialization. The context is initialized with the first connection.
Comment 3 Jakub Hrozek 2012-04-25 09:19:45 EDT
Is the situation different with OpenSSL?

Is there no way to initialize the context on demand?
Comment 4 Jan Vcelak 2012-04-25 10:16:58 EDT
Yes, OpenSSL does not use deferred initialization. The initialization would take place immediately after LDAP_OPT_X_TLS_NEWCTX option is set.

I'm not aware of any possible way of forcing the initialization. And I even don't know why exactly deferred initialization is used. It would work without it. I think it remained after the old implementation of the backend. Currently it just complicates the things.

As far as I know, Fedora and Red Hat are the only who use MozNSS backend. We can probably consider removing the deferred initialization from MozNSS and upstream could accept that. The behavior would be more consistent with OpenSSL backend. And some other stuff which is possible with OpenSSL and impossible with MozNSS would work (like entering the password for the certificate when starting slapd server).

Rich, I'm I right about the deferred initialization? Or is there any other reason why it is there now? Maybe I miss something.
Comment 5 Rob Crittenden 2012-04-25 13:09:34 EDT
I guess it depends on what you mean by initialize. Do you want it to actually make the SSL connection or simply verify that the arguments you provide exist in the filesystem?

NSS abstracts the SSL connection a lot more than OpenSSL. With NSS you just need to call PR_Read() and it takes care of the handshaking for you. With OpenSSL you have to manage a lot of this yourself.

There are ways to force a handshake to occur (like SSL_ForceHandshake) that may do what you want but you may still be required to do a read.
Comment 6 Jan Vcelak 2012-04-25 15:13:14 EDT
> I guess it depends on what you mean by initialize.

I think that Jakub needs this to recognize TLS configuration errors from connection errors. I understand initialization in OpenLDAP as loading the modules (PEM), creating NSS context, opening certdb.
Comment 7 Jakub Hrozek 2012-04-26 04:04:23 EDT
(In reply to comment #5)
> I guess it depends on what you mean by initialize. Do you want it to actually
> make the SSL connection or simply verify that the arguments you provide exist
> in the filesystem?
> 

Verifying that the arguments exist on the filesystem would be a good start, actually establishing the SSL connection might not be possible or practical anyway with all SSSD configurations (we might need to do a SRV resolution etc etc).
Comment 8 Jan Vcelak 2012-04-26 06:51:16 EDT
(In reply to comment #7)
> Verifying that the arguments exist on the filesystem would be a good start,

This can be achieved by removing deferred initialization.
Comment 9 Rich Megginson 2012-04-30 12:29:56 EDT
(In reply to comment #8)
> (In reply to comment #7)
> > Verifying that the arguments exist on the filesystem would be a good start,
> 
> This can be achieved by removing deferred initialization.

I'm not sure if deferred init is needed anymore - should try without it.
Comment 10 Fedora End Of Life 2013-01-16 09:25:35 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Fedora Admin XMLRPC Client 2013-01-30 06:10:52 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Fedora End Of Life 2013-02-13 10:26:28 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.