Re: More SHA-1 certs
On 11/03/2016 07:40, Charles Reiss wrote: On 03/03/16 19:48, Ryan Sleevi wrote: On Thursday, March 3, 2016 at 9:20:07 AM UTC-8, Andrew Ayer wrote: It's also troubling that a CA may be allowed to continue issuing non-serverAuth certs with SHA-1 from an issuer that is also used for serverAuth certs. Again, a collision attack could be used to forge a trusted serverAuth cert. I urge that this hole be fixed in both Mozilla policy and the BRs, not just by clarifying the cert/pre-cert equivalence, but also by forbidding an issuer that is trusted for serverAuth from signing _anything_ with SHA-1. A resounding +1 to this. This goes back to the core goal - if a certificate has id-kp-serverAuth / is in scope for the BRs, the only way to make a reasonable argument about the cryptographic operations is if _everything_ issued by that CA is seen in scope. This is not just a matter for SHA-1; consider an intermediate with id-kp-serverAuth and id-kp-emailProtection. If, in the issuance of S/MIME certificates, the CA leaves off the EKU from the leaf, and issues a commonName of "example.com", then that certificate - though intended for email - can now be used for TLS authentication. This is wholly independent of SHA-1 deprecation. And I'd guess that (based on lack of EKU and existence of rfc822Name SAN) this SHA-1 certificate is an example of precisely that problem: https://crt.sh/?id=15019496 (used in the wild for a TLS server as of this writing: https://censys.io/ipv4/194.145.239.217) That seems a particularly clumsily generated certificate: - DNS name (for https?) in CN, but not repeated as a SAN (as per PKIX). - SAN present but does not include the server name from the CN, this might make some PKIX-based clients fail to match the name to the certificate. - SHA-1 certificate with apparently intended https usage issued after 2016-01-01. - e-mailaddress in DN placed before CN (tradition is after, so the matchable CN for older browsers is the first element of the DN). - No EKU extension and no Netscape usage extension. For this reason, I'm a strong supporter in mandating that the scope of Mozilla's policies - and, more importantly, the expectation of BR compliance - extends to include _all_ certificates issued from an intermediates capable of causing TLS certificate issuance, even if those leaves are not intended for TLS. Indeed, if an intermediary is not technically constrained, it should be subject to the BRs. But if it is technically constrained to the maximum extent possible and audited for anything that could not be constrained away, it should remain exempt, such that CAs can continue to support platforms that are stuck in the past for purposes that don't interfere with modern clients. Code signing for various Microsoft platforms is a key example of such a situation. The Microsoft platforms that are still restricted to SHA-1 signatures are also restricted to old CA lists, so setting up new roots for supporting those is not viable, and not every CA has an old root they can "throw away", like Symantec did with some of the branded roots they had accumulated. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: More SHA-1 certs
On 03/03/16 19:48, Ryan Sleevi wrote: > On Thursday, March 3, 2016 at 9:20:07 AM UTC-8, Andrew Ayer wrote: >> It's also troubling that a CA may be allowed to continue issuing >> non-serverAuth certs with SHA-1 from an issuer that is also used >> for serverAuth certs. Again, a collision attack could be used to >> forge a trusted serverAuth cert. >> >> I urge that this hole be fixed in both Mozilla policy and the BRs, >> not just by clarifying the cert/pre-cert equivalence, but also by >> forbidding an issuer that is trusted for serverAuth from signing >> _anything_ with SHA-1. > > A resounding +1 to this. This goes back to the core goal - if a > certificate has id-kp-serverAuth / is in scope for the BRs, the only > way to make a reasonable argument about the cryptographic operations > is if _everything_ issued by that CA is seen in scope. > > This is not just a matter for SHA-1; consider an intermediate with > id-kp-serverAuth and id-kp-emailProtection. If, in the issuance of > S/MIME certificates, the CA leaves off the EKU from the leaf, and > issues a commonName of "example.com", then that certificate - though > intended for email - can now be used for TLS authentication. This is > wholly independent of SHA-1 deprecation. And I'd guess that (based on lack of EKU and existence of rfc822Name SAN) this SHA-1 certificate is an example of precisely that problem: https://crt.sh/?id=15019496 (used in the wild for a TLS server as of this writing: https://censys.io/ipv4/194.145.239.217) > > For this reason, I'm a strong supporter in mandating that the scope > of Mozilla's policies - and, more importantly, the expectation of BR > compliance - extends to include _all_ certificates issued from an > intermediates capable of causing TLS certificate issuance, even if > those leaves are not intended for TLS. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Drafting Q1 2016 CA Communication
Hi Kathleen, Would this be a good opportunity to ask CAs to do an audit of any undisclosed cross-signatures they may have to other unconstrained roots? For example, there were two recently discovered cross-signatures to the Federal Bridge by commercial CAs, Identrust and Symantec. Once it was identified that Identrust had not disclosed this cross-signature, Identrust revoked it: https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c26 While services like censys.io and crt.sh are doing wonders for finding things like this, it would also be beneficial to have CAs use their own vantage point over their cross-signatures to identify other possible gaps between what Mozilla understands their root store to trust and what it could potentially be made to trust. -- Eric On Thu, Mar 10, 2016 at 6:43 PM, wrote: > On Tuesday, February 2, 2016 at 9:51:02 AM UTC-8, Kathleen Wilson wrote: > > All, > > > > I would like to start drafting the next CA Communication, with the goal > > of sending it around the end of February. > > > > For reference, previous CA Communications are here: > > https://wiki.mozilla.org/CA:Communications > > > > > I will greatly appreciate your feedback on the following draft of the > March 2016 CA Communication. > Are the appropriate topics covered? > Are the questions and available responses clear and sufficient? > Do you have suggestions about when the 'TBD' dates should be? > Any other thoughtful and constructive feedback on this will also be > appreciated. > > I delayed the CA Communication in order to add further customization to > the CA Community in Salesforce that will enhance how the communication and > survey responses are done. CAs will respond to this communication by > logging in to the CA Community in Salesforce. > > To view the draft of the March 2016 CA Communication as it will appear for > each CA in Salesforce, please browse to > https://wiki.mozilla.org/CA:Communications#March_2016 > and click on "Link to DRAFT of March 2016 CA Communication" > > The differences between this page and what the CA will see in the CA > Community in Saleforce are: > - The date picker fields, check boxes, and text entry fields are not > clickable/editable. > - There is no 'Submit' button at the bottom of the page. > > For your convenience I have copy-and-pasted the text from that page below. > > ~~~ > March 2016 CA Communication > > Dear Certification Authority, > > This survey requests a set of actions on your behalf, as a participant in > Mozilla's CA Certificate Program by [DATE TBD]. > > To respond to this survey, please login to the CA Community in Salesforce, > click on the 'CA Communications (Page)' tab, and select the 'March 2016 CA > Communication' survey. Please enter your initial response by [DATE TBD]. > After that, you may update your responses until the survey Expiration Date > of [TBD], by following these same steps. > > A compiled list of CA responses to the survey action items will be > automatically published. > > In addition to responding to the action items in this survey, we request > that you follow and contribute to discussions in the > mozilla.dev.security.policy forum, which includes discussions about > upcoming changes to Mozilla's CA Certificate Policy, questions and > clarification about policy and expectations, root certificate > inclusion/change requests, and certificates that are found to be > non-compliant with the CA/Browser Forum's Baseline Requirements. Your > contributions to the discussions will help shape the future of Mozilla's CA > Certificate Program. > > Participation in Mozilla's CA Certificate Program is at our sole > discretion, and we will take whatever steps are necessary to keep our users > safe. Nevertheless, we believe that the best approach to safeguard that > security is to work with CAs as partners, to foster open and frank > communication, and to be diligent in looking for ways to improve. Thank you > for your cooperation in this pursuit. > > Regards, > > Kathleen Wilson > Mozilla CA Program Manager > > ACTION #1a: As previously communicated, CAs should no longer be issuing > SHA-1 certificates chaining up to root certificates included in Mozilla's > CA Certificate Program. Check your systems and those of your subordinate > CAs to ensure that SHA-1 certificates chaining up to your included root > certificates are no longer being issued. Please enter the last date that a > SHA-1 certificate was issued that chained up to your root certificate(s) > included in Mozilla's program. (Required) > > > ACTION #1b: Enter the date when all of the SHA-1 certificates that chain > up to your root certificate(s) included in Mozilla's CA Certificate Program > will either expire or be revoked. As previously communicated we plan to > show the "Untrusted Connection" error whenever a SHA-1 certificate is > encountered in Firefox after January 1, 2017. (Required) > > > ACTION #1c: Enter the date by which safeguards will be put into place that > will prevent the fu
Re: Drafting Q1 2016 CA Communication
On 11/03/2016 00:43, kwil...@mozilla.com wrote: On Tuesday, February 2, 2016 at 9:51:02 AM UTC-8, Kathleen Wilson wrote: All, I would like to start drafting the next CA Communication, with the goal of sending it around the end of February. For reference, previous CA Communications are here: https://wiki.mozilla.org/CA:Communications I will greatly appreciate your feedback on the following draft of the March 2016 CA Communication. Are the appropriate topics covered? Are the questions and available responses clear and sufficient? Do you have suggestions about when the 'TBD' dates should be? Any other thoughtful and constructive feedback on this will also be appreciated. I delayed the CA Communication in order to add further customization to the CA Community in Salesforce that will enhance how the communication and survey responses are done. CAs will respond to this communication by logging in to the CA Community in Salesforce. To view the draft of the March 2016 CA Communication as it will appear for each CA in Salesforce, please browse to https://wiki.mozilla.org/CA:Communications#March_2016 and click on "Link to DRAFT of March 2016 CA Communication" The differences between this page and what the CA will see in the CA Community in Saleforce are: - The date picker fields, check boxes, and text entry fields are not clickable/editable. - There is no 'Submit' button at the bottom of the page. For your convenience I have copy-and-pasted the text from that page below. ~~~ March 2016 CA Communication Dear Certification Authority, This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program by [DATE TBD]. To respond to this survey, please login to the CA Community in Salesforce, click on the 'CA Communications (Page)' tab, and select the 'March 2016 CA Communication' survey. Please enter your initial response by [DATE TBD]. After that, you may update your responses until the survey Expiration Date of [TBD], by following these same steps. A compiled list of CA responses to the survey action items will be automatically published. In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements. Your contributions to the discussions will help shape the future of Mozilla's CA Certificate Program. Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. Regards, Kathleen Wilson Mozilla CA Program Manager ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. Check your systems and those of your subordinate CAs to ensure that SHA-1 certificates chaining up to your included root certificates are no longer being issued. Please enter the last date that a SHA-1 certificate was issued that chained up to your root certificate(s) included in Mozilla's program. (Required) ACTION #1b: Enter the date when all of the SHA-1 certificates that chain up to your root certificate(s) included in Mozilla's CA Certificate Program will either expire or be revoked. As previously communicated we plan to show the "Untrusted Connection" error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. (Required) ACTION #1c: Enter the date by which safeguards will be put into place that will prevent the future issuance of SHA-1 certificates that chain up to your root certificate(s) included in Mozilla's CA Certificate Program. If you have already completed this, then please enter the approximate date when those safeguards were completed. (Required) ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the requirement that CAs must provide public-facing documentation about certificate verification requirements and annual public attestation of conformance to the stated certificate verification requirements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. Respond with the date by which you plan to complete entry into Mozilla's CA Comm
Re: Drafting Q1 2016 CA Communication
On Tuesday, February 2, 2016 at 9:51:02 AM UTC-8, Kathleen Wilson wrote: > All, > > I would like to start drafting the next CA Communication, with the goal > of sending it around the end of February. > > For reference, previous CA Communications are here: > https://wiki.mozilla.org/CA:Communications > I will greatly appreciate your feedback on the following draft of the March 2016 CA Communication. Are the appropriate topics covered? Are the questions and available responses clear and sufficient? Do you have suggestions about when the 'TBD' dates should be? Any other thoughtful and constructive feedback on this will also be appreciated. I delayed the CA Communication in order to add further customization to the CA Community in Salesforce that will enhance how the communication and survey responses are done. CAs will respond to this communication by logging in to the CA Community in Salesforce. To view the draft of the March 2016 CA Communication as it will appear for each CA in Salesforce, please browse to https://wiki.mozilla.org/CA:Communications#March_2016 and click on "Link to DRAFT of March 2016 CA Communication" The differences between this page and what the CA will see in the CA Community in Saleforce are: - The date picker fields, check boxes, and text entry fields are not clickable/editable. - There is no 'Submit' button at the bottom of the page. For your convenience I have copy-and-pasted the text from that page below. ~~~ March 2016 CA Communication Dear Certification Authority, This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program by [DATE TBD]. To respond to this survey, please login to the CA Community in Salesforce, click on the 'CA Communications (Page)' tab, and select the 'March 2016 CA Communication' survey. Please enter your initial response by [DATE TBD]. After that, you may update your responses until the survey Expiration Date of [TBD], by following these same steps. A compiled list of CA responses to the survey action items will be automatically published. In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements. Your contributions to the discussions will help shape the future of Mozilla's CA Certificate Program. Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. Regards, Kathleen Wilson Mozilla CA Program Manager ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. Check your systems and those of your subordinate CAs to ensure that SHA-1 certificates chaining up to your included root certificates are no longer being issued. Please enter the last date that a SHA-1 certificate was issued that chained up to your root certificate(s) included in Mozilla's program. (Required) ACTION #1b: Enter the date when all of the SHA-1 certificates that chain up to your root certificate(s) included in Mozilla's CA Certificate Program will either expire or be revoked. As previously communicated we plan to show the "Untrusted Connection" error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. (Required) ACTION #1c: Enter the date by which safeguards will be put into place that will prevent the future issuance of SHA-1 certificates that chain up to your root certificate(s) included in Mozilla's CA Certificate Program. If you have already completed this, then please enter the approximate date when those safeguards were completed. (Required) ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the requirement that CAs must provide public-facing documentation about certificate verification requirements and annual public attestation of conformance to the stated certificate verification requirements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesfor
RE: OCSP Responders Are An Attack Vector For SHA-1 Collisions
Hi
Some additional information regarding Buypass Class 2 CA 1. The Buypass Class 2
CA 1 is a part of the first generation of Buypass CA infrastructure and this CA
was originally both an issuing and a root CA. We established a new generation
of CA infrastructure separating the root CAs and issuing CAs back some years
ago and have performed a migration from the old infrastructure to the new
infrastructure to fulfill the requirements within this area.
We did stop issuing certificates in the old infrastructure years ago, but it
was difficult to switch off the validation operations due to important end
clients and relaying parties (e.g. governmental entities) depending on this
services in the old infrastructure.
The last step in our migration plan has been to remove the support for
validation services in the old infrastructure. This has taken some time since
it must be performed in a controlled manner and we have used a staged approach
to reduce the consequences for our clients.
However, we have now been able to complete this last step and disabled the
Buypass Class 2 CA 1 as an OCSP responder. All validation operations are now
being taken care of in the new infrastructure.
Regards
Mads
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+mads.henriksveen=buypass...@lists.mozilla.org]
On Behalf Of Mads Egil Henriksveen
Sent: 9. mars 2016 18:53
To: Andrew Ayer; mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: OCSP Responders Are An Attack Vector For SHA-1 Collisions
Hi Andrew
Thank you for making us aware of this issue with our OCSP responder.
We did make a major change in our CAs some years ago where we among other
things established a new OCSP responder for all Buypass CAs used for
SSL/TLS-certificates (including Buypass Class 2 CA 1). However, the original
OCSP responder for Buypass Class 2 CA 1 is still active, even though it is not
referenced for use in SSL/TLS-certificates today.
We will do some investigation in order to identify any potentially problematic
consequences of disabling this OCSP responder before we can decide to do so.
However, as a short term measure we have reconfigured the OCSP responder to use
SHA256 instead of SHA-1.
Regards
Mads
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+mads.henriksveen=buypass...@lists.mozilla.org]
On Behalf Of Andrew Ayer
Sent: 8. mars 2016 22:58
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: OCSP Responders Are An Attack Vector For SHA-1 Collisions
As we all know, the Baseline Requirements forbid signing certificates with
SHA-1 after January 1, 2016. However, both the BRs and Mozilla policy are
silent on the topic of OCSP response signatures[1].
Theoretically, CAs could continue to sign OCSP responses with SHA-1
indefinitely. Indeed, among the 869 distinct OCSP responder URLs referenced in
CT logs, 351 sign responses with SHA-1 (as of March 5, 2016).
([1] The BRs forbid SHA-1 for signing "certificates to verify OCSP responses"
after January 1, 2017, but I take that to mean the signature on the OCSP
responder's certificate, not the OCSP responses themselves.)
Of those 351 responders, 209 will include an attacker-controlled nonce of
arbitrary length in the signed response (I tested with up to 1kb nonces). This
creates a condition *extremely* favorable for a chosen-prefix attack. The first
~200 bytes of the hash input are trivially predictable (the only variable parts
are the "Produced At", "This Update", and "Next Update" fields, which are all
based on the current time). This prefix is followed by the entirely
attacker-controlled nonce. An attacker can predict the prefix and stash the
collision bits in the nonce to create a collision with another preimage, such
as a certificate.
Fortunately, the majority of those responders sign responses using a
certificate that is restricted by ExtendedKeyUsage to OCSP signing, so the
worst that an attacker could do is forge OCSP responses. However, I found two
responders that sign responses using CA:TRUE certificates that are trusted for
server auth in NSS:
1. http://ocsp.buypass.no/ocsp/BPClass2CA1 signs responses with a root
certificate ("Buypass Class 2 CA 1") trusted for server auth in NSS.
There is no path length constraint.
Raw request:
https://www.agwa.name/misc/ocsp_collisions/sha1/buypass-response.ocsp
Request text:
https://www.agwa.name/misc/ocsp_collisions/sha1/buypass-response.txt
Raw responder cert:
https://www.agwa.name/misc/ocsp_collisions/sha1/buypass-response.crt
Responder cert text:
https://crt.sh/?q=0f4e9cdd264b025550d170806340214fe94434c9b02f697ec710fc5feafb5e38
2. http://ocsp.acedicom.edicomgroup.com/servidores signs responses with an
intermediate cert which chains up to "ACEDICOM Root". There are no path length
constraints in the chain.
Raw request:
https://www.agwa.name/misc/ocsp_collisions/sha1/acedicom-response.ocsp
Request te
