Re: libnss consolidation (was: Re: X.509 and CA certificates for other purposes (i.e. the IGTF))
Le 10 juin 2013 07:06, "Florian Weimer" a écrit : > > * Bastien ROUCARIES: > > > Maybe crypto consolidation arround libnss will greatly help here. > > jessie release goal ? > > NSS has lots of global state, and its proper initialization from > another library is difficult. Could you give some pointer? Switching over to it is probably > doable, but it's not really straightforward. On the other hand, the > TLS implementation in NSS has been doing host name validation for a > long time, which is still problematic with some of the other > implementations. > > NSS has its own problems with SUID/SGID binaries, but these could be > addressed by switching PR_GetEnv to secure_getenv. Could you also give some pointer? I will open a wiki page > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/87vc5mtuzr.fsf...@mid.deneb.enyo.de >
libnss consolidation (was: Re: X.509 and CA certificates for other purposes (i.e. the IGTF))
* Bastien ROUCARIES: > Maybe crypto consolidation arround libnss will greatly help here. > jessie release goal ? NSS has lots of global state, and its proper initialization from another library is difficult. Switching over to it is probably doable, but it's not really straightforward. On the other hand, the TLS implementation in NSS has been doing host name validation for a long time, which is still problematic with some of the other implementations. NSS has its own problems with SUID/SGID binaries, but these could be addressed by switching PR_GetEnv to secure_getenv. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc5mtuzr.fsf...@mid.deneb.enyo.de
Re: libnss consolidation
Brian May writes: > On 31 May 2013 20:19, Bastien ROUCARIES wrote: > >> Gnutls is really crappy about suid >> see http://lists.debian.org/debian-devel/2010/03/msg00298.html > > > 2+ years later or 2 Debian releases later, I would have hoped these issues > would be, somehow, magically, fixed by now :-( > > Basically makes libpam-ldap + TLS broken with certain programs. > > libnss-ldap is probably also broken, but seems you should be using > libnss-ldapd these days which may (?) avoid these problems. Yes, libpam-ldapd does avoid this problem. The ldap connections are managed by a separate daemon (nslcd) that runs as a limited user account and isn't suid. The pam (and nss) modules then contact this daemon via a socket to run ldap queries. In addition to avoiding the gnutls bugs this brings better latency and connection pooling (with libnss-ldap one needs an ldap connection per nss using process, these pile up quite fast indeed). -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5aup1q0@iki.fi
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On Fri, May 31, 2013 at 12:19:27PM +0200, Bastien ROUCARIES wrote: > On Fri, May 31, 2013 at 4:42 AM, brian m. carlson > wrote: > > NSS does not support TLS 1.2. Since RC4 is not used securely in TLS, > > and the only other choice in TLS 1.1 and earlier is block ciphers with > > CBC, this means that there are no secure choices. I know the lack of > > TLS 1.2 support has caused customers of $DAYJOB endless heartache with > > regard to PCI compliance. > > Not true anymore: > https://hg.mozilla.org/projects/nss/rev/5a9fa031aca5 Upstream bug 480514 is still open, and while it may have landed in the main HEAD, it is not in any released version, and not in Debian. It would be irresponsible to transition to NSS when that would mean a regression in security for users. > > NSS supports fewer algorithms than either OpenSSL or GnuTLS. > > Please fill bug: > > Gnutls is really crappy about suid > see http://lists.debian.org/debian-devel/2010/03/msg00298.html > See also > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543941 > > And openssl has problem about license I'm not saying these problems don't exist, but they have no bearing on the fact that OpenSSL and GnuTLS support far more algorithms. Also, it's hard to tell what algorithms and protocols are supported (and how to use NSS at all), since Debian does not include documentation and much of the d.m.o documentation is seriously out of date. We can't expect everyone to switch to NSS without accurate, maintained, and distributed documentation. NSS is also slow to accept patches and new features upstream. It took quite a long time to get TLS 1.1 and TLS 1.2 in, even when not having them in had negative security implications. Finally, does NSS support OpenSSL-style algorithm specifications to select the protocols and algorithms used? Lots of programs expect to be able to pass this information to the library, and parts of e.g. the Postfix configuration would fail to work without it. This functionality is required for PCI compliance, which I'm sure is something lots of Debian's users want. I'm all for crypto consolidation, but only if doing so doesn't cause regressions in security or functionality. Right now, that doesn't seem to be the case. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On 31 May 2013 20:19, Bastien ROUCARIES wrote: > Gnutls is really crappy about suid > see http://lists.debian.org/debian-devel/2010/03/msg00298.html 2+ years later or 2 Debian releases later, I would have hoped these issues would be, somehow, magically, fixed by now :-( Basically makes libpam-ldap + TLS broken with certain programs. libnss-ldap is probably also broken, but seems you should be using libnss-ldapd these days which may (?) avoid these problems. (I stopped using LDAP for authentication as a direct result of these problems - hardly a good selling point for Debian; so if something has changed I may not have noticed) -- Brian May
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On Fri, May 31, 2013 at 4:42 AM, brian m. carlson wrote: > On Thu, May 30, 2013 at 04:04:47PM +0200, Bastien ROUCARIES wrote: >> > Cons: >> > >> > - not all crypto libraries are equivalent; choosing one will exclude >> > some functionality provided by others >> >> SEE compat layer >> > - we somehow have to deal with legacy systems that can't convert >> > - adoption of new software that uses something else is harder > > NSS does not support TLS 1.2. Since RC4 is not used securely in TLS, > and the only other choice in TLS 1.1 and earlier is block ciphers with > CBC, this means that there are no secure choices. I know the lack of > TLS 1.2 support has caused customers of $DAYJOB endless heartache with > regard to PCI compliance. Not true anymore: https://hg.mozilla.org/projects/nss/rev/5a9fa031aca5 Please open a debian bug > > NSS supports fewer algorithms than either OpenSSL or GnuTLS. Please fill bug: Gnutls is really crappy about suid see http://lists.debian.org/debian-devel/2010/03/msg00298.html See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543941 And openssl has problem about license > -- > brian m. carlson / brian with sandals: Houston, Texas, US > +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only > OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spazib3iezzla-sd3r0ft7ff6pdxkvkrzgxdsn1d7foz...@mail.gmail.com
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On Thu, May 30, 2013 at 04:04:47PM +0200, Bastien ROUCARIES wrote: > > Cons: > > > > - not all crypto libraries are equivalent; choosing one will exclude > > some functionality provided by others > > SEE compat layer > > - we somehow have to deal with legacy systems that can't convert > > - adoption of new software that uses something else is harder NSS does not support TLS 1.2. Since RC4 is not used securely in TLS, and the only other choice in TLS 1.1 and earlier is block ciphers with CBC, this means that there are no secure choices. I know the lack of TLS 1.2 support has caused customers of $DAYJOB endless heartache with regard to PCI compliance. NSS supports fewer algorithms than either OpenSSL or GnuTLS. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
Le 30 mai 2013 14:08, "Dennis van Dok" a écrit : > > On 30-05-13 13:16, Bastien ROUCARIES wrote: > > > Using only one lib for crypto (libnss) will allow to use only one > > trust certificate format > > 'Allow only one' doesn't immediately strike me as beneficial, but I see > what you mean. The discussion is similar to others (such as about which > init system to support) where the question is 'why do we have X > implementations of Y?' where X > 1. > > There are pros and cons to such a bold plan as you propose. I can think > of a few, and I'm sure others can think of many more. But more > importantly, it takes effort to work out the plan, inventory the pros > and cons, calculate the required efford and herd it along. Most work on > Debian is on a voluntary basis, the available effort depends on what > people will want to invest (even just to read this e-mail!). I'm not > volunteering. > > But to seed the discussion (maybe): > > Pros: having only one crypto system will simplify the handling of > certificates. Simplify security audit and get faits certification Avoid lice se issue with openssl ans GPL Avoid problem with gnutls ans suid > > Cons: > > - not all crypto libraries are equivalent; choosing one will exclude > some functionality provided by others SEE compat layer > - we somehow have to deal with legacy systems that can't convert > - adoption of new software that uses something else is harder > > Cheers, > > Dennis van Dok > -- > D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: > Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On 30-05-13 13:16, Bastien ROUCARIES wrote: > Using only one lib for crypto (libnss) will allow to use only one > trust certificate format 'Allow only one' doesn't immediately strike me as beneficial, but I see what you mean. The discussion is similar to others (such as about which init system to support) where the question is 'why do we have X implementations of Y?' where X > 1. There are pros and cons to such a bold plan as you propose. I can think of a few, and I'm sure others can think of many more. But more importantly, it takes effort to work out the plan, inventory the pros and cons, calculate the required efford and herd it along. Most work on Debian is on a voluntary basis, the available effort depends on what people will want to invest (even just to read this e-mail!). I'm not volunteering. But to seed the discussion (maybe): Pros: having only one crypto system will simplify the handling of certificates. Cons: - not all crypto libraries are equivalent; choosing one will exclude some functionality provided by others - we somehow have to deal with legacy systems that can't convert - adoption of new software that uses something else is harder Cheers, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a74103.5040...@nikhef.nl
