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/CAHP1u2iSHkQTjSAe_CSqnfNb8FP7BJDyhYFhCJhCbKwhCOXRhw%40mail.gmail.com.
