On 01/28/2013 11:40 PM, Phil Pennock wrote:
> On 2013-01-28 at 19:25 +0000, Jeremy Harris wrote:
>> I've pushed my work-in-progress branch to tahini, "test_ocsp_staple".
>
> +setup_ocsp_verify(BIO *bp, char *CAfile, char *CApath)
> +{
> + X509_STORE *store;
> + X509_LOOKUP *lookup;
> + if(!(store = X509_STORE_new())) goto end;
> [...]
> + return store;
> + end:
> + X509_STORE_free(store);
> + return NULL;
> +}
>
> The X509_STORE_free() will be called on the non-allocated store. The
> third line of the function body needs to just `return NULL;`. I see
> that this is copy&paste from openssl's apps/apps.c -- we'll need to
> update the file header to acknowledge the code source as it's
> non-trivial and the OpenSSL project has copyright in it.
Yup.
Mind, I'm not right now convinced it's needed; it might be the
correct thing to do is to use the "store" already baked into
the connection context for verifying the cert
( store = SSL_CTX_get_cert_store(ctx); )
I wish the documentation was better. Or even existent.
>
> I'm trying to find docs on `X509_LOOKUP_load_file()` and failing;
> tracing the code, it boils down to OpenSSL crypto/x509/by_file.c
> by_file_ctrl() in the X509_L_FILE_LOAD case of cmd.
>
> I think this code is flawed: if the administrator has configured a
> CApath but not a CAfile, that does not mean to _also_ load the default
> CAfile, and vice versa. This is adding in unwarranted trust anchors and
> is a security flaw, surely? If only one of CAfile and CApath is
> non-null, then the defaults for the other should *not* be loaded!
>
> So as things stand, $SSL_CERT_DIR can be set in the environment, and if
> not set, then for OCSP purposes, all certs in OPENSSLDIR/certs will be
> trusted, even if I've explicitly configured a CAfile. Have I
> misunderstood? That seems insanely dangerous: if I'm verifying an OCSP
> staple, I want to pin the trust anchor for that to be _only_ the CA
> which is expected to be doing the OCSP stapling: no other CA gets to
> verify the staple!
>
> Can you please check on openssl-users about the API usage here before
> taking the code into the master branch of Exim?
Definitely.
--
Jeremy
