1361177 - add more comprehensive certificate transparency integration tests

Status: NEW

(Core :: Security: PSM, enhancement, P3)

Description

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Bug 1349312 will add a basic positive and negative test case for certificate transparency integration tests. We need some more:

(this is directly from an email I sent on the 26th of April)

To determine what we need here, I came up with a list of reasons why an
SCT might not be valid:

* invalid signature
* invalid data/encoding
* future timestamp
* duplicate of another SCT (so it adds no new information)
* from the same log but with a different timestamp (I'm actually not
sure if this is invalid, but it seems like it should be)
* from the same log but precert_entry vs. x509_entry (again, I'm not
actually sure if this is invalid)
* from an unknown log
* from a disqualified log with a timestamp after the disqualification time

For each of {embedded SCTs, TLS handshake / OCSP stapled SCTs}, we
should test that for each of these reasons, if there aren't otherwise
enough valid SCTs, the platform should consider that connection as not
passing CT checks. We should also test that if there are otherwise
enough valid SCTs, the platform should consider the connection as
passing CT checks.

We also need to check that the platform does the right thing during
session resumption (if a connection passed CT checks before, it should
again, and if not, then it shouldn't upon resumption).

Finally, from my reading of the specification, it seems SCT information
from OCSP must be stapled, but as far as I can tell, the current
implementation does not enforce this. That is, the platform will both
note SCT information gleaned from active OCSP responses and cache SCT
information from previous connections such that it could make use of
them in connections where that information is not present. I'm not sure
if this is a feature or a bug. Either way, we should add tests to ensure
the implementation behavior doesn't change unintentionally.

There are also a couple of one-off cases to consider:
* a certificate with a longer lifetime such that there aren't enough SCTs
* ensuring that SCTs from a disqualified log with timestamps before the
disqualification time are valid
* SCT collections with insufficient log operator diversity (we require
at least 2 currently)