On 03/26/2014 07:11 AM, Emilia Kasper wrote: > The patch fixes a) by sanity-checking the chain and chopping self-signed > roots. I believe it's harmless to turn on by default as the rebuild step > will either yield a valid chain or preserve the original configuration.
I like this suggestion. with a worst-case-engineering mindset, though,
i wonder if there aren't some places where this might cause problems
is it possible that there exist cross-signed "root certs", and clients
which auto-chain them back to another cert? for example:
CA X has older root cert Y.
X creates new root cert Z.
X creates new intermediate CA cert Y', with the same
SubjectPublicKey as Y, but signed with Z, to indicate that browsers that
accept certs signed by Z should also accept certs signed by Y. (perhaps
Y' has a shorter expiration date than Y, to indicate a new transition plan)
Some older clients ship Y in their root store, but do not know about Z.
Some newer clients ship Z in their root store, but deliberately do not
ship Y' or Y.
I'm assuming that a client would note the subject keyID and the proper
signature to terminate the chain at Y or Y' if it has either of them in
its root store. (maybe i'm mistaken about this)
If a mod_ssl server's EE cert W is signed by Y, and they ship Y,W, then
they work for all clients. With this patch applied, they would normally
ship just W; this would fail newer clients.
And of course, the web server could ship Y',W (if they know about Y'),
which would survive this cut.
This is a pretty perverse situation, though, and perhaps the answer is
that CA X just shouldn't do that kind of weird/chained reissuance over
the key in Y. I've also done no certificate surveys to see if this sort
of scenario has actually happened anywhere in the modern landscape.
> I've no good idea how to reliably detect and fix missing intermediates but
> would be happy to try out any good suggestions.
detection
---------
If the server has a list of root CAs that it expects clients to have, it
should be straightforward to detect missing intermediates. However,
SSLCACertificate{Path,File} and SSLCADNRequest{Path,File} don't work
here, because the list of CAs that a server is willing to accept for
client certs is orthogonal to the list of CAs that it expects a client
to hold. (mod_ssl's minor conflation of these two purposes by its
willingness to build server chains from the SSLCACertificate{Path,File}
is a bad idea because it encourages administrators to accept client
certs from the CAs that issued the server's cert)
One option would be to use OpenSSL's default CA path for this (e.g.
/etc/ssl/certs in debian), and to introduce another configuration
directive for administrators to override this choice.
Alternately, we could encourage the administrator to list the full chain
(including the root) in SSLCertificateChainFile. This would allow for
reliable detection, and wouldn't bloat the handshake if the patch here
is applied.
correction
----------
The best way i see to autocorrect this is to have a publicly-accessible
list of intermediate certificate authorities (and this archive might as
well include public root authorities as well), addressable by
SubjectKeyID. This seems like something that could be pulled from a
network survey, and could be verified automatically. Maybe it already
exists?
Then when mod_ssl notes that an intermediate is missing, it could log an
error message saying "an intermediate CA is missing. you probably want
to load append an intermediate certificate from
https://example.com/ca-archive/<subjectkeyid> to
<SSLCACertificateChainFile>"
A non-minimal web server installation might want to bundle such a
dataset of intermediate CAs alongside their apache installation (or
provide it as an auxiliary package) to allow the admin to do an
automatic local fetch. But in this case, it's conceivable that you
could just point mod_ssl at this indexed local cache (via some new
directive, i think -- we can't really overload any of the existing ones)
and have it construct the chain without assistance from the
administrator at all.
CT might be a good place to gather this information from -- are there
plans to ensure that all intermediate CAs are logged publicly?
--dkg
signature.asc
Description: OpenPGP digital signature
