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.
Today, though, to go with that spec, I’m happy to announce working code 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.
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 list.