Browsers and them 'supporting' TLS certificate transparency
Certificate Transparency involves all Certificate Authorities logging newly issued TLS certificates in various public 'CT Logs', and then generally adding some Signed Certificate Timestamps (SCTs) to the issued TLS certificate to demonstrate that they've done this. Interested parties can then watch the CT logs to look for bad or mis-issued TLS certificates, and TLS clients can take steps to check that TLS certificates are in the logs. Famously, Firefox currently does not 'support' Certificate Transparency. But what does this actually mean?
The "Browser Requirements" section of the MDN page on Certificate Transparency somewhat gives the game away here. Let me quote:
Firefox does not currently check or require the use of CT logs for sites that users visit.
The minimal meaning of 'supporting' CT in a browser is that the browser verifies that alleged SCTs from some supported CT logs are in fact validly signed, if there are any present in the TLS certificate. Chrome and Safari go further than this, requiring that there be some number of such verified SCTs from approved CT logs in order to accept the TLS certificate.
This is a non-trivial operational issue for a browser, partly because CT logs come and go over time. The browser maker will need to establish a procedure for evaluating and qualifying CT logs as ones that it will check SCTs from, and then it must watch and update its initial list of these CT logs (which has to be known by the browser). Probably you want a fast update mechanism so that you can rapidly push out updates to this list without a full browser upgrade (and the list of qualified SCTs may depend on when the certificate was issued).
To gain more assurance, the browser can potentially try to verify that the certificate is actually in the trusted CT logs it has SCTs from. The best current option appears to be getting this information and 'proof' from the web server, which requires either or both of adding a TLS extension to the TLS handshake (and parsing the result) or parsing an additional extension in any stapled OCSP response. It's not clear how many web servers support either at the moment, so any code added for this might not be widely tested (and might be hard to test). It's not clear to me if either Chrome or Safari attempt to do this at the moment, and anyway stopping here buys the browser almost no more assurance than validating the SCT (for reasons covered in yesterday's entry).
(If TLS servers don't provide this information to browsers, the browser can query CT logs itself for the 'proof', but doing so leaks the web site the user is visiting. This is probably not going to be a popular information leak to add to browsers.)
The browser can go further to try to detect CT log malfeasance (or compromise), but this involves at least one background web request every so often combined with a bunch of code to verify the proof (provided by the CT log) that one Signed Tree Head from a CT log is a subset of another STH. If TLS servers don't provide the extra CT information to browsers, doing this additional verification requires leaking information to the CT log on what website a user visited (okay, what TLS certificate the website used). If this work detects CT log malfeasance, it's not clear what the browser could do; at a minimum, reporting anything useful to the browser vendor probably requires breaking some degree of user privacy to report that you got a 'bad' STH from such and such a website at such and such a time (which also means routinely keeping this information, although browsers could manage it along side the other history information they currently keep and similarly throw it away with that information if asked to).
Chrome and Safari require the presence of some number of valid and verified SCTs from supported CT logs in order to accept TLS certificates, and as a corollary of that both have some program to decide on what are supported CT logs (and update that list from time to time). To do even this, Firefox would need a similar program to manage its own list (and then it would have to write additional cryptography code in the browser).