On 01/17/2011 06:28 PM, Kaspar Brand wrote:
On 17.01.2011 13:38, Bernhard Thalmayr wrote:
Apache httpd 2.2.17
and what MPM are you using?
Worker MPM is used , but is configured so start multiple processes (default)
Is it possible that the
Connection::initialized boolean might not be shared among the httpd
processes, resulting in multiple (concurrent) NSS initializations?
Would this be a problem? The Agent codes has always worked this way for
multi-process servers.
Not sure. But when you say "has always worked this way for multi-process
servers", does this mean it worked with previous Apache httpd versions?
I had been employed at Sun/iPlanet for last 10 years and I've never run
into this issue ....
Did you also try with the prefork MPM (which is the default for the
CentOS-bundled version of httpd)?
Not yet...
Also, are "CertDir" and "dbPrefix" set in your configuration?
They are not set.
If not,
Connection::initialize() would call NSS_NoDB_Init, which isn't intended
for SSL operations, from what I understand
(http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1234224).
Hmm if this is true then the Agent code should exit and should not call
'NSS_NoDB_Init'. However how could 911 handshakes be made if this holds
true?
Well, unless I'm completely misreading the following code,
Connection::initialize will proceed with NSS_NoDB_Init if certDir is not
set:
if (certDir.length() != 0) {
Log::log(Log::ALL_MODULES, Log::LOG_DEBUG, "Connection::initialize()
"
"calling NSS_Initialize() with directory = \"%s\" and "
"prefix = \"%s\"", certDir.c_str(), dbPrefix.c_str());
nssMethodName = "NSS_Initialize";
secStatus = NSS_Initialize(certDir.c_str(), dbPrefix.c_str(),
dbPrefix.c_str(), "secmod.db",
NSS_INIT_READONLY|NSS_INIT_FORCEOPEN);
} else {
Log::log(Log::ALL_MODULES, Log::LOG_DEBUG, "Connection::initialize()
"
"CertDir and dbPrefix EMPTY -- Calling NSS_NoDB_Init");
nssMethodName = "NSS_NoDB_Init";
secStatus = NSS_NoDB_Init(NULL);
}
I meant it might be a bug in Agent code to call 'NSS_NoDBInit' ...
however this code has been there for some years already.
If this is a bug ... how can SSL handshake work at all? It does not fail
over time, but it fails somehwere in time.
If the error once occured NSS can not recover from it.
I'm not 100% sure but it seems the error does only occur on SSL restarts
.. not on full handshakes.
-Bernhard
Kaspar
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
