On Mon, Mar 12, 2018 at 11:38 PM jacob.hoffmanandrews--- via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote: > > Given that Let's Encrypt has been operating a Staging Endpoint ( > > https://letsencrypt.org/docs/staging-environment/ ) for issuing > wildcards, > > what controls, if any, existed to examine the certificate profiles prior > to > > being deployed in production? Normally, that would flush these out - > > through both manual and automated testing, preferably. > > We continuously run our cert-checker tool ( > https://github.com/letsencrypt/boulder/blob/master/cmd/cert-checker/main.go#L196-L261) > in both staging and production. Unfortunately, it tests mainly the higher > level semantic aspects of certificates rather than the lower level encoding > aspects. Clearly we need better coverage on encoding issues. We expect to > get that from integrating more and better linters into both our CI testing > framework and our staging and production environments. We will also review > the existing controls in our cert-checker tool. > > > Golang's ASN.1 library is somewhat lax, largely in part to both public > and > > enterprise CAs' storied history of misencodings. > > Agreed that Go's asn1 package is lax on parsing, but I don't think that it > aims to be lax on encoding; for instance, the mis-encoding of asterisks in > PrintableStrings was considered a bug worth fixing. > > > What examinations, if any, > > will Let's Encrypt be doing for other classes of potential encoding > issues? > > Has this caused any changes in how Let's Encrypt will construct > > TBSCertificates, or review of that code, beyond the introduction of > > additional linting? > > We will re-review the code we use to generate TBSCertificates with an eye > towards encoding issues, thanks for suggesting it. If there are any broad > classes of encoding issues you think are particularly worth watching out > for, that could help guide our analysis. Well, you’ve already run into one of the common ones I’d seen in the past - more commonly with older OpenSSL-based bespoke/enterprise CAs (due to long-since fixed defaults, but nobody upgrading) Encoding of INTEGERS is another frequent source of pain - minimum length encoding, ensuring positive numbers - but given the Go ASN1 package’s author’s hatred of that, I would be surprised. Reordering of SEQUENCES has been an issue for at least two wholly independent CA software stacks when integrating CT support; at least one I suspect is due to using a HashMap that has non-guarantees ordering semantics / iteration order changing between runs and releases. These seems relevant to Go, given its map designs. SET encodings not being sorted according to their values when encoding. This would manifest in DNs, although I don’t believe Boulder supports equivalent RDNs/AVAs. Explicit encoding of DEFAULT values, most commonly basicConstraints. This is issue most commonly crops up when folks convert ASN.1 schemas to internal templates by hand, rather than using compilers - which is something applicable to Go. Not enforcing size constraints - on strings or sequences. Similar to the above, many folks forget to convert the restrictions when converting by hand. Improper encoding of parameter attributes for signature and SPKI algorithms - especially RSA. This is due to the “ANY DEFINED BY” approach and folks hand rolling, or not closely reading the specs. This is more high-level, but derived from the schema flexibility. Variable encoding of string types between Subject/Issuer or Issuer/NameConstraints. This is more quasigrayarea - there are defined semantics for this, but few get it right. This is more high-level, but derived from the schema flexibility. Not realizing DNSName, URI, and rfc822Name nameConstraints have different semantic rules - this is more high-level than encoding, but within that set. certlint/cablint catches many of these, in a large part through using an ASN.1 schema compiler (asn1c) rather than hand-rolling. Yet even it has had some encoding issues in the past. > Also, is this the correct timestamp? For example, examining > > https://crt.sh/?id=353754255&opt=ocsp > > Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a > > revocation time of 2018-03-12 23:58:10 UTC , but you stated your > alerting > > time was 2018-03-13 00:43:00 UTC. I'm curious if that's a bug in the > > display of crt.sh, a typo in your timezone computation (considering the > > recent daylight saving adjustments in the US), a deliberate choice to put > > revocation somewhere between those dates (which is semantically valid, > but > > curious), or perhaps something else. > > I believe this was a timezone computation error. By my reading of the > logs, our alerting time was 2018-03-13 23:43:00 UTC, which agrees with your > hypothesis about the recent timezone change (DST) leading to a mistake in > calculating UTC times. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
