Custom TLS Extensions in NSS (Patch in Progress)
Hi all, With the guidance of Trevor Perrin (cc-ed), I have put together the beginnings of a patch to allow clients of the NSS library to implement support for arbitrary TLS extensions. The motivation is to allow clients of NSS to implement new proposals that bolster the CA trust model, such as TACK[1] and Certificate Transparency[2]. However, the goal is to make a broadly-useful patch allowing for a wide array of TLS extensions. I have the beginnings of the patch on GitHub[3]. It is not done, but the major functionality is more-or-less all there. There are still some needed changes that I know aren't implemented, a number of test failures I need to hunt down, and a number of style problems. But I'm getting close, and for some of what I still need to do (especially defining some parts of the public interface), feedback would be very useful. So I'd love to hear any feedback and guidance, as well as any concerns that might prevent this from eventually getting committed. I'm happy to take feedback anywhere; GitHub may be the best place for line-level code comments since it has a nice interface for that, but I'd guess the list is a better for high-level discussion. I'm also happy to open an issue on bugzilla, but I thought it might be better to wait until the patch is functional. Thank you, Daniel [1] http://tack.io/ [2] http://www.certificate-transparency.org/ [3] https://github.com/jackowayed/mozilla-nss/pull/1 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: moznss with openldap - error -8018:Unknown PKCS #11 error
On 08/07/2013 10:38 PM, Augustin Wolf wrote: Hi List, I have a Centos 6.4, fresh install, and I'm trying to configure OpenLDAP with moznss. For now, self signed certificate is sufficient for my needs. But when I try to search using secure connection (-Z option), I got error: ldap_start_tls: Connect error (-11) additional info: TLS error -5938:Encountered end of file In openLdap logs: connection_read(14): checking for input on id=1000 TLS: certdb config: configDir='/etc/openldap/certs/' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/certs/', error -8018:Unknown PKCS #11 error. TLS: skipping 'cert8.db' - filename does not have expected format (certificate hash with numeric suffix) TLS: skipping 'key3.db' - filename does not have expected format (certificate hash with numeric suffix) TLS: skipping 'secmod.db' - filename does not have expected format (certificate hash with numeric suffix) TLS: error: the certificate 'LDAPServer' could not be found in the database - error -8187:security library: invalid arguments.. TLS: could not read certificate file LDAPServer - error -5950:File not found. TLS: error: could not initialize moznss security context - error -5950:File not found TLS: can't create ssl handle. connection_read(14): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=14 I cannot resign from using moznss, as it is in default with openldap package in CentOS 6.4. I created TLS certificates like this: [root@ldap ~]# openssl req -new -x509 -extensions v3_ca -keyout /etc/pki/CA/private/CAss.key -out /etc/pki/CA/certs/CAss.pem -days 200 #got rid of certificate password: [root@ldap ~]# openssl rsa -in /etc/pki/CA/private/CAss.key -out /etc/pki/CA/private/CAssNOpass.key #created pkcs12 key+cert [root@ldap ~]# openssl pkcs12 -export -inkey /etc/pki/CA/private/CAssNOpass.key -in /etc/pki/CA/certs/CAss.pem -out /etc/pki/ldap.example.com.p12 -nodes -name 'LDAPServer' #import p12 certificate to openldap keybase: [root@ldap ~]# pk12util -i /etc/pki/ldap.example.com.p12 -d /etc/openldap/certs #import CA, as CA to certificate keybase: [root@ldap ~]# certutil -A -d /etc/openldap/certs -n LDAPServer -t CT,, -i /etc/pki/CA/certs/CAss.pem # verify: [root@ldap ~]# certutil -d /etc/openldap/certs -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI LDAPServer CTu,u,u # keybase has ldap permission, and ldap is able to read from it: [root@ldap ~]# chown root:ldap /etc/openldap/certs/* [root@ldap ~]# chmod 0640 /etc/openldap/certs/* #openldap uses this keystore: [root@ldap ~]# cat /etc/openldap/slapd.conf |grep -i tls TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificatePath /etc/openldap/certs TLSCertificateFile LDAPServer TLSVerifyClient allow What I did wrong? In general, self-signed certificates are a bad idea, but the real problem is probably related to your databases. The error message says you are trying to open the databases, but failing. It looks like your permissions are right, but I'm a little confused by your reverence to moz-nss. Do you mean nss in general? is certutil and openldap using the same version of nss? bob Best regards, Augustin 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: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
On 08/09/2013 02:57 AM, Gervase Markham wrote: Can an NSS hacker please tell me, in the fashion of the attempt by the IE representative below, what types of certificate NSS accepts for making SSL connections? What features must the cert or chain have or not have? Or, if this is a PSM question, tell me that :-) Gerv I think you already have the answer, but here's the basic: The code to determine the type a cert is in in certdb.c called cert_ComputeCertType(). It's rather complex to allow historical issued certificates to function: If the cert has neither an extended key usage or a netscape cert extension, then the cert is considered legacy and OK for use for everything except code signing (Email/SSL client/SSL Server). If the cert as either an extended key usage or a netscape cert extension, then the cert must have the SSL_Server type set. Exception, if it has the extended key usage and the Govt_approved, it is assumed to also have SSL_Server. The code has some comment that COMMODO needs this behavior until 2020. If the cert has both an extended key usage and a netscape cert extension, only one of these need to indicate that it's an SSL_Server cert. Also, the cert can't be a CA cert (SSL Server+CA maps to a CA that can issue SSL_Server certs, not an SSL_Server cert). We do not parse 'AnyEKU' (though it's reasonable for us to do so). bob Original Message Subject: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements Date: Thu, 8 Aug 2013 17:10:36 + From: Kelvin Yiu kelv...@exchange.microsoft.com To: jeremy.row...@digicert.com jeremy.row...@digicert.com, 'Gervase Markham' g...@mozilla.org CC: 'CABFPub' pub...@cabforum.org One way to make progress is perhaps for browsers to summarize the certificate profile (e.g. required fields and extensions) that their browsers accept as SSL, code signing, or any other public certificates they accept. For example, I believe IE expects SSL certificates require at least the following: (I will need to do some research to confirm) 1. Either no EKU extension, anyEKU, or the server auth EKU in all certificates in the chain. IE may still accept the old SGC olds as well 2. Valid DNS name in either the CN field in the subject name, or one or more dNSNames or IPv4 address in the SubjectAltName extension 3. Root CA must be enabled for server auth For code signing certificates: 1. Either no EKU extension, anyEKU, or the code signing auth EKU in all certificates in the chain. 2. Root CA must be enabled for code signing 3. Subject name must have either CN, or O, (and maybe OU) field. Hence, OV SSL certificates that do not have an EKU extension (or include the anyEKU OID) are valid for both SSL and code signing. Arguably it is probably not the intention of the CA to issue SSL certificates that can be also used for code signing. At a high level from the MS perspective, I want all CAs that issue certificates that would be interpreted as SSL, code signing, or whatever other usages allowed by the root program) to be in scope of the discussion. The high level principle here is to prevent or at least minimize unintended certificate usages that opens up security vulnerabilities. So if while PIV certificates may include the anyEKU but do not contain any valid DNS name, browsers may reject it for SSL so they can be considered out of scope. I agree the much harder problem to resolve is whether to include CAs with no EKUs that are capable of issuing SSL certificates, but I don't have a good answer yet. Kelvin -Original Message- From: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, August 8, 2013 9:04 AM To: 'Gervase Markham' Cc: 'CABFPub' Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements Yes - I am officially withdrawing the ballot pending further consideration. I'm not sure how to overcome these obstacles since: 1) PIV-I in the US space requires the anyEKU 2) Qualified Certs may require no EKU 3) Certificates without an EKU or the anyEKU may be used as SSL certificates 4) All SSL certificates should be covered by the BRs 5) Qualified and PIV-I Certs cannot be covered by the BRs since they lack a FQDN 6) SSL Certificates without an FQDN are considered local host and explicitly covered by the BRs I think the best option might be to simply acknowledge the inconsistency and change the definition as follows: All root certificates included in a browser's trust store, all subordinate CA certificates signed by one of these root certificates, and all end-entity certificates that either lack any Extended Key Usage extension or contain an Extended Key Usage extension that contain (i) either an Internal Server Name or a FQDN and (ii) one of the following: - Server Authentication (1.3.6.1.5.5.7.3.1) - anyExtendedKeyUsage (2.5.29.37.0) - Netscape Server Gated Cryptography (2.16.840.1.113730.4.1) - Microsoft Server Gated
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 08/09/2013 10:12 AM, Brian Smith wrote: On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham g...@mozilla.org wrote: * Can you provide some background or references on exactly how ciphersuite construction and choice works? Can I invent e.g. TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of elements? Can any combination be encoded in the ClientHello? Does the server support specific sets, or will it support my combination if it supports all the component pieces? No, each combination is hard-coded into its own distinct code point that is registered with IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4. This is a design choice based on the fact that many crypto modules don't let you mix/match algorithms at will, and because you often can't/shouldn't move keys between crypto modules. Minor tweak. The design point has nothing to do with crypto modules. It had to do with analyzing combinations of algorithms. In 1994/5 when SSL-3 was being designed there were 2 camps: 1) select Asymmetric/Symmetric/Macing algorithms separately and 2) cipher suites. The security argument fell to cipher suites under the theory that it simplified your analysis of whether the algorithm is secure or not. At the time no one was thinking of doing operations in tokens, even at this point in time, I know of no crypto modules that actually implement cipher suites as a suite. That info is really only of historical interest and doesn't affect the rest of Brian's argument (particularly since he's correct in the only part of the paragraph Gerv cares about --- that SSL uses suites, not arbitrarily mixed combinations of algorithms). 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: Custom TLS Extensions in NSS (Patch in Progress)
On 08/14/2013 10:45 AM, Daniel Jackoway wrote: Hi all, With the guidance of Trevor Perrin (cc-ed), I have put together the beginnings of a patch to allow clients of the NSS library to implement support for arbitrary TLS extensions. The motivation is to allow clients of NSS to implement new proposals that bolster the CA trust model, such as TACK[1] and Certificate Transparency[2]. However, the goal is to make a broadly-useful patch allowing for a wide array of TLS extensions. I have the beginnings of the patch on GitHub[3]. It is not done, but the major functionality is more-or-less all there. There are still some needed changes that I know aren't implemented, a number of test failures I need to hunt down, and a number of style problems. But I'm getting close, and for some of what I still need to do (especially defining some parts of the public interface), feedback would be very useful. So I'd love to hear any feedback and guidance, as well as any concerns that might prevent this from eventually getting committed. I'm happy to take feedback anywhere; GitHub may be the best place for line-level code comments since it has a nice interface for that, but I'd guess the list is a better for high-level discussion. I'm also happy to open an issue on bugzilla, but I thought it might be better to wait until the patch is functional. Thank you, Daniel First I was excited because I thought it was something I wanted to get into NSS for a while (dynamically adding cipher suites... though that probably causes problems for Brian's attempt to standardize on cipher suites). That being said, Adding dynamically added extensions sounds like a reasonable addition. The main question that comes to mind is: Are you adding the extensions programmatically (that is an application can add extensions by making various calls to do so) or are you adding extensions dynamically through some sort of configuration. Both are useful, though the latter may be more interesting. Also, NSS lives in the mozilla Hg repository, The NSS team usually share uncommitted patches through bugzilla as straight patch files. This let's the team members use the tools they prefer to review them.. bob [1] http://tack.io/ [2] http://www.certificate-transparency.org/ [3] https://github.com/jackowayed/mozilla-nss/pull/1 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: Custom TLS Extensions in NSS (Patch in Progress)
On Aug 14, 2013, at 5:39 PM, Robert Relyea rrel...@redhat.com wrote: Are you adding the extensions programmatically (that is an application can add extensions by making various calls to do so) or are you adding extensions dynamically through some sort of configuration. Both are useful, though the latter may be more interesting. The way I've implemented it, an application makes a function call to NSS and passes in callbacks to define the implementation of the extension. But I'm open to other ideas. Also, NSS lives in the mozilla Hg repository, The NSS team usually share uncommitted patches through bugzilla as straight patch files. This let's the team members use the tools they prefer to review them.. Ok, I'll get a patch on bugzilla soon. I've realized that I ended up basing everything on somewhat stale code (the most-visible docs on developer.mozilla.org suggested that CVS was still the way to get the code; I edited things to fix that), so I'm in the midst of moving everything over. Once I have it all based on tip, I'll put up a patch and post a link here. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
