Cipher suites are only defined as a set of C preprocessor macros. There is no way for an application to operate with suites that were defined in the library after the app was written. Likewise, there is no way for users to obtain a human-readable list of the cipher suites that are supported in the current version of the library.
For comparison, in OpenSSL you can use "openssl ciphers -v" and in GnuTLS you can use "gnutls-cli -l" to see what they support. Without this information it's difficult/impossible for end users to configure which cipher suites to enable in an application.
Functions are needed to enumerate all of the supported suites, and also to parse a text suite name into the library's internal identifier form.
Rich M supports this request, he says this feature would simplify life for application development.
To expand upon what Howard said:
For example, in firefox about.config, it gives the following list:
NSS should provide cipher API functions that accept a string like "ssl3.rsa_aes_256_sha" instead of a integer. For example, instead of
rv = SSL_CipherPrefSetDefault(TLS_RSA_WITH_AES_256_CBC_SHA, PR_TRUE);
we could use
rv = SSL_CipherPrefSetDefaultString("tls10.rsa_aes_256_sha", PR_TRUE);
rv = SSL_CipherPrefSetDefaultString("tls10", PR_TRUE);
to enable all tls10 cipher suites.
There are several such API functions like SSL_CipherPrefSet, SSL_EnableCipher, etc.
Or, if this is not possible, at the very least, a function like SSL_CipherStringToInt() which will, given a string, return the integer cipher suite identifier, or in the case of a protocol like "tls10" return an array/list of values.
In addition, there should be an API function that will list all of the values. Support should be added to the command line utilities to print out the current list of ciphers e.g.
Note that this is duplicate code that every single app that uses NSS has to provide in some manner, often with conflicting and incompatible "short, descriptive name" strings for the cipher suites, leading to even more confusion.
This also leads to upgrade hassles. Since every application has to maintain the list of cipher suite strings, when the application wants to support a new version of TLS, the hard code string/int map in _every application_ has to be changed.
This functionality should be provided by NSS instead.
This request is similar to one I made in bug 358440.
FYI, current NSS APIs can enumerate available cipher suite names with SSL_GetCipherSuiteInfo. It's a bit cumbersome, but workable. And it uses the RFC standard identifier names which I think is appropriate. See sample code in attachment to bug 358440.
(In reply to Kai Engert (:kaie) from comment #1)
> Rich M supports this request, he says this feature would simplify life for
> application development.
Wow, no shit.
4 years for a productive response. Nice job guys. Allow me to congratulate you again on both the Fine Quality of your API design, as well as your sterling support of your community.
Wake me up in another 4 years, maybe you'll actually have done something useful by then. Meanwhile the OpenLDAP Project will continue to give NSS the loud deprecation it soundly deserves.
Howard, please see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Created attachment 8341806 [details]
Enumeration of cipher suites is already possible, see attachment; compile with
> gcc -O2 -Wall -Wextra -o ciphers ciphers.c $(pkg-config --cflags --libs glib-2.0 nspr nss)
Making the string->integer direction more convenient would probably make sense (or is that already bug #358440)?
(In reply to Kai Engert (:kaie) from comment #6)
> Howard, please see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Kai - I wouldn't waste my time submitting the bug report in the first place if it wasn't for very good reasons. If it takes this pathetic project 4 years to wake up to the fact that its stinking API needs help, and even admit that this bug report is valid, then these guys deserve every bit of flack that comes its way. Note also that I'm not one to just sit on the sidelines and complain - I write patches to fix flaws when I find them, but even those get ignored by these guys. They are too stupid to recognize they're broken and too stupid to accept help when it's offered. That's a formula for an open source project that deserves to wither away and die.
RedHat talks up a great game about crypto consolidation http://fedoraproject.org/wiki/FedoraCryptoConsolidation but picks the lamest technology as a starting point. In the open source world, technological merit wins, and there's no merit here. All they've done is make life harder for open source developers everywhere, because they've intentionally promoted an inferior technology that now everyone has to support in addition to everything else we already had working.