Nelson B. Bolyard wrote:
Peter Djalaliev wrote:
Hello,
I am trying to upgrade a normal HTTP connection to SSL in the Apache
mod_nss module.
So, You're the source of all those questions I've been getting! ;-)
I don't know if Rob C. announced it, but there is now a mod_nss for
Apache that can be used instead of mod_ssl -
http://directory.fedora.redhat.com/wiki/Mod_nss
Fedora DS uses it as part of the Admin Server.
When the mod_nss module is initialized, it calls:
- PR_Init
- PK11_ConfigurePKCS11
- NSS_Initialize
- NSS_SetDomesticPolicy.
Also, I can see that 8 ciphers are being set with SSL_CipherPrefSet()
Here are the NSS-related function calls that I make:
- PR_CreateIOLayerStub return a file descriptor "ssl"
That's a little unusual, but only a little.
- SSLImportFD(NULL, ssl)
- SSL_HandshakeCallback(...)
- SSL_ResetHandshake(ssl, PR_TRUE)
Your list of 8 NSS/NSPR functions down to this point doesn't include
ANY functions for the configuration of an SSL socket. Well, you did
mention SSL_CipherPrefSet(). Perhaps you did not list all the NSS
functions called by mod_nss ?
and then a loop invoking SSL_ForceHandshake(ssl) that terminates when
the SSL handshake callback function has been called.
However, when I call SSL_ForceHandshake, I get this assertion failure:
in ssl3_config_match_init() in ssl3con.c
Assertion failure: numPresent > 0 || numEnabled == 0
Does anybody have an idea why this assertion fails?
libssl uses replaceable locally configured PKCS#11 modules to do all
the crypto. The capabilities of those modules may vary. A user might
enable a cipher suite that requires a cryptogrpahic algorithm that is
not available (or more precisely, a set of cryptographic algorithms that
are not available on the same token).
libssl also needs to be correctly configured with certs and private keys.
So, in the course of actually setting up all the data to do the work,
libssl goes down the list of cipher suits enabled by the application,
and checks to see how many of them have all the necessary cryptographic
support from the underlying PKCS#11 modules, including certificates, and
public and private keys.
If it concludes that NONE of the enabled cipher suites has all the crypto
support that it needs, then this assertion triggers. That's what happened
to you.
Given that your list of called NSS functions above didn't include the
functions to configure the SSL socket with certs and keys, I'd guess you
didn't do that, and so ssl3_config_match_init found no certs and keys
for any cipher suites.
One more thing: http upgrade is EVIL. :-/
Why? And does that apply to LDAP upgrade as well? Because the
recommended way to use TLS with LDAP is to use the startTLS extended
operation on the unsecure port to upgrade the connection to TLS.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
