On Wed, Oct 24, 2012 at 10:19 PM, Julien Pierre <julien.pie...@oracle.com> wrote: > > The following changes may be problematic : > > 1) * New default cipher suites > > ( https://bugzilla.mozilla.org/show_bug.cgi?id=792681 ) > > The default cipher suites in NSS 3.14 have been changed to better > reflect the current security landscape. The defaults now better match > the set that most major Web browsers enable by default. > > This doesn't just affect browsers. There are other client apps that were > written with the existing defaults in mind.
Any client apps that care about the exact cipher suites enabled need to enable and disable each cipher suite explicitly. This Chromium code in this file can be used as code example: http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/nss_ssl_util.cc?revision=151846&view=markup Search for "Explicitly enable exactly those ciphers with keys of at least 80 bits" in that page. You can use different criteria appropriate for the client app. > I could understand if this change was only about removing cipher suites that > have had vulnerabilities removed from the default list. But this not the > case, and some ciphers were also added. > It would appear to be a binary compatibility problem. Some applications may > not behave as intended without both a source change and recompilation, ie. > some ciphers will be enabled when they are not expected to be. > This change will break one of the test suites we have with our web server > and traffic director applications, in particular. > > If this change was done in order to save a few lines of code in the browser > at the cost of breaking existing applications, it doesn't seem like a good > tradeoff. > In the past, binary compatibility was always maintained for minor NSS > releases. Was it the deliberate intent of NSS 3.14 to break binary > compatibility ? You need to change your tests to explicitly enable the desired cipher suites and disable the undesired cipher suites, and not depend on the defaults. Sorry about the inconvenience. In year 2012, AES cipher suites, rather than (single) DES cipher suites, should be enabled by default. We decided to break this compatibility to improve security. This is also why we disabled SSL 2.0 by default in NSS 3.13 (https://bugzilla.mozilla.org/show_bug.cgi?id=593080). Note that we waited another two years to change the cipher suite defaults. I think this is already very conservative. > 3)* Support for TLS 1.1 (RFC 4346) has been added > > ( https://bugzilla.mozilla.org/show_bug.cgi?id=565047 ) > > To better support TLS 1.1 and future versions of TLS, a new version > range API was introduced to allow applications to specify the desired > minimum and maximum versions. These functions are intended to replace > the now-deprecated use of the SSL_ENABLE_SSL3 and SSL_ENABLE_TLS socket > options. > > Q: will unmodified applications that use the deprecated interfaces still > continue to work identically ? This appears to be the case from reading the > above bug, but I want to make sure that is correct. Yes, I confirm that. > 4) SSL PKCS#11 bypass is now conditionally built. > https://bugzilla.mozilla.org/show_bug.cgi?id=745281 > > ... > I would like to know if the bypass feature got tested when the patch was > created, and whether it will still be getting tested at all going forward > other than at Oracle. Yes. The default NSS build still compiles the SSL PKCS#11 bypass code. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
