Certificate Transparency: Log a legit precertificate and issue a rogue certificate

Question

I'm trying to understand how Certificate Transparency solves the problem with dishonest Certificate Authorities embedding an SCT in their certificates. I understand that the log is append-only, and server can "prove" that the certificate was indeed logged.

Suppose I'm a rogue CA, and I want to issue a certificate but also log it to a couple of logs. I create a certificate for a domain name that nobody cares about (say foobar.com), and submit the precertificate to the logs. I can then get the SCT back. I can then remove the poison extension, and add another domain name (say, paypal.com) to the SAN field, and then issue the certificate.

Is there any mechanism that prevents me from doing this? Anyone scanning CT logs will not see that I issued a certificate for paypal.com, but the browsers are supposed to trust the certificate and will also believe that I have submitted the certificate to the log.

The very objective of CT is to prevent CAs from issuing certificates for what it should not. I'm sure there are baseline requirements that prevents this and the CA would be removed from the trusted roots if they are caught doing this. But is there any cryptographically secure way to prevent this?

Answer 1

Guessing: Wouldn't work. Same thing when some CAs tried to use a nonstandard redaction scheme. -- Which is just a specific variant of submitting one cert while actually issuing another. This was dectected by browsers that actually bother to check. -> My site has Certificate Transparency enabled but Chrome is still showing NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

-- CT enforcement is up to the browser. And AFAIK only required by Chrome for Symantec certs. But the CT-everything requirement is on the horizon for Chrome for October 2017. See: https://groups.google.com/a/chromium.org/forum/m/#!topic/ct-policy/78N3SMcqUGw

Edit 1: What is CT good for?

You wrote:

The very objective of CT is to prevent CAs from issuing certificates for what it should not.

It's not. The objective is not prevention but accountability. A CA can issue a cert for any domain anytime. That part is NOT changed by CT.

What is a game changer is that when a rogue cert is issued one of two things may happen:

• If the CA doesn't submit to CT at all or submits with a different host name then (as soon as browsers actually enforce this) the browser will reject the cert. And the rogue cert will be useless.
• If the CA does submit to CT with the right host name then the cert will be public. And a domain owner who cares may place an automated watch job for all his domain names on the CT logs. (Facebook offers a such a service for free.)

In their own words:

Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.

Answer 2

Yes, it is possible to catch the scenario that you described.

This is made possible because the entire certificate chain is stored in the log. The questions then are "which party has the responsibility to do this?" and "how do they do it?"

It seems to me that the primary responsibility is with the client, as the Relying Party (my interpretation, not stated in the standard), to check properly before relying on anything.

My reconstruction (interpretation?) of how it happens - based on the RFC 6962 document:

1. The Certificates (precertificate and the actual one) are logged and issued as you describe.
2. During the TLS handshake, Client includes a ClientHello extension "signed_certificate_timestamp" with extension_data as empty.
3. Server returns SCTs (multiple, from multiple log providers, if applicable) in extension_data with the type "signed_certificate_timestamp".
4. Client retrieves cert-chain from a/the Log, and performs 4 checks in any order.
5. (3a) Do the cert signatures match between the Server-provided cert vs Log-provided cert?
6. (3b) Do the cert SCTs match? (retrieval appears to be by LogID, so I would imagine this check is required)
7. (3c) Does the cert integrity check out? This is already a part of checks that are already in vogue.
8. (3d) Does the server name match one of the SNI/SN entries in the cert? This too is already a part of the checks currently in vogue.

I expect that if clients do 3a & 3b, the fraud will be caught. The role of the CT Logs and SCT stops with making the information available for clients (including Certificate Owners & CT Auditors) so that such fraud can be detected at the earlies.

If a Certificate Owner is not complicit in the scenario you described, the problem would be detected as soon as the Certificate is delivered to the owner and the Owner submits the certificate to the CT Log. There would be signature mismatch on the certificate.

Even if the certificate owner is complicit, when a compliant browser (client) makes this check, it would be caught in 3a or 3b, depending on how the data was altered on the cert.