[exim-dev] Exim OCSP stapling

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Phil Pennock
Datum:  
To: Jeremy Harris
CC: exim-dev
Alte Treads: Re: [exim-dev] SMTP PRDR; Exim 4.82
Betreff: [exim-dev] Exim OCSP stapling
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.

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?

Thanks,
-Phil