Re: NSS 3.14 release
Hi, I'm trying to provide that version as an RPM package and also run the testsuite within the build process. With that version the testsuite fails: [ 1202s] chains.sh: #2294: Test that OCSP server is reachable - FAILED [ 1202s] chains.sh: #4023: Test that OCSP server is reachable - FAILED [ 1202s] chains.sh: #6393: Test that OCSP server is reachable - FAILED Is it trying to reach an external server here? That wouldn't work in that build environment. Is there a way to change that? I already have export BUILD_OPT=1 export HOST=localhost export DOMSUF= export USE_IP=TRUE export IP_ADDRESS=127.0.0.1 in my environment. Thanks, Wolfgang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.14 release
julien.pie...@oracle.com wrote: Oracle still ships NSS with many products even though we are no longer actively involved with its development. It is important to have somebody at least monitoring the bugs filed/fixed in the NSS component in bugzilla. See https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch for how you can subscribe to a feed of all NSS bug discussions. Chris Newman wrote: --On October 24, 2012 22:19:40 -0700 Julien Pierre julien.pie...@oracle.com wrote: Oracle still ships NSS with many products even though we are no longer actively involved with its development. We do pick up new releases from time to time. We picked up 3.13.x last year and I'm looking into picking up 3.14 . 2) - The NSS license has changed to MPL 2.0. Previous releases were released under a MPL 1.1/GPL 2.0/LGPL 2.1 tri-license. For more information about MPL 2.0, please see http://www.mozilla.org/MPL/2.0/FAQ.html. For an additional explantation on GPL/LGPL compatibility, see security/nss/COPYING in the source code. This may be a serious problem also, but IANAL, so that is not for me to decide. Will vulnerability fixes can be provided on the NSS 3.13.x patch train? And if so, is there a date when vulnerability fixes will no longer be provided for that version? First, I think pretty much everybody agrees that, concerns about backward compatibility aside, the changes that were made were all positive. And, so, we have to balance backward compatibility with old versions of NSS with compatibility with websites on the internet and compatibility with web browsers. Now, there are no people actively contributing to NSS that are arguing in favor of absolute backward compatibility. AFAICT, there is no plan to work on 3.13.x any more. IMO, it is better to continue to focus development on the trunk. Even if somebody were to backport fixes to 3.13.x, then that work would also be under the MPL 2.0, for various reasons that, at this point, I think we cannot do anything about. For example, all the fixes in the new version are assumed to have been contributed under MPL 2.0. See the MPL 2.0 FAQ that contains the email address to send licensing questions to: http://www.mozilla.org/MPL/2.0/FAQ.html Also, I thought the goal was/is to remove the bypass mode code soon. Perhaps that decision will partly be based on how much it gets in the way of the TLS 1.2 implementation? I would be surprised if we required the TLS 1.2 implementation to support the bypass mode. By the way, I think it would be very useful to know what causes the difference in performance between the bypass mode and the non-bypass mode, to see if we can optimize the non-bypass mode so that everybody (including users of NSS outside of libssl) can get the performance improvements. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.14 release
Julien Pierre wrote: I know what code changes are necessary. I'm only a developer on a couple of NSS applications at this point, not an NSS maintainer. If this was only about those couple of apps, it wouldn't be an issue. But there are other apps in Oracle that could be affected. I can safely say that tracking and modifying every single app that this binary compatibility change may affect is not going to happen at Oracle at this point. Many other apps may not have the same kind of tests we have for ciphers and won't even catch the issue. As NSS gets distributed as patches to many existing application, binary compatibility is a requirement. Generally everybody is trying to maintain binary compatibility by default. But, there are other concerns too, such as compatibility with other implementations, and/or cost of maintenance issues, that may sometimes outweigh any binary compatibility requirement. Regarding the cipher suite changes, I think that overall, more applications will benefit than will be hurt. In fact, although it is probably the case that some Oracle products are affected, it isn't clear from your message whether the effect is negative or positive. I agree that they should be, but the decision of the defaults was always up to the application until now. When an application does not explicitly set the set of enabled cipher suites, and/or it doesn't set a particular SSL option, then IMO it is saying Let the NSS library decide what is best for me. If that isn't a good policy for an application, then it should set the options explicitly. Unless the DES ciphers were broken, I don't see the rationale for this change. These were the not the 3DES ciphers; they were the original, weak, DES ciphers. In 2012 it is not worth analyzing whether DES ciphers are strong enough to keep enabled, because it is clear that they are obsolete, and everybody recommends against their use. But, also, see: http://en.wikipedia.org/wiki/Data_Encryption_Standard#Security_and_cryptanalysis In 2008 their COPACOBANA RIVYERA reduced the time to break DES to less than one day, using 128 Spartan-3 5000's. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.14 release
--On October 26, 2012 11:52:47 -0700 Brian Smith bsm...@mozilla.com wrote: julien.pie...@oracle.com wrote: Oracle still ships NSS with many products even though we are no longer actively involved with its development. It is important to have somebody at least monitoring the bugs filed/fixed in the NSS component in bugzilla. See https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch for how you can subscribe to a feed of all NSS bug discussions. Thanks, I subscribed. Chris Newman wrote: Will vulnerability fixes can be provided on the NSS 3.13.x patch train? And if so, is there a date when vulnerability fixes will no longer be provided for that version? First, I think pretty much everybody agrees that, concerns about backward compatibility aside, the changes that were made were all positive. I consider the license change a big negative at a minimum because it will cause several engineers to waste time interacting with lawyers. I consider the technical changes positive to the degree I understand them, including the compatibility changes (I don't share Julien's concerns on that point). And, so, we have to balance backward compatibility with old versions of NSS with compatibility with websites on the internet and compatibility with web browsers. Now, there are no people actively contributing to NSS that are arguing in favor of absolute backward compatibility. AFAICT, there is no plan to work on 3.13.x any more. IMO, it is better to continue to focus development on the trunk. Even if somebody were to backport fixes to 3.13.x, then that work would also be under the MPL 2.0, for various reasons that, at this point, I think we cannot do anything about. For example, all the fixes in the new version are assumed to have been contributed under MPL 2.0. See the MPL 2.0 FAQ that contains the email address to send licensing questions to: http://www.mozilla.org/MPL/2.0/FAQ.html I can't provide any MPL 2.0 code to customers with problems unless/until my employer's legal department approves doing so. - Chris -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.14 release
On Thu, 2012-10-25 at 15:36 +0200, Wolfgang Rosenauer wrote: With that version the testsuite fails: [ 1202s] chains.sh: #2294: Test that OCSP server is reachable - FAILED [ 1202s] chains.sh: #4023: Test that OCSP server is reachable - FAILED [ 1202s] chains.sh: #6393: Test that OCSP server is reachable - FAILED Is it trying to reach an external server here? Yes. Because NSS doesn't contain OCSP server code yet, the test suite currently depends on contacting an external server (running on host kuix.de). That wouldn't work in that build environment. Is there a way to change that? Not right now. You'll have to disable the test, or ignore those failures in your restricted environment. Removing that dependency will require contributions to https://bugzilla.mozilla.org/show_bug.cgi?id=663733 Regards Kai smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.14 release
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=151846view=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
Re: NSS 3.14 release
--On October 24, 2012 22:19:40 -0700 Julien Pierre julien.pie...@oracle.com wrote: 2) - The NSS license has changed to MPL 2.0. Previous releases were released under a MPL 1.1/GPL 2.0/LGPL 2.1 tri-license. For more information about MPL 2.0, please see http://www.mozilla.org/MPL/2.0/FAQ.html. For an additional explantation on GPL/LGPL compatibility, see security/nss/COPYING in the source code. This may be a serious problem also, but IANAL, so that is not for me to decide. Will vulnerability fixes can be provided on the NSS 3.13.x patch train? And if so, is there a date when vulnerability fixes will no longer be provided for that version? - Chris -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.14 release
Wan-Teh, Thanks for your response, comments inline. On 10/25/2012 11:17, Wan-Teh Chang wrote: 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=151846view=markup I know what code changes are necessary. I'm only a developer on a couple of NSS applications at this point, not an NSS maintainer. If this was only about those couple of apps, it wouldn't be an issue. But there are other apps in Oracle that could be affected. I can safely say that tracking and modifying every single app that this binary compatibility change may affect is not going to happen at Oracle at this point. Many other apps may not have the same kind of tests we have for ciphers and won't even catch the issue. As NSS gets distributed as patches to many existing application, binary compatibility is a requirement. 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. I agree that they should be, but the decision of the defaults was always up to the application until now. This is also why we disabled SSL 2.0 by default in NSS 3.13 (https://bugzilla.mozilla.org/show_bug.cgi?id=593080). SSL 2.0 has been broken for some time, and nobody can argue with changing that default, certainly not me. But adding new ciphers to the default list is a different kind of change. Unless the DES ciphers were broken, I don't see the rationale for this change. 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. Thanks ! 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. Great ! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.14 release
Oracle still ships NSS with many products even though we are no longer actively involved with its development. We do pick up new releases from time to time. We picked up 3.13.x last year and I'm looking into picking up 3.14 . 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. 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 ? 2) - The NSS license has changed to MPL 2.0. Previous releases were released under a MPL 1.1/GPL 2.0/LGPL 2.1 tri-license. For more information about MPL 2.0, please see http://www.mozilla.org/MPL/2.0/FAQ.html. For an additional explantation on GPL/LGPL compatibility, see security/nss/COPYING in the source code. This may be a serious problem also, but IANAL, so that is not for me to decide. 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. 4) SSL PKCS#11 bypass is now conditionally built. https://bugzilla.mozilla.org/show_bug.cgi?id=745281 I understand that nobody but Oracle is using bypass at this time. I appreciate the efforts not to delete the code altogether. 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
