An application consuming NSS presently has to write a non-trivial amount of code to give customers the ability to enable/disable cipher suites. Furthermore, incautious implementations of such code are likely to do bad things, such as leaving weak ciphers on, or get out-of-sync as NSS adds new cipher suites. This situation can lead to sub-optimal constraints on the capabilities NSS provides by default, as discussed in 262186. If NSS provided an API to adjust the enabled cipher suites that takes a string argument that's extensible, not only will it simplify the task of evolving NSS with new cipher suites, but it may lead to more configuration consistency between apps that use NSS.
Created attachment 243848 [details] Sample code for how this might be done. Perhaps simplistic, but a start. I'm attaching the code I added to Messaging Server for this purpose. I wanted some backwards compatibility with legacy names, support for OpenSSL names for more consistency with other products (see URL for OpenSSL ciphers command), as well as support for the canonical names. This is more conservative and restrictive than the OpenSSL syntax (also a bit simpler) and would probably be better if it had a syntax for compound requirements (e.g. RSA+AES cipher suites), but a simple start is better than nothing. I also wanted this to continue to work as NSS adds new cipher suites.
+1 - there must be some api to activate some sort of safe, up to date set of ciphers. if backward compatibility / interoperability problems are found users can stop calling that api and rely on mechanisms currently in place to enable/disable exactly what they want/need. sucha api would be of great help to most users as it will greatly simplify things for them in a majority of situations and if such api is not possible for whatever reason there should be another one that will return up to date set of cipher suites. - asking api or regular product users to keep up to date on current cipher suites and developments in that area ie what is considered weak or flawed today is imho asking too much. how many users will actually bother enabling/disabling specific ciphers say in their browsers for example ? new FireFox seems to lack cipher prefs in its standard settings pane altogether and has SSL2 disabled by default because nobody actually cares/knows how/to tune that stuff, even geeks dont not to mention your average Joe user.
+1 openssl compatability - would help tremendously towards porting openssl apps to use NSS
Another pain point is adding support for TLS 1.2, and trying to future-proof our applications for TLS 1.3 (and 2.0?). We need to have some way to set the supported SSLProtocolRange with strings e.g. min = "TLS1.1" max = "TLS1.2". We also need to have some way to have NSS give us a protocol version string given the number, similar to how openssl SSL_get_version works. Note that the api returns a constant string - does not malloc - does not require passing in a string buffer to fill in with a value - which is really nice for application developers. For example, logging which protocol version was negotiated - logging "TLS1.2" is a lot more friendly than logging "0x0303"
You need to log in before you can comment on or make changes to this bug.