On Tue, Jan 7, 2025 at 8:52 AM bruce lee <[email protected]> wrote:
> Thanks for the second reply, I still have questions to follow: > > Question 9: > Based on your answer to question 8, if "A" and "B" are from the server > rather than from the Windows system, for instance, if the server sends a > certificate chain file (.crt) containing the PEM encodings of [C, A, B], in > this scenario, I still want to ask about the content mentioned in question > 8. How would Firefox make its selection? > Firefox will try the intermediates in the order received in the handshake. > Question 10: > Chrome uses the CA Issuer URL in the AIA field of the certificate to > download CA certificates for building the certificate chain. Does Firefox > have this capability? > No - Firefox does not do AIA chasing (it introduces additional latency in the handshake and is a privacy concern). Instead, Firefox proactively downloads all publicly-disclosed intermediate certificates that are part of Mozilla's Root CA Program. > Question 11: > Firefox has a path length limit of 8, but I'd like to know if there is a > path construction iteration limit in Firefox? > My investigation shows that Chrome has a parameter set to > kPathBuilderIterationLimit = 20, so its maximum allowed certificate chain > depth is also 20. This leads to the following construction process in > Chrome: > > First attempt to build: [ABCDEFG], this chain is invalid. > Second attempt to build: [AHIJKLMNOPQ], this chain is also invalid. > At this point, 17 certificates have appeared: [ABCDEFGHIJKLMNOPQ]. > When attempting the third build, if the 20th certificate is tried and a > trust anchor is still not found, the kPathBuilderIterationLimit is > exhausted, stopping the search, and the build fails. > Does Firefox have such a limitation? > Firefox's equivalent, buildForwardCallBudget, is 200000: https://searchfox.org/mozilla-central/rev/e24277e20c492b4a785b4488af02cca062ec7c2c/security/nss/lib/mozpkix/lib/pkixbuild.cpp#393 > 在2025年1月8日星期三 UTC+8 00:31:01<[email protected]> 写道： > >> On Tue, Jan 7, 2025 at 8:19 AM bruce lee <[email protected]> wrote: >> >>> I've seen your reply and I'll continue the discussion as I still have >>> some questions that I haven't figured out, here are my follow-ups: >>> >>> Question 6: >>> Based on your response to question 2 (Once a path to a trust anchor has >>> been found, it is validated), I have the following inference: >>> Once a path to a trust anchor is found, Firefox will immediately proceed >>> to validation. If this path passes validation, Firefox will stop looking >>> for other possible paths. This means that even if there is a shorter path, >>> as long as the found path has passed validation, it will be used. >>> Therefore, Firefox does not guarantee finding the shortest certificate >>> chain. >>> Is my understanding correct? I would like a 'Yes' or 'No' answer, along >>> with the relevant knowledge. >>> >> >> Yes. Firefox does not exhaustively search all possible paths, so there >> may be a shorter path than the one found. >> >> >>> Question 7: >>> In Chrome, one can obtain a log file through 'chrome://net-export/', >>> which provides the following information: >>> 1: The N paths that Chrome attempted to build, including the PEM >>> encoding of the certificates in the path and their Subject field contents. >>> (Assume the first N-1 paths were invalid, and the Nth path was valid). >>> 2: The reasons why the first N-1 paths were invalid, e.g. "CA >>> certificate key usage is incorrect". >>> Is there a way to achieve a similar effect as 'chrome://net-export/' in >>> Firefox, where I can see the information of every certificate chain that >>> Firefox attempted to build, as well as the reasons why the candidate chains >>> were invalid? >>> >> >> No. Firefox does not have a feature like this. >> >> >>> Question 8: >>> Based on your response to question 1, I think you misunderstood my >>> meaning. I am not concerned about the priority of the certificate source >>> categories; I need to rephrase my question. >>> Suppose there is an end-entity certificate "C". This certificate can >>> potentially be linked to two intermediate certificates, "A" and "B". >>> Intermediate certificates "A" and "B" share the same private key and have >>> the same subject name. Importantly, they also come from the same category >>> of library, e.g. both "A" and "B" are from the intermediate CA certificate >>> store on Windows. >>> In this case, how does Firefox make the selection? >>> In our experiments, we performed 500 tests, sending the end-entity >>> certificate "C" to Firefox, and then adding "A" and "B" to the Windows >>> intermediate CA certificate store, where "A" uses SHA256-RSA2048bits and >>> "B" uses SHA384-RSA2048bits, and all other fields are the same between "A" >>> and "B". >>> In each test, Firefox always selected the certificate "B" with the >>> SHA384 algorithm. >>> So I inferred that Firefox prefers the more complex signing algorithm. >>> I know I only understand the tip of the iceberg, so my question remains: >>> When faced with multiple certificates that share the same private key and >>> subject name, and come from the same certificate source category, how does >>> Firefox make the selection? For example, does it choose the certificate >>> with the more complex signing algorithm? The one with the longer validity >>> period? The one with the larger serial number value? If the two >>> certificates only differ in the binary data of the public key, while all >>> other fields are completely the same, just like facing identical twins with >>> different names, how does Firefox make the choice? >>> I hope to receive a complete answer that can support me in reproducing >>> the same selection logic as Firefox. >>> >> >> Firefox does not make any kind of ordering decision here. The ordering in >> this case would come from the order in which the operating system presented >> the certificates to Firefox. >> >> >>> 在2025年1月7日星期二 UTC+8 01:41:39<[email protected]> 写道： >>> >>>> On Sat, Jan 4, 2025 at 8:52 AM bruce lee <[email protected]> wrote: >>>> >>>>> Dear Browser Development Team, >>>>> >>>>> I am writing to inquire about the specific logic and algorithms >>>>> employed by your browser when constructing certificate chains, >>>>> particularly >>>>> in scenarios involving multiple intermediate certificates. I am looking >>>>> for >>>>> a thorough explanation of the decision-making process and, if possible, >>>>> the >>>>> location of the relevant code within your codebase. >>>>> >>>>> My specific area of interest is in how the browser handles situations >>>>> where it encounters multiple potential intermediary certificates that >>>>> could >>>>> link to a given end-entity certificate, specifically: >>>>> >>>>> Scenario: Consider an end-entity certificate "C". This certificate can >>>>> potentially be linked to two intermediate certificates, "A" and "B". >>>>> Key and Subject Identity: Intermediate certificates "A" and "B" share >>>>> the same private key and have the same subject name. >>>>> Field Differences: However, other fields within "A" and "B" are >>>>> different (e.g., different validity periods, subject alternative names, >>>>> extensions, etc.). >>>>> >>>>> In such a case, end-entity certificate "C" could be successfully >>>>> linked to either "A" or "B", resulting in two potential certificate chain >>>>> paths. >>>>> >>>>> My questions are: >>>>> >>>>> 1. Selection Criteria: What specific criteria or properties does the >>>>> browser prioritize when selecting between such multiple intermediate >>>>> certificates with the same subject name and public key? Is this selection >>>>> based on the most recently issued certificate, or the one with the longer >>>>> validity period, or some other factors? Please provide a complete list of >>>>> these criteria, ordered by priority. >>>>> >>>> >>>> Candidate issuers are determined by subject name alone during path >>>> building. The public key/signature is verified when validating a particular >>>> path. Firefox tries candidate issuers in the following order. If there are >>>> multiple certificates in a particular category, they are tried in no >>>> particular order. >>>> >>>> 1. Built-in root certificates >>>> 2. Third-party root certificates >>>> 3. Intermediate certificates from the TLS handshake >>>> 4. Third-party intermediate certificates >>>> 5. Preloaded intermediate certificates (the set of disclosed >>>> intermediate certificates in the CCADB) >>>> 6. Root certificates found in the NSS cert DB >>>> 7. Intermediate certificates found in the NSS cert DB >>>> >>>> >>>>> 2. Algorithm: Could you describe the detailed algorithm (or >>>>> pseudo-code) used by the browser when making this selection? I am >>>>> interested in understanding the complete process flow. >>>>> >>>> >>>> Firefox uses mozilla::pkix to build and verify certificate chains. This >>>> is done in two parts: path building and chain validation. Path building is >>>> essentially depth-first search to find a path to a trust anchor (this is >>>> where e.g. basic constraints are checked). The depth is limited to 8 >>>> certificates, and loops are disallowed. Once a path to a trust anchor has >>>> been found, it is validated (this is where signature and revocation >>>> checking happens). If a path turns out to not be valid, path building >>>> continues with the next suitable candidate certificate. >>>> >>>> >>>>> 3. Implementation Location: Could you please provide information on >>>>> the location within the browser's codebase where this certificate chain >>>>> selection logic is implemented? If possible, please include specific file >>>>> paths or code modules. >>>>> >>>> >>>> mozilla::pkix: >>>> https://searchfox.org/mozilla-central/source/security/nss/lib/mozpkix/ >>>> Firefox's TrustDomain implementation: >>>> https://searchfox.org/mozilla-central/source/security/certverifier/NSSCertDBTrustDomain.cpp >>>> Firefox's CertVerifier: >>>> https://searchfox.org/mozilla-central/source/security/certverifier/CertVerifier.cpp >>>> >>>> >>>>> 4. Rationale: What is the reasoning behind these design choices, and >>>>> what are some potential edge cases or known issues that they are designed >>>>> to mitigate? >>>>> >>>> >>>> This is the original design document: >>>> https://briansmith.org/insanity-pkix >>>> The short version is that among other issues, Firefox's previous >>>> implementation wouldn't fully traverse all available paths, which would >>>> lead to unexpected errors. In particular, it made implementing key pinning >>>> impossible. >>>> >>>> >>>>> 5. Specific Examples: If there are any practical examples or case >>>>> studies of where the logic is relevant, could you share a few cases? >>>>> >>>> >>>> The prioritization in 1 is largely for performance reasons. If Firefox >>>> can find a short path to a trust anchor, that means fewer signatures to >>>> verify, which is faster. If it can find intermediates and eventually a >>>> trust anchor without accessing the NSS cert DB, that is also faster. >>>> >>>> I understand the complexity of this area and appreciate any detailed >>>>> information you can provide. I am particularly interested in the technical >>>>> specifics behind these choices, as it directly relates to the security and >>>>> reliability of web browsing. >>>>> >>>>> Thank you for your time and consideration. I look forward to your >>>>> response. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "[email protected]" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion visit >>>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/8375bf7d-d061-4aef-b888-b1bbbd408fe6n%40mozilla.org >>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/8375bf7d-d061-4aef-b888-b1bbbd408fe6n%40mozilla.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHP1u2iF30APbjMup_3XxEer7Y4JJt4S2RMvVTcrw%3DUT305Osw%40mail.gmail.com.
