I understand the push behind getting as many packages to build against nss as possible. However, nss is not on feature parity with openssl at this time.
I've run into two problems where this has bitten me.
First, libcurl being built against nss. Nss does not provide some functions which are necessary for NTLM authentication to succeed. This has defeatured the 'curl' application, rendering it useless in environments where users are behind an NTLM-authenticating proxy. This bites me personally every day. Yes, NTLM is based on MD4 which is insecure. Nevertheless, choice of corporate proxy servers is often beyond the reach of even the most senior Linux developers (aside from changing jobs...)
Second, libcurl being built against nss. OpenWSMAN has an eventing capability, but this uses libcurl, which in turn would use a feature of openssl. But as libcurl is not built against openssl, the eventing capability at this point must be disabled in OpenWSMAN. This capability will be important to the sblim-* systems management software stack which implements DMTF open standards. I need to investigate further what the source of the problem here is.
Arguably, one should discover the missing functionalty from nss, and re-implement it so as to enable these functions. However, as these functions do work if linked against openssl, I would prefer to see the expedient approach of linking libcurl against openssl again, and only release with it linked against nss once it is at feature parity for the functions used by software within Fedora.
Can I ask that libcurl be rebuilt against openssl instead of nss for the time being?
Thanks, Matt
-- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux
Matt_Domsch@Dell.com wrote:
First, libcurl being built against nss. Nss does not provide some functions which are necessary for NTLM authentication to succeed. This has defeatured the 'curl' application, rendering it useless in environments where users are behind an NTLM-authenticating proxy. This bites me personally every day. Yes, NTLM is based on MD4 which is insecure. Nevertheless, choice of corporate proxy servers is often beyond the reach of even the most senior Linux developers (aside from changing jobs...)
Second, libcurl being built against nss. OpenWSMAN has an eventing capability, but this uses libcurl, which in turn would use a feature of openssl. But as libcurl is not built against openssl, the eventing capability at this point must be disabled in OpenWSMAN. This capability will be important to the sblim-* systems management software stack which implements DMTF open standards. I need to investigate further what the source of the problem here is.
Arguably, one should discover the missing functionalty from nss, and re-implement it so as to enable these functions. However, as these functions do work if linked against openssl, I would prefer to see the expedient approach of linking libcurl against openssl again, and only release with it linked against nss once it is at feature parity for the functions used by software within Fedora.
Can I ask that libcurl be rebuilt against openssl instead of nss for the time being?
You can, but it is obvious that a backward switch is very unlikely.
Addon of some extra functionality to NSS seems questionable as well. Perhaps, in far future only. Unlike the OpenSSL and Gnutls, NSS seems more stable, more tested, more certificated -- ie. more conservative. Hence the support of some "corner" cases is not a primary goal.
BTW, in some areas OpenSLL looks more perspective. For example, Russia have chosen other way for crypto in the state life -- so called GOST instead of RSA. OpenSSL will start to support it since 0.9.9, plans of NSS is unknown... As a result, the compulsion for NSS in Fedora can make its usage impossible in the state organisations of some countries.
Another issue is license compatibility. Whilst OpenSSL is "widely used", it can be considered as a "basic system application", hence programs may link with it anyway (due to some exception in GPL etc...). After the most of things will be switched to NSS, the OpenSSl itself will become "an optional" instead of "system basic". The correspond exception in GPL will not affect anymore, and the rest of GPL applications who still will use OpenSSL will become illegal.
Just my thoughts...
~buc
Dmitry Butskoy wrote:
Matt_Domsch@Dell.com wrote:
First, libcurl being built against nss. Nss does not provide some functions which are necessary for NTLM authentication to succeed. This has defeatured the 'curl' application, rendering it useless in environments where users are behind an NTLM-authenticating proxy. This bites me personally every day. Yes, NTLM is based on MD4 which is insecure. Nevertheless, choice of corporate proxy servers is often beyond the reach of even the most senior Linux developers (aside from changing jobs...)
Second, libcurl being built against nss. OpenWSMAN has an eventing capability, but this uses libcurl, which in turn would use a feature of openssl. But as libcurl is not built against openssl, the eventing capability at this point must be disabled in OpenWSMAN. This capability will be important to the sblim-* systems management software stack which implements DMTF open standards. I need to investigate further what the source of the problem here is.
Arguably, one should discover the missing functionalty from nss, and re-implement it so as to enable these functions. However, as these functions do work if linked against openssl, I would prefer to see the expedient approach of linking libcurl against openssl again, and only release with it linked against nss once it is at feature parity for the functions used by software within Fedora.
Can I ask that libcurl be rebuilt against openssl instead of nss for the time being?
You can, but it is obvious that a backward switch is very unlikely.
Addon of some extra functionality to NSS seems questionable as well. Perhaps, in far future only. Unlike the OpenSSL and Gnutls, NSS seems more stable, more tested, more certificated -- ie. more conservative. Hence the support of some "corner" cases is not a primary goal.
Not in NSS itself, but there is this project as well - http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ - to assist in porting applications that use OpenSSL to use NSS. There are plans to provide support for MD4 as well. I don't think MD4 will be added to NSS, but perhaps to the ossl wrapper layer or to some other add-on layer.
BTW, in some areas OpenSLL looks more perspective. For example, Russia have chosen other way for crypto in the state life -- so called GOST instead of RSA. OpenSSL will start to support it since 0.9.9, plans of NSS is unknown... As a result, the compulsion for NSS in Fedora can make its usage impossible in the state organisations of some countries.
Now that NSS has been adopted by the LSB - http://ldn.linuxfoundation.org/article/lsb-40-the-cryptography-strategy - there will likely be a lot more impetus to support other crypto. I think other countries have different crypto requirements outside of the usual SSLv3/TLSv1 algorithms and cipher suites, and I expect these will be supported by the NSS framework, if not directly supported by NSS.
Another issue is license compatibility. Whilst OpenSSL is "widely used", it can be considered as a "basic system application", hence programs may link with it anyway (due to some exception in GPL etc...). After the most of things will be switched to NSS, the OpenSSl itself will become "an optional" instead of "system basic". The correspond exception in GPL will not affect anymore, and the rest of GPL applications who still will use OpenSSL will become illegal.
Just my thoughts...
~buc
On Thu, 2008-10-09 at 15:45 +0400, Dmitry Butskoy wrote:
Addon of some extra functionality to NSS seems questionable as well. Perhaps, in far future only. Unlike the OpenSSL and Gnutls, NSS seems more stable, more tested, more certificated -- ie. more conservative. Hence the support of some "corner" cases is not a primary goal.
Usually these "corner cases" are just bad security practice, it is better if NSS keep you straight and does not let you mess with security related stuff.
BTW, in some areas OpenSLL looks more perspective. For example, Russia have chosen other way for crypto in the state life -- so called GOST instead of RSA. OpenSSL will start to support it since 0.9.9, plans of NSS is unknown... As a result, the compulsion for NSS in Fedora can make its usage impossible in the state organisations of some countries.
Send inquiries to the NSS team about support of GOST in NSS then.
Another issue is license compatibility. Whilst OpenSSL is "widely used", it can be considered as a "basic system application", hence programs may link with it anyway (due to some exception in GPL etc...). After the most of things will be switched to NSS, the OpenSSl itself will become "an optional" instead of "system basic". The correspond exception in GPL will not affect anymore, and the rest of GPL applications who still will use OpenSSL will become illegal.
Sorry but this is just legal mumbo-jumbo ...
Simo.
On Wednesday 08 October 2008 18:34:40 Matt_Domsch@dell.com wrote:
First, libcurl being built against nss. Nss does not provide some functions which are necessary for NTLM authentication to succeed. has defeatured the 'curl' application, rendering it useless in environments where users are behind an NTLM-authenticating proxy. This bites me personally every day. Yes, NTLM is based on MD4 which is insecure. Nevertheless, choice of corporate proxy servers is often beyond the reach of even the most senior Linux developers (aside from changing jobs...)
This appears to be bug: https://bugzilla.redhat.com/show_bug.cgi?id=258481 or https://bugzilla.redhat.com/show_bug.cgi?id=263241
I think that more effort needs to be put on these.
Second, libcurl being built against nss. OpenWSMAN has an eventing capability, but this uses libcurl, which in turn would use a feature of openssl.
Which feature?
But as libcurl is not built against openssl, the eventing capability at this point must be disabled in OpenWSMAN. This capability will be important to the sblim-* systems management software stack which implements DMTF open standards. I need to investigate further what the source of the problem here is.
Yes, and please file a bug.
Arguably, one should discover the missing functionalty from nss, and re-implement it so as to enable these functions. However, as these functions do work if linked against openssl, I would prefer to see the expedient approach of linking libcurl against openssl again, and only release with it linked against nss once it is at feature parity for the functions used by software within Fedora.
If we didn't do this, you wouldn't have reported a problem and we wouldn't know something needs fixing. NSS has been accepted by LSB, so we need to press forward and make fixes. One could also say that openssl is not on feature parity with NSS, too.
Can I ask that libcurl be rebuilt against openssl instead of nss for the time being?
I think we should identify what's broken and try to fix it.
Thanks, -Steve
On Wed, 2008-10-08 at 17:34 -0500, Matt_Domsch@Dell.com wrote:
I understand the push behind getting as many packages to build against nss as possible. However, nss is not on feature parity with openssl at this time.
Using SSL certificates from a TPM is fairly trivial in OpenSSL too. Just install the openssl-tpm-engine package and it's a few lines of code to initialise that engine in your application (and curl has callbacks which let you do it at the appropriate time).
For NSS, there's theoretically a PKCS#12 plugin which can use the TPM, but it relies on a whole stack of other weird stuff we don't ship, including more system dæmons, and which I haven't been able to get working.
Then there's the DTLS protocol, which neither NSS or GNUTLS support at all...
I actually ditched libcurl and wrote my own http code, cursing all the time as I did it, because of the switch to NSS.
-
David Woodhouse -
Dmitry Butskoy -
Matt Domsch -
Rich Megginson -
Simo Sorce -
Steve Grubb