[cryptography] Certificate Transparency: working code

Ben Laurie ben at links.org
Thu Mar 1 14:17:51 EST 2012


"Certificate Transparency: Spec and Working Code<http://www.links.org/?p=1226>

Quite a few people have said to me that Certificate Transparency (CT)
sounds like a good idea, but they’d like to see a proper spec.

Well, there’s been one of those for quite a while, you can find the latest
version in the code
or for your viewing convenience, I just made an HTML

Today, though, to go with that spec, I’m happy to announce working
code<http://code.google.com/p/certificate-transparency/> for
a subset of the protocol. This covers the trickiest part – a fully
backwards compatible SSL handshake between servers and clients. The rest of
the protocol will necessarily all be new code for interacting with the log
server and other new components, and so should not have these issues.

If you build the code according to the
then you will find instructions in
the demo.

What this does, in short, is the following:

   - Run a CT log server. Currently this has no persistence across runs,
   but does keep a full log in memory.
   - Issue a self-signed server certificate. A CA issued certificate would
   also be fine, but not so easy to automate for a demo.
   - Use the CT client to register that certificate with the log server and
   to obtain a log proof for it.
   - Use the CT client to convert that proof into a fake “certificate”
   which can be included in the certificate chain in the TLS handshake.
   - Run an Apache 2.2 instance to serve the self-signed certificate and
   the log proof certificate. Note that Apache is unmodified, all that is
   needed is appropriate configuration.
   - Use the CT client to connect to the Apache instance and verify the
   presented log proof.
   - You can also connect to Apache with an existing browser to check that
   you can still access the site despite the presence of the log proof.

There’s plenty more to be done, but this is the part that needs the
earliest scrutiny, since we are bending the rules to get back compatibility
and avoid the need to change server software. Client software has to change
anyway to provide any benefit to users, so that’s less of a worry.

We welcome discussion, suggestions and questions on the mailing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20120301/81c246ae/attachment.html>

More information about the cryptography mailing list