Use of crt.sh ID in Incident Reports

[Ben Wilson]

All,

In an incident report recently, there was discussion about the right way to report the certificates involved in the incident. See https://bugzilla.mozilla.org/show_bug.cgi?id=1736064

In section 5 of https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report, it currently says, "5. In a case involving TLS server certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem."

We are thinking of removing the reference to the "crt.sh ID" and clarifying the instructions on providing the certificate fingerprints. Instead of the crt.sh database ID, for instance, crt.sh currently supports a lookup based on the SHA256 hash (https://crt.sh/?q=[sha256 hash]).

Should it instead say, "The recommended way to provide this is to ensure each certificate is logged to CT and then list the crt.sh fingerprint URL for each certificate in the format 'https://crt.sh/?q=[sha256 hash]', ...."? Should the SHA1 fingerprint also be allowed?

What is the preferred method, and which other alternatives should be allowed for unambiguously reporting / locating the certificates or their "complete certificate data"?

Thanks,

Ben

[Corey Bonnell]

Hi Ben,

Comments inline.

 

> Should it instead say, "The recommended way to provide this is to ensure each certificate is logged to CT and then list the crt.sh fingerprint URL for each certificate in the format 'https://crt.sh/?q=[sha256 hash]', ...."?

 

The current language on the Wiki doesn’t explicitly “encourage” the use of crt.sh (one can list fingerprints and not provide them in a crt.sh URL), whereas this proposal does. Not to besmirch crt.sh (it’s a great tool), but I don’t think we should recommend the use of a single tool over an interoperable solution. Namely, we should encourage listing SHA256 fingerprints and leave it to the reader to supply those fingerprints to the tool of their choice, whether that be crt.sh, Censys, or something else.

 

> Should the SHA1 fingerprint also be allowed?

 

I think we should encourage the use of SHA256 fingerprints and discourage other hash algorithms. Popular tooling (crt.sh, Censys, etc.) supports SHA256 fingerprints, whereas support for other algorithms may not be as universal.

 

> What is the preferred method, and which other alternatives should be allowed for unambiguously reporting / locating the certificates or their "complete certificate data"?

 

An alternative method would be to allow the specification of a CT log’s base URI and the entry number of the affected certificate. Uptime of CT logs is monitored by at least one Root Program, which provides assurance that the certificate can be retrieved. Additionally, retrieving the certificate is done in a documented, standard manner (any CT client can fetch the certificate).

 

Thanks,

Corey

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaY5t3yMs2bVoGy-F%3D2_Tph__G%2BfLARXD3TxBZ7MJK97sw%40mail.gmail.com.

[Rob Stradling]

> Should it instead say, "The recommended way to provide this is to ensure each certificate is logged to CT and then list the crt.sh fingerprint URL for each certificate in the format 'https://crt.sh/?q=[sha256 hash]', ...."? Should the SHA1 fingerprint also be allowed?

Hi Ben.  This post is really just a comment about crt.sh usage rather than a substantive response to your question.

For a general-purpose 'q=' search, crt.sh uses the following heuristic approach to determine the type of the search term:

  - if the search term can be parsed as a 64-bit integer, it performs an 'id=' search for a crt.sh ID; otherwise...

  - if the search term can be parsed as a "hex string" that represents precisely 20 bytes, it performs a 'sha1=' search for a SHA-1 certificate fingerprint; otherwise...

  - if the search term can be parsed as a "hex string" that represents precisely 32 bytes, it performs a 'sha256=' search for a SHA-256 certificate fingerprint; otherwise...

  - it performs an 'identity=' search.

So 'https://crt.sh/?q=[sha256 hash]' will indeed find a (pre)certificate whose SHA-256 fingerprint matches '[sha256 hash]'; however, when a specific type of search term is intended, I encourage folks to quote crt.sh URLs that use the most specific search type that is applicable.  In this case, what I mean is that I would encourage the use of 'https://crt.sh/?sha256=[sha256 hash]' URLs instead of 'https://crt.sh/?q=[sha256 hash]'.

I'm not bothered about the extra CPU cycles that it takes for crt.sh to execute the heuristic approach described above.  Rather, ISTM that a "?sha256=" URL is more self-descriptive than a "?q=" URL, and clarity is important.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ben Wilson <bwi...@mozilla.com>
Sent: 17 November 2021 22:46

To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Use of crt.sh ID in Incident Reports

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[Ryan Dickson]

Hi Ben,

Thanks for opening up this discussion.

Regarding your questions:

1) Should it instead say, "The recommended way to provide this is to ensure each certificate is logged to CT and then list the crt.sh fingerprint URL for each certificate in the format 'https://crt.sh/?q=[sha256 hash]', ...."?

For those CA operators currently submitting crt.sh IDs, I would imagine the transition from ID to SHA256 hash would simplify the reporting process, and in turn, would be well received.  

From a root program perspective, our interests are focused on allowing for an unambiguous method of identifying and facilitating access to problematic certificates.  For some additional perspective, as I've been ramping up in my new role, I've appreciated how easy it's been to review historical incidents on Bugzilla and quickly follow crt.sh ID hyperlinks to the corresponding certificate records.  If for whatever reason, crt.sh was unavailable or unavailable to serve specific records in the future (hopefully just a hypothetical situation), the historical value of past these discussions, at least as I've observed them, would be diminished.  In this regard, the transition to using the SHA256 hash as an identifier from crt.sh ID would at least offer some degree of future-proofing.

2) Should the SHA1 fingerprint also be allowed?

+1 to Corey's comment regarding standardizing on SHA256.

Thanks again!

- Ryan

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729197679DA013A8677EBEDAA9B9%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Nick Lamb]

On Wed, 17 Nov 2021 15:46:41 -0700
Ben Wilson <bwi...@mozilla.com> wrote:

> What is the preferred method, and which other alternatives should be
> allowed for unambiguously reporting / locating the certificates or
> their "complete certificate data"?

I would prefer https://crt.sh/?sha256= rather than q= because I think
it drops a stronger hint that this is just SHA256(certificate) for the
price of 5 ascii characters.

I would prefer Mozilla picks exactly one required format, because our
experience is that the simpler the requirement the more likely
everybody obeys it correctly. The prefix https://crt.sh/?sha256= plus a
SHA256 hash, it seems to me is a completely satisfactory way to do this
with the following set of benefits:

* No choices. One less thing to get wrong. Tools can produce exactly
this one format, and consume exactly this one format, even if they
don't talk to crt.sh

* Ergonomic for outsiders. Which certificates are we talking about?
Just follow the URL

* Future proof because it has the SHA256(certificate) in it.

If there's a need for something else, like SHA1 I think somebody who
needs that (from a participating Certificate Authority) ought to reach
out about this immediately explaining why. I don't think Mozilla should
add optional ways to do things which maybe nobody needs as this incurs
technical cost for no practical benefit.

Nick.

[Cynthia Revström]

Hi,

I am in support of sha256 only for uniformity and universal support.

+1 for Rob's comment regarding use of the "sha256" query string parameter for crt.sh URLs.

I do think "https://crt.sh/?sha256=[hash]" should probably be the recommended formatting, however simply specifying the sha256 hash should be allowed as to not require use of a specific website.

I would suggest to disallow any other websites unless they use similarly obvious URL formats with a sha256 hash, or even disallow any outside of a list of approved log sites. (that could include crt.sh, censys, etc)

The thinking I had here was that with something like the crt.sh URLs or just a list of hashes, it would be trivial to translate into your favorite cert viewer of choice with a simple regex or whatever. (in the case of list of multiple certs that could be annoying to deal with by hand)

-Cynthia

[Alex Cohn]

On Wed, Nov 17, 2021 at 4:46 PM Ben Wilson <bwi...@mozilla.com> wrote:

We are thinking of removing the reference to the "crt.sh ID" and clarifying the instructions on providing the certificate fingerprints. Instead of the crt.sh database ID, for instance, crt.sh currently supports a lookup based on the SHA256 hash (https://crt.sh/?q=[sha256 hash]).

Currently, requiring a crt.sh ID implicitly ensures the full certificate data is actually available from a CT log. I find the portability and future-proofing argument for SHA256 fingerprints compelling, but I'm a bit concerned that in the rush to put an incident report together it'd be easy for a CA to copy-paste a fingerprint from an internal system into a crt.sh URL without ensuring the cert is actually logged and the URL actually works. 

This would primarily be an issue for CAs that only log precertificates and not final certificates to CT upon issuance. Without the final certificate's full data there's no way to map its fingerprint back to the corresponding precertificate, so other user agents' CT logging requirements do not mitigate this issue.

Should it instead say, "The recommended way to provide this is to ensure each certificate is logged to CT and then list the crt.sh fingerprint URL for each certificate in the format 'https://crt.sh/?q=[sha256 hash]', ...."?

It might be useful to clarify "logged to CT" - does it mean "logged to the CT log behind my sofa"? "logged to a CT log that crt.sh monitors"? "logged to a CT log trusted by $OTHER_USER_AGENT"? "viewable on crt.sh"? 

Like others, I can think of no compelling reason not to standardize on SHA256 fingerprints.

Alex

[Ben Wilson]

I have updated the wiki instructions to read (new text in bold): 

In a case involving TLS server certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. It is also recommended that you use this form in your list "https://crt.sh/?sha256=[sha256-hash]", unless circumstances dictate otherwise.

https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Ben

[Aaron Gable]

Fantastic! I will say that Let's Encrypt used this format for our recent reports and going into the process knowing that we had a well-specified format that didn't require querying crt.sh for unique IDs made putting together the lists of affected certs very nice.

Aaron

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaahx1sifJ2uBKFiDn1Zvc1ijVohActmeHwxx2NCdW4TAg%40mail.gmail.com.