358440 - API and syntax to adjust enabled NSS cipher suites

Status: NEW

(NSS :: Libraries, defect)

Description

[Chris Newman]

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.

Comment 1

[Chris Newman]

Attachment: 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.

Comment 2

[Anton Bobrov]

+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.

Comment 3

[Rich Megginson]

+1 openssl compatability - would help tremendously towards porting openssl apps to use NSS

Comment 4

[Rich Megginson]

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"