Spec and Code

[Ben Laurie]

http://www.links.org/?p=1226

"Certificate Transparency: Spec and Working Code

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 repository, or for your viewing convenience, I just made an HTML version.

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.

If you build the code according to the README, then you will find instructions in test/README for 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 list."

[Rob Stradling]

Hi Ben. 

• 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.

When installing a certificate issued by a third-party CA, a significant number of website operators fail to perform "appropriate configuration" for SSLCertificateChainFile even though they have been given clear instructions.

I'd expect an even higher rate of screw-ups if they have to install an extra audit-proof "certificate" too!

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

IIRC, adding that extra certificate will break the default browser in Android <=2.1, which today would affect ~9.2% of all Android users (http://developer.android.com/resources/dashboard/platform-versions.html).

and avoid the need to change server software.

So it works for Apache.  And it'll work for nginx too.

But it won't work for IIS unless you either...

1. Write a server-side "plugin" that hooks (perhaps using Microsoft Detours) various CryptoAPI functions, notably CertGetCertificateChain()...and somehow persuade all IIS users to install this plugin.

or

2. Work with the CAs to get the audit proof embedded into the real certificate so that you don't need the extra certificate.

...since we are bending the rules...

Let's be clear: Adding the audit proof as a self-signed "certificate" _breaks_ the rules.  The TLS WG would have a fit.

But if the audit proof could be embedded into the real certificate, no rules would be broken.

[Ben Laurie]

On 2 March 2012 10:10, Rob Stradling <r...@comodo.com> wrote:

Hi Ben. 

• 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.

When installing a certificate issued by a third-party CA, a significant number of website operators fail to perform "appropriate configuration" for SSLCertificateChainFile even though they have been given clear instructions.

I'd expect an even higher rate of screw-ups if they have to install an extra audit-proof "certificate" too!

Possibly, but these screwups should be immediately apparent, in that browsers will give scary warnings. AIUI this is less true for chaining certs coz sometimes browsers know them and sometimes they don't.

 

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

IIRC, adding that extra certificate will break the default browser in Android <=2.1, which today would affect ~9.2% of all Android users (http://developer.android.com/resources/dashboard/platform-versions.html).

Hmmm ... pretty sure we didn't see that much breakage when we tested, but that sort of thing does need dealing with somehow!

 

and avoid the need to change server software.

So it works for Apache.  And it'll work for nginx too.

But it won't work for IIS unless you either...

1. Write a server-side "plugin" that hooks (perhaps using Microsoft Detours) various CryptoAPI functions, notably CertGetCertificateChain()...and somehow persuade all IIS users to install this plugin.

or

2. Work with the CAs to get the audit proof embedded into the real certificate so that you don't need the extra certificate.

We can certainly consider an option for this, but it does cause substantial complication. I admit I have not yet looked at IIS - I hope you're wrong!

 

...since we are bending the rules...

Let's be clear: Adding the audit proof as a self-signed "certificate" _breaks_ the rules.  The TLS WG would have a fit.

The correct way to do this is to use a TLS extension, which we will work on soon. So, rule-bending (or breaking) is only a stopgap.

 

But if the audit proof could be embedded into the real certificate, no rules would be broken.

As I say, I am happy to consider this as an option.

[Rob Stradling]

On Friday, 2 March 2012 10:30:55 UTC, Ben Laurie wrote:

On 2 March 2012 10:10, Rob Stradling <r...@comodo.com> wrote:

Hi Ben. 

• 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.

When installing a certificate issued by a third-party CA, a significant number of website operators fail to perform "appropriate configuration" for SSLCertificateChainFile even though they have been given clear instructions.

I'd expect an even higher rate of screw-ups if they have to install an extra audit-proof "certificate" too!

Possibly, but these screwups should be immediately apparent, in that browsers will give scary warnings. AIUI this is less true for chaining certs coz sometimes browsers know them and sometimes they don't.

Fair point.

 

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

IIRC, adding that extra certificate will break the default browser in Android <=2.1, which today would affect ~9.2% of all Android users (http://developer.android.com/resources/dashboard/platform-versions.html).

Hmmm ... pretty sure we didn't see that much breakage when we tested, but that sort of thing does need dealing with somehow!

I mentioned this to AGL a couple of months ago.  He replied:

"Thanks to your hint, I've confirmed that Android < 2.2 rejects certificate chains with superfluous certificates."

http://www.ietf.org/mail-archive/web/pkix/current/msg30103.html

  

and avoid the need to change server software.

So it works for Apache.  And it'll work for nginx too.

But it won't work for IIS unless you either...

1. Write a server-side "plugin" that hooks (perhaps using Microsoft Detours) various CryptoAPI functions, notably CertGetCertificateChain()...and somehow persuade all IIS users to install this plugin.

or

2. Work with the CAs to get the audit proof embedded into the real certificate so that you don't need the extra certificate.

We can certainly consider an option for this, but it does cause substantial complication. I admit I have not yet looked at IIS - I hope you're wrong!

IIS automatically decides which cert(s) to send in the TLS handshake.  You can't override it (unless you hook various CryptoAPI functions).  I guess the IIS developers never expected anyone to have any good reason to bend/break the rules!

We (Comodo) had a good reason to break these rules ~5 years ago.  We developed a server-side "plugin".  It worked, although the source code was rather scary, and IIRC a significant number of customers didn't want to run it on their servers.  If this "plugin" approach can be avoided, I'd advise you to avoid it!  (Oh, I should probably mention our patent: http://www.freepatentsonline.com/y2010/0030897.html)

[Adam Langley]

I mentioned this to AGL a couple of months ago.  He replied:

"Thanks to your hint, I've confirmed that Android < 2.2 rejects certificate chains with superfluous certificates."

http://www.ietf.org/mail-archive/web/pkix/current/msg30103.html

Yep, stock Android < 2.2 doesn't work with this, although it does appear that some manufacturers might have fixed this before shipping their versions of Android 2.1. I haven't been able to find such a device to confirm.

Superfluous certs certainly aren't the final word in getting the audit proofs to the client, but they are convenient for configuring Apache.

Cheers

AGL

[Paul Tiemann]

Sorry for joining late...

Rob is right -- you'd have to develop a plugin for IIS -- maybe even multiple versions?

I don't know if the goal includes yet other platforms too, but there are a fair number of other server platforms that do their own SSL chain building: Java keystore based servers may present similar headaches.

Cheers,

Paul