httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kahn Gillmor <>
Subject Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
Date Wed, 26 Mar 2014 16:46:26 GMT
On 03/26/2014 11:29 AM, Emilia Kasper wrote:
> Cross-signing happens all the time but afaik the other way around, i.e., an
> intermediate Y' corresponding to a _newer_ root cert Y is cross-signed by
> some _older_ root cert Z. So an old client would usually know only Z and a
> newer client would know Z and Y (or even Y' - some clients directly trust
> intermediates these days).
> W, Y' is the correct chain to ship. Shipping W, Y is unnecessary for
> clients that have either Y or Y' in their local store - they can build the
> chain from W alone. And conversely, shipping W, Y won't help against
> clients that only know Z - they can't build the chain through Y' no matter
> what.

And by your patch, a server configured to ship W,Y would be stripped to
a serve just W, which wouldn't work for clients that only know Z either.

> In general shipping a self-signed certificate should never help with
> anything as the client must have an exact copy in the local store to trust
> it. That said, there are always surprising perversities in SSL...

ah, this brings to mind one other thought:  We're relying here on
servers not using HPKP as a mechanism to introduce novel CAs that are
only usable for a given host.

For HPKP, that might be possible, because
suggests that any TLS errors will cause a connection termination anyway,
before pins are checked.  But, it's conceivable that an HPKP
implementation could modify a TLS stack to allow a novel root cert base
on its SPKI matching a known pin for a given site.  I don't see that
implementation choice explicitly forbidden in the spec.

to be clear about the scenario:

a TLS server could use HPKP to indicate a set of acceptable signing
authorities for the site, including the current certifying authority.
This enables the site to indicate, say, that it is willing to rely on
FooCA for its certificates (currently in use), plus BarCA, that the
browser has never seen before.  The browser now has a hash of both
FooCA's public key and BarCA's public key, and it knows that these two
are the only legitimate signing authorities for the site in question.

At some point, the site administrator switches over to BarCA (perhaps
they learn that BarCA has finally been imported into the root store of a
major browser that they care about).  But some clients don't list BarCA
yet, even though they've recorded these public key pins.

Now a server might want to explicitly ship EE,BarCA so that clients who
know about the pin but don't yet know about the cert can make the

If we want to avoid this situation, maybe it needs to be clarified as
something HPKP needs to forbid?  or maybe it's too far in the weeds to
seriously consider it.

> I'm clueless here - how often would a server installation have something
> reasonable in /etc/ssl/certs?

hm, well, the ca-certificates debian package (which will install things
in /etc/ssl/certs by default) has a higher popcon score than
apache2-bin, which is a requirement for apache:

otoh, ca-certificates is also installed on desktop systems, and i don't
think the summaries published by the popcon project show the
intersection of two packages.  i can ask folks within debian about that
if people think this sort of spot-check would be useful (it doesn't
cover other OSes or even debian users without popcon installed, of course).

> No current plans for CT to require logging intermediates. But actually, if
> we go the autocorrect route then we should just implement AIA fetching.
> Modern certs should have a CA Issuers field in the
> AuthorityInformationAccess extension in them that the chain builder could
> follow recursively

ah, this sounds like a very useful piece of data.

> I've now looked a bit more at the mod_ssl code and it's
> a bit of work but maybe not all that different from doing OCSP, really?
> The wrinkle with remote fetching at runtime is of course that it's
> nondeterministic, so you may end up serving a different chain depending on
> the network weather. Print the corrected chain big and bold in the error
> logs and live with it?

it doesn't even need to fetch the certificate itself, it could just make
the big noisy error log say "you should fetch the cert from <AIAURL> and
append it to <SSLCertificateChainFile>"


View raw message