CT enforcement seems incorrect

[briansmith]

In the code there is logic like this:

        // 3. Verify any included SCTs.
        match (self.server_cert.scts.as_ref(), sess.config.ct_logs) {
            (Some(scts), Some(logs)) => {
                verify::verify_scts(&self.server_cert.cert_chain[0], now, scts, logs)?;
            }
            (_, _) => {}
        }

If the server doesn't supply SCTs then Rustls doesn't enforce that the certificate has been logged, even if the user configured CT logs. Without additional APIs for controlling it at a finer-grained level, the user configuring CT logs should force Rustls to ensure every certificate has been logged, and if the server doesn't send any SCTs then Rustls shouldn't accept the certificate.

[briansmith]

Further it should be possible to enforce CT for the client certificate, but Rustls only implements CT checks on the client side (for the server's certificate).

[ctz]

Back when I was initially doing this work, I found that support for SCT stapling in TLS was pretty patchy; compared to embedding the SCT list in a certificate extension. So rejecting a handshake because the SCT was inside the certificate rather than stapled seemed not very helpful.

[briansmith]

Back when I was initially doing this work, I found that support for SCT stapling in TLS was pretty patchy; compared to embedding the SCT list in a certificate extension. So rejecting a handshake because the SCT was inside the certificate rather than stapled seemed not very helpful.

Right. That's why I think fixing this depends on fixing #480, which I've started to do in PR #526. The certificate verifier needs both the stapled SCTs (if any) and the SCTs in the certificate (if any). It also needs the list of trusted logs which isn't necessarily available to the application using Rustls; it might be managed within the operating system.