Howard Chu wrote, On 2008-08-10 14:13:
> 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.
A process can add or remove modules from its running configuration.
It can have many modules. Having a DB that remembers them reduces the
amount of work an application must do every time at startup, that's all.
It makes the developer's life easier, not more limited.
> It means that every user has a complete copy of all of the CA
> certificates in each of their home directories,
That's false. As a counter example, a single copy of nssckbi, the PKCS#11
module that holds Mozilla Foundation's chosen root CA certs, suffices for
all users.
> 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.
It doesn't force that. A user/application can have as many modules as he
wants, each with its own storage of cert.
> Likewise it keeps all of the private keys in the same place.
No, The user/app can have as many modules as the user wants, and they can
be in as many directories as the user wants.
> 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.
The old cert8.db files, which could not be shared by multiple applications
simultaneously, did have that problem. The present cert9.db solves that.
> 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.
Nothing prevents each application from having its own configuration.
Nothing prevents an application from changing its configuration while it
is running. Not even with cert8.db files.
> Architecturally it's an insecure design for the default case of credentials
> residing in a filesystem.
Which is true for PEM files and NSS files, alike. NSS key DBs have always
been encrypted, which PEM files for private keys have not. But either way,
the fact that they reside on the file system remains an issue.
> 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.
Not at all clear that anything here is detrimental for users without tokens.
Most laptop motherboards now come with FIPS compliant crypto chips built in
(so called TPM chips), and many of those have PKCS#11 modules available.
Using those should really become the norm pretty soon, for people who
really care about their system's security.
> 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
That's a relic, indeed. It's only built on Mac OS/9 and earlier, not OS/X.
It's totally dead code, because we don't support OS/9 and earlier any more.
The symbol used in that ifdef is not defined in builds on any platform
presently supported.
> Anyone who has ported their server (hm, Apache? OpenLDAP?) to MacOS with
> NSS is going to wonder WTF.
Not relevant at all to OS/X.
> 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,
That is certainly not an accurate description of NSS! NSS was closed source
until the year 2000 because US law required it. But it was designed from
day one for all platforms. It uses NSPR for platform independence.
Another way to view it is: it has one platform, which is NSPR, which runs
on all the platforms supported by Mozilla products.
If there's any one platform for which it could be said that NSS was
developed first, it was SGI IRIX. :) When I started work on NSS in 1996,
nearly all the NSS developers had SGI Indy boxes.
> it needs a bottom-up audit because otherwise we really don't know what
> we're getting by using it.
Like the audit done for FIPS, 5 times now?
>>> 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);
No response?
>> 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.
Yeah, the sample code is QA code for unit tests, not GUI. It's not
exemplary from a UI perspective. People who want to see UI examples
should look at how the browser uses it.
>>> 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?
It's the library's job to make the application developer's job, of
producing products that he can export from his country of origin, and
that his customers can import to their countries of destination, and
pass any tests required for same, easier. NSS provides facilities for
that. The facilities are general.
There are three small functions that use the general policy control
facilities to implement old US policies and one old France policy.
Since the year 2000, when US export policies changed, those functions now
exist as relics of an era gone by. However, they serve as examples of how
application developers would devise similar functions for use in their own
national environments.
> 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?
If your country's government says it is, then it is. Most likely, if your
country cares about this any more (and most don't but some do) it will
require you to make specific packages for specific nations. The packages
will have the information about their target nations precompiled 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?
It does, if your country's government says it does, whether it seems logical
to you (or me) or not.
Export and import controls on crypto software haven't disappeared
everywhere. They still exist in the USA, for example. There is an
"exception" for products that are entirely open source, but products that
are not entirely open source still have to jump through hoops, even if the
crypto code they use is entirely open source (e.g. NSS). So, NSS still
provides facilities for products to use when they need them for export
control reasons. I don't know why this should offend you, really.
>>> 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."
For internationalization/localization reasons, I would expect a config file
to store info about cipher suites in numeric form, e.g. using the standard
cipher suite number, and let UI handle the representation to the user,
rather than using strings (with all their attendant I18n/L10n issues) in
configuration files. But I know that quite a few products do use string
representations of cipher suites in config files, and that quite a few
different non-standard sets of cipher suite name strings exist for that
purpose. :( As a library, all we can do is provide the tools that enable
applications to do the best job of presenting the info to their users.
We can't make them use those facilities.
>> 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.
I think the NSS team is already quite well aware of the costs of backwards
compatibility. But thanks for the concern.
I worked for various Unix system vendors for years (from the late 80's),
and I saw how their attempts to differentiate themselves in almost every
way so fragmented the Unix market that it destroyed it. Today, the Linux
market seems to be repeating many of the mistakes that the old Unix
companies made. I think there's a fresh crop of developers working on
Linux, who didn't learn from history and are repeating the mistakes.
If Linux is to gain market share, it MUST ensure that applications that
run on one Linux box will run on any linux box, and that upgrading one
application (including the libraries on which it depends) on a Linux box
doesn't break other apps on the Linux box. Users won't become or remain
loyal to Linux if they must run different apps (or different app builds)
on every distribution, and if they must spend much time getting their apps
to work again when they upgrade one app or one library.
Linux growth requires backwards compatibility, and cross distribution
compatibility, that don't seem to exist today. The fiercely independent
cowboy nature of many Linux developers who want the freedom to change
anything and everything at the drop of a hat without regard to compatibility
is keeping Linux out of the main stream. LSB's attempt to promote the
necessary forms of compatibility seems like a big step in the right
direction for Linux's success, IMO.
>> 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.
I agree that the design philosophy of NSS is quite different from that of
OpenSSL. I've been wanting to write about that for some time now (motivated
by earlier postings in this thread) and I expect I will do so
before long. Here I will just try to write a little bit about it.
In my 18+ years of developing crypto library code, I have seen a LOT of
application programmers make a LOT of mistakes with crypto, and produce
results that were highly insecure, but claimed to be secure, because they
used crypto in some fashion. Really, a LOT of it. In fact, I would say
that the MAJORITY of application programs who attempt to use crypto in
their code make big mistakes, security wise. The most common problems
I see are (re)inventing crypto protocols, which invariably are vulnerable
to attacks these newbies don't yet understand. I call what most app
developers do with crypto "fun and games with cryptography". NSS does
not exist to promote fun and games with cryptography.
There are some APIs that are designed with the philosophy that they
provide access to any and all defined algorithms and protocol variants,
the secure and the insecure alike. They put 100% of the burden of
knowing what's secure and what's not on the application developer.
They make little or no attempt to steer the application developer away
from known vulnerabilities, known insecure practices. Application
developers may love the freedom to tinker, that such libraries give them,
but the results are not likely to be highly secure.
In contrast to that, NSS is designed with the intent of helping the app
developer to achieve *security*. So, NSS tries to facilitate the
incorporation into applications of STANDARD protocols (SSL, TLS, S/MIME),
standardized APIs (PKCS#11), and standardized file formats (PKCS#12).
The developers of NSS make conscious choices about what features they
implement and what they don't, with the idea of making it easy to
develop apps that work securely, and actually more difficult to develop apps
that use encryption insecurely. That's why NSS doesn't implement
the unauthenticated (so called "anonymous") SSL/TLS cipher suites, for
example. And it's why NSS doesn't facilitate the export of unencrypted
private keys into PKCS#8 files (something for which another library is
notorious). You may call that "draconian", but it really makes a
difference in the real security delivered by the apps that use it.
I've recently received feedback from an IETF "area director" saying that
he believes that NSS's APIs still make it too easy for the application
developer to do things insecurely. He suggested that NSS go even farther
in reducing the number of ways in which an application developer can
produce an application that behaves insecurely.
(hmm, maybe there's not much left to write about that subject, but
we should probably start a new thread to pursue it, if you want to.)
> It also reflects a single-user PC mentality, which is poorly
> suited for use in servers and multi-user OS environments.
Actually, most of the developers who work on it are developing it for
servers. It is revenue from server sales that pay the salaries of
most of NSS developers (since revenues from browser sales are ... low :).
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
