Wow, thanks for all the great feedback!
On Wed, Mar 26, 2014 at 2:47 PM, Daniel Kahn Gillmor
<d...@fifthhorseman.net>wrote:
> 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.
>
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.
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...
> > 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.
>
I'm clueless here - how often would a server installation have something
reasonable in /etc/ssl/certs?
A CA path might be helpful for reducing the false-positive noise of
correctly configured servers. As for actually broken chains, I've no big
hope for anything that requires admin intervention. If a server can't
configure its chain in the first place then we really can't expect them to
be able to configure a trusted cert store either.
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.
>
But we can only recommend that when they have OpenSSL >= 1.0.2 which
quickly gets messy, unless the recommendation is in the form of an error
log from the 1.0.2 code path.
>
> 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?
>
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. 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?
> --dkg
>
>
