Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
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 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 Cryptography (1.3.6.1.4.1.311.10.3.3) are expressly covered by these requirements. Jeremy -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Thursday, August 08, 2013 9:20 AM To: jeremy.row...@digicert.com Cc: 'CABFPub' Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements On 02/08/13 12:19, Jeremy Rowley wrote: There is a potential conflict that I think needs more data and discussion: We agree; hence Mozilla votes NO on the ballot in its current form. We would like to see it withdrawn until further information can be gathered. We very much support the goal of this ballot; we want the BRs to cover all certs capable of being used by SSL servers. But we need to figure out whether this requires a change in the definition of what the BRs cover, or a change (e.g. on clients) in the definition of capable of being used by SSL servers. Or something else. Gerv ___ Public mailing list pub...@cabforum.org https://cabforum.org/mailman/listinfo/public -- dev-tech-crypto mailing list
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
Hi Brian, On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html Suggestions for improvements are encouraged. Thanks for this. Here are my questions: * 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? * We should avoid leaking the distinction between mobile and desktop products in the TLS handshake, which means that the handshake should look the same on mobile and desktop. Why is this a goal? There are many, many other ways of determining this distinction, some supported by Mozilla (e.g. the UserAgent string). This is not to deny that there are other reasons for having a consistent set, but this seems an odd one. The same question applies to your point about avoiding TLS fingerprinting. I think it should be a goal to make it hard to distinguish between specific instances of Firefox, but it seems to be not a goal to avoid people distinguishing between Firefox and IE, or Firefox for desktop and Firefox for Android. * this proposal does not recommend supporting the CBC-HMAC-SHA-2-based ciphersuites that those browsers recently added Can you spell out why? Is it because they don't offer forward secrecy? * In the course of testing TLS 1.2 and the ALPN TLS extension, the Chromium team recently found that some servers choke when the ClientHello message in the TLS handshake is larger than 256 bytes. How many bytes are taken up per ciphersuite? How many can we probably fit in, if we say we need to include all the other stuff? * Re: Camellia and SEED: we should talk to the organisations which pushed for their addition, and our business development people in the region, before eliminating them. (This is not to say that we will definitely not remove them if they raise objections.) * Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of security given how they are used in TLS. However, if we never use them, then have to switch to them because a problem arises with HMAC-SHA-1, how will they have received any testing? More generally, is there a place for including ciphersuites 'of the future', perhaps at lower priority, to try and make sure there aren't problems or interop issues with them? * Your final section says what cipersuites should be added and dropped. Is this simply a config change with testing, or does it require code to be written in one or more of the TLS stacks? Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
moznss with openldap - error -8018:Unknown PKCS #11 error
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? Best regards, Augustin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: downloading NSS
On Wed, 2013-08-07 at 17:12 +, James Burton wrote: Hi, I would like to know were i could download Netscape Security Library which Mozilla NSS was build on. This page attempts to collect a small selection of links to get you started: http://nss-crypto.org/ However, the official project page is at: https://developer.mozilla.org/en-US/docs/NSS This page describes how to get the source code and how to use it: https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing Regards Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
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. * We should avoid leaking the distinction between mobile and desktop products in the TLS handshake, which means that the handshake should look the same on mobile and desktop. Why is this a goal? There are many, many other ways of determining this distinction, some supported by Mozilla (e.g. the UserAgent string). There is a difference between leaking to somebody on the network and leaking to the server you are connecting to. Remember that TLS hides the User-Agent string and other HTTP-level information is hidden from others on the network. So, if Firefox for Android and Firefox for Desktop use the exact same TLS handshaking logic/parameters, then it should be possible to make them indistinguishable from each other. The same question applies to your point about avoiding TLS fingerprinting. I think it should be a goal to make it hard to distinguish between specific instances of Firefox, but it seems to be not a goal to avoid people distinguishing between Firefox and IE, or Firefox for desktop and Firefox for Android. If every browser's TLS handshake were to look the same, then observers on the network wouldn't be able to tell browsers apart, though the website you are connecting to obviously would. I admit that is a state that is likely to be difficult to obtain. * this proposal does not recommend supporting the CBC-HMAC-SHA-2-based ciphersuites that those browsers recently added Can you spell out why? Is it because they don't offer forward secrecy? It is explained below. Worse performance, no security benefit, and they take up space in the handshake. * In the course of testing TLS 1.2 and the ALPN TLS extension, the Chromium team recently found that some servers choke when the ClientHello message in the TLS handshake is larger than 256 bytes. How many bytes are taken up per ciphersuite? How many can we probably fit in, if we say we need to include all the other stuff? They take two bytes per ciphersuite. If the 256-byte limitation cannot be worked around, then we basically can't afford to waste *any* bytes in the TLS handshake. It is already likely going to be very difficult for us to support the ALPN extension as it is, even after making these reductions. * Re: Camellia and SEED: we should talk to the organisations which pushed for their addition, and our business development people in the region, before eliminating them. (This is not to say that we will definitely not remove them if they raise objections.) Do you have suggestions for who to contact? * Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of security given how they are used in TLS. However, if we never use them, then have to switch to them because a problem arises with HMAC-SHA-1, how will they have received any testing? More generally, is there a place for including ciphersuites 'of the future', perhaps at lower priority, to try and make sure there aren't problems or interop issues with them? We will soon have AES-GCM and we'll hopefully soon have Salsa20/12+(Poly1305|UMAC|VMAC) to mitigate that. Relying on either/both of those alternatives kills more birds with fewer stones. I think ultimately we'd rather have all HMAC-based ciphersuites also marked deprecated, for performance and security reasons. * Your final section says what cipersuites should be added and dropped. Is this simply a config change with testing, or does it require code to be written in one or more of the TLS stacks? Dropping ciphersuites is a simple configuration change. In the top table, the notes column lists the ciphersuites that will require code changes to NSS and to SChannel. Bug 880543https://bugzilla.mozilla.org/show_bug.cgi?id=880543tracks the addition of AES-GCM ciphersuites to NSS's libssl. OpenSSL already implements them. I think Google may be working on Sals20/12+Poly1305 ciphersuites and there has been some small progress on adding Sals20/12 ciphersuites in the IETF TLS working group. Reordering ciphersuites in SChannel can be done with a configuration change to the app. Reordering ciphersuites in NSS either requires us to reorder
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
Thoughts, as a random passerby: Of course I quite like the prioritization of (EC)DHE. I think standardizing on a ciphersuite preference order with the aims of reducing fingerprinting is a worthwhile (although wildly difficult) goal for SSL _libraries_, but less so for browsers - to the point of probably not being a fight worth fighting. A web browser is so incredibly complex it is next to impossible to browse with _soley_ over TLS, and the first HTTP request leaks the User Agent. Even with soley-over-TLS, requests for malware protection, the dynamic favorites RSS feeds Firefox bundles (which I quite hate), and the auto-update checks will leak the browser anyway. Trying to avoid leaking the preference to the network is admirable, and worthwhile in a library I think, but the browser is a mighty beast to tackle. There are lower hanging fruit than the TLS handshake right now. Weak DHE keys are a lurking problem. Someone needs to survey the internet. (Unless there's a paper I'm not aware of...) The Ephemeral ECDH certs is clever... but I feel like that's an awful amount of engineering for the relatively few organizations who their own Intermediate cert. Unless this is a strategic push to encourage Name Constraints. In which case: Hmm. Future work: A comprehensive profile for browsers' use of TLS. - In theory, this would be the domain of the relatively-new IETF PKI Operations Working Group, which is being driven by a few browser folks and many CA folks. I would suggest another item for Future Work and that is trying to work in protections against TLS downgrades. This has been batted around a few times in the past [0][1] but has never gained much traction or agreement. -tom [0] https://www.ietf.org/mail-archive/web/tls/current/msg08861.html [1] I'm failing to find a link, but Yoav had a trick he added to Opera to prevent downgrade if the server supported secure renegotiation. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
