Nelson B Bolyard wrote:
> 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.
OK, fair enough, I had a mistaken impression there.
But how many apps do this? And what happens to an app when several of its
dependent libraries all use NSS and attempt to reset their known
state-of-the-world?
>> 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.
Present as of when? I just CVS updated my Mozilla source tree yesterday and
did a full clean build; I still see cert8.db files in the tree.
>> 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.
And apparently nothing prevents one library's configuration changes from
affecting the active configuration another library expected. To be usable in
the environments we're being asked to go into, NSS needs to use per-caller
contexts, not a single global context.
>> 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.
For unattended server use, ultimately some key must reside somewhere in
accessible storage. Whether it takes 20 password lookups to get there or none,
the end result is the same. But one way is more *usable*.
>> 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.
Fine. But this sort of arbitrary exclusion of platforms just because nobody
needed it that particular day doesn't exactly inspire confidence.
>> 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.
Then there should not be any XP_* ifdef's anywhere in the NSS code.
That aside, I'm not too thrilled about adding the overhead of NSPR either; in
most cases it's not adding significant value.
>> 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?
Did any of those FIPS audits red-flag the above code snippet?
>>>> 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?
I think those APIs are fine. You're just lacking a function for mapping from
cipher suite names to numbers, that's all.
>>> 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.
I'm looking... But that answer just reinforces the perception that NSS is a
special-purpose library (tailored to the browser) and not really designed for
general-purpose use.
> 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.
I'm just easily offended... ;)
When these algorithms are already public knowledge all over the world,
facilitating these restrictions only places an artificial restriction on your
users, and encourages them to use other solutions that don't place artificial
restrictions on them. Ultimately it harms the authors of the software, just as
government bans on new types of medical/genetic research etc. harm one country
because researchers move their work to other countries without those
restrictions.
Any time I see that a capability exists but I may be artificially prevented
from using it, I get offended...
>>>> 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.
What you're talking about just imposes a greater maintenance burden (on
someone; I'm not sure who gets the responsibility here). What human
administrator is going to want to edit a file full of bare numbers? Someone
has to provide a mapping of numbers to human-readable names and currently that
mapping only exists inside the source code, which is generally not at the
fingertips of the end-users. As for I18n/L10n - there's a class of strings for
which L10n is not desirable, because it just causes unnecessary fragmentation
of the knowledge base. E.g., googling for error messages - as much as we try
to make error messages meaningful, inevitably your users come along and ask
"what does 'This certificate is expired' mean?" When all the error messages
are written in a single language, you're guaranteed to get more hits and more
chances of finding a useful explanation.
In this case, it's no big deal to me whether the cipher suite names are
standardized or not. I just want a command line tool that tells me the names
of the suites that are compiled into my currently installed version of the
system, so that I know what suites I can tell the system to use and I can
distinguish between them easily. A stream of numbers tells me nothing.
> 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.
OK.
>> 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.
Not just app developers... I recall evaluating a "secure sockets" product from
(one of your competitors back in the 90s) that encrypted connections (using
their own proprietary protocol) but didn't use any kind of checksum on the
stream. It was trivial to inject random/garbage data into those connections
and cause the programs on one or both sides of the connection to crash. With a
little more effort one could probably have injected well-formed data without
detection...
> 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).
I see no problem with providing secure defaults. I think in current versions
NSS disables SSL2 by default; that makes perfect sense. I'm not opposed to
trying to make it harder to weaken your security. (The whole exportpolicy
thing does the opposite though - it explicitly weakens your security...)
On the flip side, it's obvious that security isn't something you can
shrink-wrap in a box. It takes education, knowledge, and vigilance. When you
go into it knowing "the field is wide open, you can easily shoot yourself in
the foot, so be careful" I think that encourages more careful development than
saying "here you go, everything in here is perfectly safe".
> 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.)
I think your post was pretty well written and I understand where you're coming
from.
>> 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 :).
They must be using it in pretty simple scenarios so far. The whole "who called
NSS_Init first" game is really pretty fundamental...
--
-- 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
