Nelson B Bolyard wrote:
> Howard Chu wrote, On 2008-08-10 03:30:
> When one considers all the important reasons to choose a crypto
> implementation, support for one file format which is not used in any
> standard protocols (e.g. TLS, SMIME) doesn't seem like a biggie.
The issue isn't about a specific file format, it's about overall usability.
Ignoring the issue of hiding things in a fragile DB the problem is that it's a
one-shot monolithic configuration. A process may only call NSS_Init once, and
provides a single "configdir" argument that must contain information about all
of the certificates, keys, and security modules that the process will use.
This is an API that only makes sense in a world of single-user Microsoft
machines.
It means that every user has a complete copy of all of the CA certificates in
each of their home directories, which makes certificate management/revocation
dicy at best. It forces certificates that have logically different purposes to
all be lumped together in one place, preventing the use of fine-grained access
control to manage them. Likewise it keeps all of the private keys in the same
place. It means that servers that act as both a server and a client (e.g. a
proxy) are stuck needing to maintain a lot of extra copies of what would
otherwise be individually/separately managed credentials. It would make it
impossible to use in e.g. OpenLDAP/nss_ldap because applications would be
unable to load their own configuration settings after nss_ldap/libldap/nss
initialized.
Architecturally it's an insecure design for the default case of credentials
residing in a filesystem. It may make sense for people using hardware tokens,
but in the grand scheme of things that's a small percentage of the world;
you're optimizing a special case to the detriment of the general case.
There's other relics lying around in the code, waiting to bite:
nss/lib/nss/nssinit.c:561
#ifndef XP_MAC
/* only servers need this. We currently do not have a mac server */
if ((!noModDB) && (!noCertDB) && (!noRootInit)) {
if (!SECMOD_HasRootCerts()) {
nss_FindExternalRoot(configdir, secmodName);
}
}
#endif
Anyone who has ported their server (hm, Apache? OpenLDAP?) to MacOS with NSS
is going to wonder WTF. If they had just stuck with OpenSSL everything Would
Just Work.
Frankly, code developed under the model in which NSS was developed (closed
source for many years, targeting 1 main platform with everything else treated
as 2nd or 3rd class citizens) can't be trusted, it needs a bottom-up audit
because otherwise we really don't know what we're getting by using it.
>> the other obvious source of pain is the lack of an intuitive API for
>> selecting cipher suites.
>
> Huh? What's unintuitive about these?
>
> SSL_CipherPrefSet(PRFileDesc *fd, PRInt32 cipher, PRBool enabled);
> SSL_CipherPrefGet(PRFileDesc *fd, PRInt32 cipher, PRBool *enabled);
> SSL_CipherPrefSetDefault(PRInt32 cipher, PRBool enabled);
> SSL_CipherPrefGetDefault(PRInt32 cipher, PRBool *enabled);
>
> Further, the function
> SSL_GetCipherSuiteInfo(PRUint16 cipherSuite, SSLCipherSuiteInfo *info,
> PRUintn len);
> outputs a structure of info about any supported cipher suite, making
> it easy to construct a localized GUI for the user tho choose from among
> the offered cipher suites, and have that GUI grow automatically with new
> NSS releases, without having to recode the application. It eliminates
> or reduces application dependencies on hard coded tables of information
> about cipher suites.
And yet all of your sample code uses hard coded tables of information.
>> The notion of NSS_SetDomesticPolicy / NSS_SetExportPolicy /
>> NSS_SetFrancePolicy is quaint at best. It's a relic of a closed-source
>> legacy that makes no sense in FOSS that can be freely used anywhere in
>> the world.
>
> There are still countries in which it is a crime to use certain forms of
> encryption, open source or not. Those functions (and more that you didn't
> mention, such as
> SECStatus SSL_CipherPolicySet(PRInt32 cipher, PRInt32 policy);
> SECStatus SSL_CipherPolicyGet(PRInt32 cipher, PRInt32 *policy);
> ) continue to be useful for people making products for use in those
> countries, making it possible to implement arbitrary national policies,
> of which the 3 functions you mentioned are examples.
Is it really the software library's job to *embody* a particular country's
policies? As free software authors attempting to adopt this library, is it our
job to add code to our programs to sniff out what country we're running in?
And does it make any difference at all, when a user can simply obtain the
code, patch it as they please, and use whatever ciphers they wanted to anyway?
>> While there appears to be a function for enumerating the available cipher
>> suites and their names, it would also be convenient to have a function that
>> returns the cipher number for a given name, to make it easier to work with
>> settings read from a configuration file.
>
> And I suppose you would want such a function to use OpenSSL's non-standard
> name strings for that, right?
No, it should obviously use the strings that are already compiled in and
retrievable from your SSL_GetCipherSuiteInfo data. I'm not being unreasonable
here, just saying "a convenience function to do this would be nice."
> BTW, Are you aware of the Linux Foundation's "Linux Standard Base" (LSB)
> effort? http://www.linuxfoundation.org/en/LSB
> One of the primary considerations for acceptance into the LSB is binary
> backwards compatibility assurances from the libraries. NSS is being
> considered for the LSB as a/the standard library and interface for SSL,
> in large part because NSS has been offering shared libs with a strong
> guarantee of API and ABI backward compatibility ever since NSS was first
> released as shared libraries in 2001 (or 2002, I forget).
I've heard about that; it makes me shudder. Perpetually carrying around
obsolete cruft isn't something to be proud of. That's the same formula that
keeps Windows users in patch hell and keeps the Intel x86 instruction set in
permanent disorder; you have to allow for housekeeping and making a clean
break periodically. Otherwise you wind up having to twist like a pretzel to
add new features over time.
> If you absolutely must have every thing work exactly like OpenSSL to be
> happy, then use OpenSSL. Complaints about NSS, that it isn't exactly
> like OpenSSL aren't going to motivate NSS to change much. Absent
> cryptographic functionality is one thing. Absent emulation of OpenSSL
> is quite another. Near the beginning of this thread, I asked for people
> to report absent crypto functionality. But so far, what I've heard is:
> "It isn't OpenSSL", which is not a statement about cryptographic
> functionality.
I haven't looked closely enough yet to judge the crypto functionality, but as
someone whose been working with crypto software for 20+ years now, I think the
usability is lacking.
Fundamentally I'm sure NSS is a decent piece of code. But philosophically, its
design reflects a draconian closed-source "tightly control the user"
mentality, which is IMO antithetical to what FOSS is about. It also reflects a
single-user PC mentality, which is poorly suited for use in servers and
multi-user OS environments.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
