CT is a simple idea. Currently, it's possible for certificates to be issued privately. The PKI was designed to scale (and scale it does), so there is no requirement that a certificate be downloaded from some trusted source: an SSL server can provide the client with a certificate chain that acts as a proof that a public key is owned by a particular named entity.
That has some advantages, most obviously, scalability and robustness. It also has one giant disadvantage: the only way to catch misbehaviour is to actually find a bogus certificate being used in the wild.
Certificate transparency is Google's plan to fix this. The idea is to evolve the PKI in a backwards compatible way. It creates public logs in which every certificate is meant to be registered. The certificates (or SSL handshakes, or a few other things) can then have a short mathematical proof embedded in them that the certificate was logged.
If the log proof isn't present then browsers remove the security indicators in order to apply pressure to people to get their certificates logged. It's supposed to be done by CAs so most SSL users should never notice any of this is happening.
Once certificates are being logged publicly the idea is anyone can do data mining over the log, for example to find certificates issued for their own website that they know they didn't request. Thus it allows crowdsourced policing of the CA system. Violations of the rules could be detected much faster.
Currently however only Chrome implements CT, and only for EV certs (the ones that make the address bar green), and the majority of CAs have been ignoring it, although the big fish are taking part. The customers of the smaller CAs that are pretending CT isn't happening will get a nasty surprise once Chrome stops treating their certificate as EV.
Small nitpick: Chrome implements CT for all certificates and shows its status, however they only currently plan to downgrade an EV certificate to a normal certificate.
Firefox has an open bug for implementation[1] but it's inactive for whatever reason.
You don't need implementation in the browser. You need the CAs to provide the public audit logs and all HTTPS domain owners to check them for unexpected issuance.
The browser is just a political tool to enforce the CAs to provide the logs, for example by no longer marking their certs as trusted unless they do so.
There is none, which is why I said the browser is just a tool in a politics game. It enforces the existence of the log. The security doesn't come from checking whether the cert is in the log!
On its face the idea of making a note of what certificates are created is a simple idea, but in reality CT is far from simple, and it does not actually "fix" these sorts of problems.
CT is an attempt a transparency, that's it. It cannot prevent MITM attacks because it allows unaffiliated third-parties to issue certificates on your website's behalf (same as X.509), something that they have no business doing (and is completely unnecessary).
Nor does it guarantee that mis-issued certificates will be found. The reason is partly because, as you note, it is mostly a voluntary effort on behalf of the CAs out there, but also because its design is ineffective. Even if every CA participated in CT, it would still not accomplish much:
1. It does not prevent these types of attacks from being used on users.
2. It does not guarantee that mis-issued certificates would be found because it requires website owners to query all the logs out there in order to find out whether or not someone mis-issued a certificate (a sort of needle in a haystack problem that almost no one [except maybe large companies like Google] is going to engage in, and in the end doesn't prevent attacks from happening).
Whoever downvoted the parent, how about replying to the comment instead?
We spent a good amount of effort analyzing CT, and if you believe we missed something, your reply is worth a lot more than a downvote & run.
It's odd how much effort is being put behind this effort, especially given that in this particular attack Google would have nothing to gain from CT (since all it can hope to do is tell them who issued the fraudulent cert, which they already know).
I love that they came back to downvote your appeal to good netiquette.
HN needs a learning option for downvote external validity -- consitent upvotes on something a user downvoted should degrade the weight of their downvote for all articles.
That has some advantages, most obviously, scalability and robustness. It also has one giant disadvantage: the only way to catch misbehaviour is to actually find a bogus certificate being used in the wild.
Certificate transparency is Google's plan to fix this. The idea is to evolve the PKI in a backwards compatible way. It creates public logs in which every certificate is meant to be registered. The certificates (or SSL handshakes, or a few other things) can then have a short mathematical proof embedded in them that the certificate was logged.
If the log proof isn't present then browsers remove the security indicators in order to apply pressure to people to get their certificates logged. It's supposed to be done by CAs so most SSL users should never notice any of this is happening.
Once certificates are being logged publicly the idea is anyone can do data mining over the log, for example to find certificates issued for their own website that they know they didn't request. Thus it allows crowdsourced policing of the CA system. Violations of the rules could be detected much faster.
Currently however only Chrome implements CT, and only for EV certs (the ones that make the address bar green), and the majority of CAs have been ignoring it, although the big fish are taking part. The customers of the smaller CAs that are pretending CT isn't happening will get a nasty surprise once Chrome stops treating their certificate as EV.