Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <5332DA7F.2070702@fifthhorseman.net>
Date: Wed, 26 Mar 2014 09:47:43 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
References: 
 <CABp4ts2Wo3Xec71TT_-Cdi-UFv7=WMS3_PfxbHiUNLi=+8DDAA@mail.gmail.com>
In-Reply-To: 
 <CABp4ts2Wo3Xec71TT_-Cdi-UFv7=WMS3_PfxbHiUNLi=+8DDAA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="kWdmfhApc4uqsGupIt5PDlxHoTOipIhfQ"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--kWdmfhApc4uqsGupIt5PDlxHoTOipIhfQ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 03/26/2014 07:11 AM, Emilia Kasper wrote:
> The patch fixes a) by sanity-checking the chain and chopping self-signe=
d
> roots. I believe it's harmless to turn on by default as the rebuild ste=
p
> 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 pla=
n)

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


--kWdmfhApc4uqsGupIt5PDlxHoTOipIhfQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTMtp/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcchsQAJv7b/Ny//9wlARST/CXZz5a
opjciEfHaL7w4YXRU1aT5m1K9IHj+rcCX4M0mgdeWffa+meU65yIabR23m9P27Be
5lYHUxcLPi7RRnu5Q2u+4Xka88IOWppv5VNvhOZATwyRd79rhvX+eMGgl+Lk1+zd
/9VaKOqTpGSOrO9G/euDBJ8DsJ3lIKdx7MPX1jqJlX9uhqsz3SmZt8xqqWClsXDh
AUx8GSrYtWHl+nav+/5y3xIhnRoaQu6Sz/UALCZwSKbOsSA6H6vrOmlbDrkoBePd
l//2vkmqjHkPg9GfhT6lj7HK+uJ9xxQbXDQ0uby/5FCPZuhvhEQEpwuNBrJMwsTp
LG3o+z0lC5l2T3LR3JU1ixiFlB75A2PPh+agh8kpNwZNQNYuCXdH2Q9rAZUU+cz5
wGdJHju/UCwWs55ed5hrdQVLncGmNLtY870ZAnYPo/mbcihp1SK9KjnObeexwg4I
1n4t3/QyGS3ly0Ii4qXIgfM4PWhKxacDleZO3L3flw2j1f9APFkQ++9YuXhVYnhU
JpMEhfKBJ0dXE9DGIj5xe2N/cnlicXLBztYpi8dbVIvlRtrOBwSUsh9v8sv0wz+G
jtxVNYiJ0KH1z9xHODN/L5AVQh0T7OLiH1h5cQp8BsBc8s8H5RTNZYJ1NiJc7wFt
1SVSiDasqYm5pVIBLhts
=Xo1H
-----END PGP SIGNATURE-----

--kWdmfhApc4uqsGupIt5PDlxHoTOipIhfQ--