[schoen]

Next year Google Chrome will require people to publish all the certificates in Certificate Transparency, which will be a significantly better source of proof because then people who are in a better position to know that the attack is an attack will also have a straightforward way to see them.

[MichaelGG]

Is each cert chained to the previous somehow? Like a field from one hashed into the next, so that you can detect gaps in the issuance? That way they can't even issue a secret cert for a one time national security op without breaking the chain.

[castillar76]

Kind of. The way CT works is that everything submitted to a CT log is chained, so you can validate that the CT log's record of issuance is complete—that is, everything it has received has been digitally signed into its record, and you can verify that nothing has been removed from the record. So if you're presented a cert with a CT timestamp, you can validate that a CT log server saw and accepted that certificate (making it part of the public record). The signed timestamp (or timestamps--you're supposed to present stamps from a minimum of three different CT logs to make Chrome happy) has to be embedded in the cert or presented as part of the TLS handshake. (See https://www.certificate-transparency.org/how-ct-works for more info.)

All of that doesn't prevent someone from issuing a certificate from a public CA and /not/ submitting it to a CT server: there's no easy way to detect that. If someone did that, though, they would have to present the certificate to your browser without a CT stamp attached. Both Firefox and Chrome are working on implementing mandatory CT validation, at which point your browser will yell and scream if it is presented a cert from a public CA that doesn't have an associated CT stamp. (Right now, if you want to check CT timestamps on certs, you need a plugin (there's one for Firefox, e.g., at https://www.elevenpaths.com/labstools/certificate-transparen... although I can't vouch as to its completeness).) At that point, sneakily grabbing certs from a public CA won't do you any good because it will be obvious they're not legitimately issued.

[schoen]

> At that point, sneakily grabbing certs from a public CA won't do you any good because it will be obvious they're not legitimately issued.

An interesting problem in this design is how to persuade users that they've encountered something genuinely important that it would be helpful for them to tell someone else about. (Maybe browsers can store such questionable certificates offline and gossip about them to other TLS servers later.) It's not very common for people to be persuaded that errors on their computer matter and that other people will care about them... but this one does! :-)

I know HPKP has a report method which one could imagine generalizing somehow to CT inclusion failures, but, in many attack scenarios involving use of misissued certs, the victim's network connection is controlled by the attacker. In that case, the attacker will probably not want to allow the victim to report the attack to another server in real time.

[castillar76]

Interesting idea! I know the CT spec recommends that clients archive CT data received for later review, and it defines the concept of a CT 'auditor' that constantly reviews the logs from CT log servers looking for malfeasance. It would be interesting and very useful to amalgamate anonymized data from browsers into one of those auditors and crunch through it to compare to CT records.

[ChuckMcM]

Yes.