7 Feb
2014
7 Feb
'14
7:25 a.m.
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