Hi Nils, This is interesting, but unfortunately, doesn’t work. The 4-certificate hierarchy makes the very basic, but understandable, mistake of assuming the Root CA revoking the SICA is sufficient, but this thread already captures why it isn’t.
Unfortunately, as this is key to the proposal, it all falls apart from there, and rather than improving security, leads to a false sense of it. To put more explicitly: this is not a workable or secure solution. On Mon, Nov 16, 2020 at 2:58 AM Nils Amiet via dev-security-policy < [email protected]> wrote: > Hello all, > > My colleague Andre and I recently became aware of this problem and we > explored > a new solution to it. > Please find our analysis below. > > For a formatted version of this message with images inline, please find it > available at: > https://research.kudelskisecurity.com/2020/11/16/a-solution-to-the-dangerous-delegated-responder-certificate-problem/ > > === > > Issue of the Dangerous Delegated OCSP Responder Certificate > > 1. Introduction > > In this memo, we address the issue of the "Dangerous Delegated OCSP > Responder > Certificate" [1]. We propose a new solution, different from the original > solution suggested in the Mozilla Dev Security Policy (mdsp) mailing list. > > This proposed solution addresses compliance issues, security risks, > feasibility, time to implement and practicability (e.g. operational > aspects) as > well as negative financial consequences. For the feasibility, please > consider > the Proof of Concept provided in [2]. > > This memo is structured as follows. First, section 2 below describes and > compares the two solutions. Then, section 3 analyzes them by providing an > extensive list of potential concerns and discussing each of them in detail. > > To illustrate the analysis further, a complete set of diagrams is > available at > [3]. > > > 2. Description of the initial situation and the two solutions > > 2.1. Initial situation > > Image: > https://raw.githubusercontent.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc/master/img/initial_situation_diagram.jpg > Figure 1: Initial situation - 4-level hierarchy > > In Figure 1, SICA contains the problematic id-kp-ocspSigning Extended Key > Usage > (EKU). The goal is to reach a situation where the EE certificate can be > verified up to the root CA in a chain where this EKU extension is not > present > anymore. Indeed, the mere presence of this EKU makes SICA a delegated OCSP > responder on behalf of ICA. If SICA was intended to be an issuing CA and > not an > OCSP responder, there is the security risk that SICA signs an OCSP > response for > any sibling certificate on behalf of ICA. This is a huge security concern > if > siblings are not operated by the same company/entity. This risk can impact > all > the Sub-CA companies having certificates under ICA. Hence, it is important > that > all the direct children certificates of ICA that have this problem are > neutralized. > > In addition to the security risk, there is also a compliance issue that is > introduced because the Baseline Requirements [4] state that OCSP responders > must also have the id-pkix-ocsp-nocheck extension in addition to the EKU. > > 2.2. Original solution > > Image: > https://raw.githubusercontent.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc/master/img/original_solution_diagram.jpg > Figure 2: Original solution - 4-level hierarchy > > The original solution addresses the issue in the following way (see Figure > 2): > > (i) a new SICA2 certificate is issued. It is signed by ICA and is based on > a > new key pair; > > (ii) the old SICA certificate is revoked and, very importantly for security > reasons, its associated private key is destroyed during an audited > ceremony; > > (iii) new EE2 certificates are issued by SICA2. > > 2.3. New solution > > Image: > https://raw.githubusercontent.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc/master/img/new_solution_diagram.jpg > Figure 3: New solution - 4-level hierarchy > > The new solution addresses the issue as illustrated in Figure 3, which can > be > summarized as follows: > > (i) RCA issues a new ICA2 certificate, using a new DN and a new key pair; > > (ii) RCA revokes the old ICA; > > (iii) ICA2 issues a new SICA2 certificate, which reuses the same SICA DN > and > key pair but does not contain the OCSP problematic EKU; > > (iv) SICA is also revoked. > > Since the same DN and key pair are reused for SICA2, the EE certificate is > still valid. > > Also, the new SICA2 cannot be involved in any OCSP response, in any > context at > all (removal of the problematic EKU). The old SICA cannot be involved in > any > OCSP response either, in any context at all (it does not validate with > regard > to the new ICA2 and ICA is revoked). Finally, no third party, which would > not > have properly done the job of properly renewing a problematic SICA > certificate, > can do any harm to any other company (the old validation branch is not > available anymore by the revocation of ICA). > > 2.4. Differences between the 2 solutions > > 2.4.1. 3-level vs 4-level hierarchy > > The original solution works in both a 3-level hierarchy and 4-level > hierarchy. > The new solution works only in a 4-level (or more) hierarchy because that > hierarchy allows for the parent of the affected certificate to be revoked > because it is not a trust anchor. Therefore, no third party can be affected > because nobody trusts that chain anymore. This is impossible to achieve in > the > 3-level hierarchy because the parent of the affected certificate is a trust > anchor and cannot be revoked. > > 2.4.2. Risk surface > > However, each solution induces a different risk surface. > > On the one hand, the new solution involves only one entity/company, the CA > that > issued the affected certificate. That CA must properly revoke its ICA > certificate and regenerate a new one. The only risk is that they do not > properly revoke the certificate that issued affected certificates. > > On the other hand, the original solution requires destruction of private > keys > during audited ceremonies by all Sub-CAs concerned by the issue, > independently. > This means that a single Sub-CA failing to do so puts all the other > Sub-CAs at > risk. The resulting risk is the sum of the risks of each independent > Sub-CA to > fail to properly destroy its private key. That risk quickly increases as > the > number of independent Sub-CAs grows. Moreover, as the risk surface of a > Sub-CA > is usually larger than that of a CA since dealing with PKI is not its core > activity but a technology it exploits, the situation is worsen. > > Because of this exposure, the new solution has a smaller risk surface than > the > original solution. > > 2.4.3. Simplicity of the solution > > The new solution is implemented using standard PKI procedures such as CRLs > for > revocation. A CRL is a simple and effective method to revoke a certificate > and > is industry battle-tested. > > On the other hand, the original solution relies on key destruction > ceremonies, > which are complicated to implement and cannot ultimately prove that the > risk is > zero. > > 2.4.4. Time to implement > > Since the original solution relies on key destruction ceremonies, it > requires > heavyweight coordination. Additionally, the number of end-entity > certificates > that need to be revoked can be huge for some CAs. For this reason, the > time to > implement the solution can be significantly longer. > > The new solution can be implemented at a higher level in the hierarchy and > does > not require key destruction ceremonies. It requires revoking only a few > certificates using simple CRLs. On top of that, only a few certificates > need to > be regenerated, thus considerably reducing the time required to implement > compared to the original solution. > > > 3. Eliminating security risks and compliance issues > > Several concerns have been raised in the Mozilla Dev Security Policy [1]. > The > concerns were two-fold: > > (i) A compliance issue (violation of a Baseline requirement). > > (ii) A security risk, allowing a delegated OCSP responder to sign > responses for any > sibling certificate, even if those siblings are not operated by the same > entity. > > In this section, we go through the raised concerns and address them with > respect to the new solution. > > 3.1. Compliance issue > > There is a violation of section 4.9.9 of the Baseline Requirements [4]. > > The proposed solution consists in revoking the affected SICA certificates > and > issue new ones without the id-kp-OCSPSigning EKU, which solves the > compliance > issue. > > 3.2. SICA siblings cannot be sure that the affected certificate is not > going to > unrevoke itself > > Image: > https://raw.githubusercontent.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc/master/img/three_level_diagram.jpg > Figure 4: 3-level hierarchy issue > > Assuming a 3-level certificate hierarchy such as the one in Figure 4 (RCA > -> > ICA -> EE), the concern is the following: if a new ICA2 is issued with the > same > key pair as ICA, then the private key was not destroyed and still exists. > Therefore, it can still be used to sign a valid OCSP response for ICA > itself or > for any sibling in the certificate hierarchy. Thus, allowing ICA to > unrevoke > itself. That is also true even if a new RCA2 is created and used to sign > the > new ICA2 because that would still make ICA valid because RCA is a trust > anchor > and the only way to “revoke” it is to remove it from trust stores. > > Contrarily to the 3-level hierarchy were the above concern applies, some > affected CAs have a 4-level hierarchy such as the one shown in Figure 3 > (RCA -> > ICA -> SICA -> EE), where the affected certificate with the > id-kp-OCSPSigning > EKU is named SICA. > > Since this is a 4-level hierarchy, the RCA in the 3-level hierarchy is now > our > ICA in this 4-level-hierarchy. Therefore, it is now possible to revoke the > parent of the affected certificate SICA (its parent is ICA). The resulting > operation does not require removing a trust anchor, which may take decades > until everyone updates their systems, but truly mitigates the security > risks > immediately. Indeed, even if a malicious person used SICA2’s private key to > sign an OCSP response to unrevoke SICA, since its parent (ICA) is also > revoked > and is not a trust anchor, the attack would not work. > > 3.3. Private keys may not have been properly destroyed > > An audited ceremony is not an absolute proof that no other copy of the > private > key exists. > > The community would benefit from revoking the parent (ICA) since some > non-TLS > issuing CAs may be unaudited and may have no other way to mitigate the > security > risk. > > 3.4. Offloading the pain to the community > > Anything other than a key destruction can be perceived as unfair since it > may > be asking everyone (web browsers, applications, etc.) to change and adapt > because someone failed to follow the expectations. It would put more work > on > the community to fix the problem by modifying how applications perform > certificate validation. > > However, the new solution only requires changes to a small subset of the > hierarchy and does not offload the burden to the community. The new > solution > uses traditional PKI features such as CRLs and does not require the > community > to make any changes to certification validation checks. > > 3.5. Feasibility – Proof of Concept > > We provide a proof-of-concept script written in Python that generates the > hierarchy in Figure 3 and test that the unmodified EE certificate is still > considered valid under the modified hierarchy using OpenSSL. The code and > documentation are available on GitHub [2]. > > 3.6. Practicability, adherence, and workload for the parties > > The original solution requires that all Sub-CAs with problematic > certificates > at the SICA level engage in a very costly re-securization campaign. > Non-concerned Sub-CAs have no work to do. In terms of security, it is > important > to stress that all Sub-CAs (the ones with problematic certificates and the > ones > without) remain at risk if a single Sub-CA does not do the proper work, or > does > it badly in terms of security. > > The new solution requires all Sub-CAs to act, but at a reduced cost, since > they > must roll only intermediate certificates, which are quite few usually. It > has > impacts and cost, but clearly lower. And there is no risk for any Sub-CA at > all, as the re-securization is managed at the ICA level by the CA. > > 4. Overall conclusion > > In this document, a new solution was proposed and compared to the original > solution. The feasibility of the new solution was verified by a > proof-of-concept that people can use to test for themselves. Both the > compliance issue and security risks were analyzed, without leading to any > negative impacts while also reducing financial strain for some > organizations. > Depending on the exact and detailed nature of the hierarchy, the new > solution > has proven to bring operational advantages and is equivalent or improved > with > regard to security. We propose the community validate this new solution as > well > as our conclusions. > > This analysis reflects the authors knowledge at the time of writing. In > case > concerns would be missing, the authors are willing to investigate them and > complete the analysis. For that purpose, members of the community are > encouraged to provide feedback in any form. > > > References > > [1] "SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated > Responder Cert", post by Ryan Sleevi on the Mozilla Dev Security Policy > mailing > list, > > https://groups.google.com/g/mozilla.dev.security.policy/c/EzjIkNGfVEE/m/XSfw4tZPBwAJ > . > [2] Technical feasibility proof of concept, written in Python. > Verification is > performed using OpenSSL. > > https://github.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc > [3] Detailed set of diagrams, file "OCSP_Signing_Issue_Figures.pdf". > Available > here: > > https://github.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc/blob/master/doc/OCSP_Signing_Issue_Figures.pdf > [4] CA/Browser Forum, "Baseline Requirements for the Issuance and > Management of > Publicly-Trusted Certificates", version 1.7.1, August 20th 2020. > [5] RFC 6960, Internet Engineering Task Force (IETF), "X.509 Internet > Public > Key Infrastructure, Online Certificate Status Protocol – OCSP", available > at > https://tools.ietf.org/html/rfc6960. > > > - Nils, André and the Kudelski Security team > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
