Thanks! I'll need to build a chain with one good and two broken certs. On Fri, 3 Dec 2021 at 11:55, Ryan Sleevi <r...@sleevi.com> wrote: > > (Will probably forget to send from the right address myself and end up double > posting đ ) > > On Fri, Dec 3, 2021 at 9:41 AM Andrew Cagney <andrew.cag...@gmail.com> wrote: >> >> (hopefully the correct address) >> >> I'm trying to understand CVE-2021-43527 and how it impacts verifying >> an untrusted end cert starting with a trusted root cert. >> >> In the blog >> https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html >> the example uses a self signed certificate. This means we have: >> >> vfy_CreateContext(key=untrusted, sig=untrusted) >> sigLen = SECKEY_SignatureLen(key); >> ... >> if (sig->len != sigLen) { >> PORT_SetError(SEC_ERROR_BAD_SIGNATURE); >> >> i.e., both SECKEY_SignatureLen(key) and sig-len are coming from the >> wire (untrusted source). >> >> However, when calling this function via CERT_PKIXVerifyCert(), the >> calls look more like: >> >> vfy_CreateContext(key=trusted, sig=untrusted) >> >> (trusted is either the root cert, or a previously authenticated >> certificate) which would mean that the (sig->len != sigLen) does the >> right thing? > > > Not quite. > > The calls arenât exactly vfy_CreateContext(key=trusted, sig=untrusted). > Thatâs because that approach only works if youâve already constructed the > entire path to a trust anchor, which hasnât really been a thing since The > Directory (X.500) failed in the 80s/early 90s. > > Instead, you work from the leaf cert (untrusted), doing a depth first search > of certificates, trying to see if you can build a chain that terminates in a > trust anchor. As a consequence, youâre doing > vfy_CreateContext(key=maybe-trusted-maybe-not, sig=untrusted). > > Thatâs what the logic at > https://searchfox.org/mozilla-central/source/security/nss/lib/certhigh/certvfy.c#740-750 > is doing - CERT_FindCertIssuer will return the first available issuer, which > be untrusted and sent by the peer (i.e. via TLS), might be untrusted and sent > by another peer (e.g. in the NSS memory cache of certificates), might be > untrusted from the local DB, or might be trusted. The design of the code > itself is assuming the issuer is untrusted, since (except for the trust > anchor), all the issuers in the path are. > > You can read more about such approaches at > https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6 > and RFC 4158. Legacy NSS (i.e. not LibPkix or mozilla::pkix) performs a > simple depth-first search with no backtracking. However, despite differences > in their path building approach, both Legacy NSS and LibPkix are affected by > this. > > Iâm not presently aware of any implementations in wide use that verify from > trusted->untrusted (i.e. âroot firstâ). That approach was more for X.500 > where The Directory provided âtheâ cert chain. As used by TLS and the PKIs in > practice, you generally start leaf first (most ignoring the order of other > certs sent in the TLS handshake, a widespread practice recognized by TLS > 1.3), and then continue building untrusted until you find trusted.
-- You received this message because you are subscribed to the Google Groups "dev-tech-crypto@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-crypto+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/CAJeAr6uf9FjO5oDU2hC6SLfDtUhZFRQ73NE%3DJC7ScrB2PC5mYQ%40mail.gmail.com.
