[Cryptography] The Trouble with Certificate Transparency

Theodore Ts'o tytso at mit.edu
Sat Sep 27 20:23:00 EDT 2014


On Sat, Sep 27, 2014 at 03:15:25PM -0700, Greg wrote:
> 
> https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/

I've looked at the blog entry, and compared it to the Certificate
Transparency descriptions, and I believe that CT does add value.  Is
it a silver bullet that solves all problems?  Of course not.

The fact that anyone can run a log, and a certificate (or TLS session)
should include multiple SCT's, including some from trusted third-party
log services, means that if a government agency wants to order a CA to
issue a bogus cert via a NSL order, it would now need to send NSL's to
N log services so they could also issue SCT's and create forked Merkle
Hash Trees.  That right there increases the costs to the government
agency; and if the browser (client) policy included some rule that at
least one SCT must come from a log service has to be run in some
country that is outside of Five Eyes and NATO, that right there can
significantly increase the costs to the FBI.  (One could imagine a
system the client might require that for a particular server, it would
require SCT's from log services running in China, Russia, and the US.
If some organization like ISIS manages to piss off the US, China and
Russia, such that all three countries issue NSL's to the log services
running in their territories, one might argue that this organization
deserves everything that is coming to it.  :-)

Another thing which a laptop client could do is save all of the
certificates it has ever received, and periodically try to submit all
of them to one or more log servers whenever it comes up on some new
network.  Remember, the log servers will accept certificates from
anyone, so long as they properly chain up to a trusted set of root
CA's.  If someone tries to MITM a laptop user with a forged cert, it
will chain up to the root CA, so if the laptop even once manages to
come up on a network not controlled by the MITM attacker, and the
laptop manages to squirt certificates which it has seen out to one or
more log servers, then the covert MITM attack will no longer be
covert.

Even if not every client does this, if enough clients start playing
this game, it makes it very hard to do pervasive monitoring using MITM
certs.  Yes, it might not help against a targetted attack, unless that
laptop happens to be using a browser which is caching all of its certs
that it has seen and sending them up to the log server, but if someone
knows they might be subject to a targetting attack, they can use
client software which does this.

Note too that that the log sevices used by the client don't have to be
the same as the log services used by the CA's or by the web servers to
issue SCT's which are either embedded in the certificate, stapled to
the OCSP, or sent via a TLS extension.  These could log services run
by the EFF, and FSF/E in Germany, and so on.  Perhaps something more
sophisticated and/or efficient can be done by the
not-yet-very-well-defined gossip protocols referenced in the slides,
but something fairly basic could be done using the existing defined CT
services.

Ultimately, if you are really concerned about a very sophisticated
attacker who is able to MITM every connection, it's unlikely such an
attacker would have the resources to do that with everyone, but this
is now really much more of a targetted attack.  And IMHO it's not that
important to make such attacks impossible.  If the attacks become more
expensive than someone simply performing a black bag job and bugging
the hardware to a fare-thee-well, then that's quite sufficient.
Because that's exactly what the FBI will do, instead of trying subvert
the CA and multiple logging services located in different countries
with National Security Letters.  :-)

						- Ted


More information about the cryptography mailing list