what to do about ssl_ca_chain_file [was: Re: [ANNOUNCE] perdition 2.1]

Daniel Kahn Gillmor <[email protected]> Fri, 07 Feb 2014 02:25:02 -0500

Newsgroups	gmane.mail.perdition.user
Message-ID	<[email protected]>

As you can (hopefully) see, i've found the config options for the
patchbomb mercurial plugin and configured it a little bit to make it
easier to send patches :)

I think i covered most of my SSL configuration concerns, but the
following one remains:

On 02/07/2014 12:39 AM, Daniel Kahn Gillmor wrote:
> Another concern: while ca_chain_file is documented as the list of
> intermediate certificates, it appears to be used as a set of certificate
> authorities for verification (via SSL_CTX_load_verify_locations())
> instead of its stated purpose.  ironically, the certificate file itself
> is loaded with SSL_CTX_use_certificate_chain_file(), presumably because
> of OpenSSL's silly API that doesn't make it simple to separate the EE
> cert from the intermediate certs.  treating the ca_chain_file as a list
> of legitimate CAs seems problematic; it's certainly possible for an IMAP
> frontend to offer one CA for its clients to use (e.g. an intermediate
> cert that chains back to a member of the well-known CA cartel) while
> using in-house certificate authorities for the backhaul (outbound)
> links.  By loading the chain_file into the list of verifiers for the
> backhaul links, anyone who compromises the CA used for the frontend
> connections can now compromise the backhaul without perdition noticing.

I'm not sure how to deal with this safely.

One approach could just be to discard the ssl_ca_chain_file option
entirely (maybe warn if the admin sets it), and indicate clearly that
perdition admins need to include the full end entity + intermediate cert
chain in the ssl_cert_file, and the list of root CAs via either
ssl_ca_path or ssl_ca_file.  This is the case currently, so we'd
basically just be deprecating one option.

What we'd lose is the claim that you can store your intermediate certs
in a separate file than your end entity cert; but it doesn't look like
that should work at all right now anyway :/

I'm sure there are other approaches too, though, that i'm not thinking of.

What do you think we should do?

	--dkg

______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users

signature.asc (application/pgp-signature, 1010 B)