Reconstructing X509_STORE_CTX from SSL object

[Akshath Hegde]

Hi Viktor,

Thanks for the response. I should have phrased it better. What I meant to
say was to "construct x509_store_ctx from the data  in the SSL received in
the OCSP response callback".
Regarding this " What real problem are you actually trying to solve.  How
does doing
something with OCSP solve it?" -> its a business decision. So don't have a
choice there.

I went through parts of openssl code related to this.
a]" Has the validated chain already been constructed
by the time your callback runs" -> The idea is to call the certificate
chain verification callback as a normal function within the OCSP callback.
By callback I mean a custom verification function which ends up calling
X509_verify_cert down the line by setting up certs and crls. So at this
point, we would have access only to the unvalidated peer cert stack. The
certificate verification chain callback though anyway expects the
unvalidated chain itself and is supposed to validate the chain itself. So
it should be as expected. But on the course of checking it, I see when the
callback is invoked by openssl, it does a bunch of pre and post setups. For
example as part of post setup I see it is setting the verification result
and verification chain. I see a problem here if we try to do this at the
application level (We receive precompiled openssl and can't modify that).
Some parts are not exposed at application level, for example verified chain
parameter. There's no way to set it from the application(openssl 1.1.1q),
and the structure itself is opaque and members cant be accessed directly.
And there's a bunch of stuff related to danetls and suiteb algorithms as
part of pre-setup which are again static.
Please correct me if any of the above understanding is incorrect. Being
unable to do these pre and post setups looks to be a bad idea both from
security perspective and keeping it compatible with new openssl versions.
So I felt this wouldnt work. If there's any other way around it, your
inputs would be helpful

b]As an alternative approach, I thought of moving the revocation check
outside the openssl provided X509_verify_cert. We are currently fetching
and setting up the CRL and use the openssl provided X509_verify_cert which
seems to be doing the revocation check with "check_revocation()" function.
If the functionality done by this routing has to be simulated at
application level, again I see they're not exposed to applications. I did
some search to see if there's an openssl api that provides revocation
checking against a cert chain as a standalone routine(that is, excluding
chain building, signature checking, timestamp checking etc). But I wasn't
able to find any. If you have any suggestions on this please let me know

Any inputs on these would be very helpful

Thanks
Akshath




On Tue, Mar 21, 2023 at 9:02 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Tue, Mar 21, 2023 at 07:07:42PM +0530, Akshath Hegde wrote:
>
> > My intention is to call the certificate verification function callback
> as a
> > normal function inside the OCSP callback (the reason why this is done is
> > due to a separate issue with callback ordering)
> > The certificate verification function is set through
> > SSL_CTX_set_cert_verify_cb(), and the callback is of the form
> > int (*cert_verify_cb) (X509_STORE_CTX *, void *)
> >
> > So to be able to call this inside the OCSP callback, I'd need to
> > reconstruct the X509_STORE_CTX argument. I'm not very familiar with
> > openssl internals, so forgive me if this is silly.
>
> There's nothing to "reconstruct" the X509_STORE_CTX in question is an
> ephemeral object, that lives just long enough to perform the certificate
> chain construction, validation and subject identity checks.
>
> The related persistent objects are the X509_STORE, which is loaded with
> the trusted certificates, and X509_VERIFY_PARAM structure which holds
> the identity to check, the "purpose" (sslserver vs. sslclient), and
> various flags.
>
> The X509_STORE_CTX is then initialised with the EE certificate to
> validate, any related untrusted certificates that may help to build the
> chain, the X509_STORE to find trusted issuers and the X509_VERIFY_PARAM
> to tweak the process.
>
> If you want to verify some certificate chain other than the one that
> is verlfied automatically as part of the TLS handshake, you'll need
> to assemble your own X509_STORE_CTX.
>
> > 1)Is it conceptually right to do so?
>
> Hard to say.  Ideally OCSP would be handled automatically internally in
> OpenSSL, once you configure OpenSSL to do so.  If not, perhaps someone
> could be persuaded to contribute better built-in OCSP support.  I am not
> a fan of OCSP (lots of ceremony for little gain IMHO), so I'm not
> volunteering.
>
> > 2)Is it possible to construct x509_store_ctx from ssl?
>
> Wrong question.  You can construct it from a STORE and verification
> parameters and a set of certificates to check.  The SSL handle can
> be queried for the store and the verification paramters.
>
> > 3)I could extract the peer cert chain from SSL through
> > SSL_get_peer_cert_stack() and create a x509_store_ctx.
>
> Timing is everything. Has the validated chain already been constructed
> by the time your callback runs?  Are certificates other than the EE cert
> relevant for OCSP? ... Are you looking at the chain as sent by the peer
> or as validated by OpenSSL, the two may not be the same.
>
> > But this wouldn't be identical to how it's created originally and
> > might lack information. If it's correct to do so and possible, what's
> > the right method to create it?
>
> It sounds to me like you're lost in the concepts.  Which will almost
> certainly mean that whatever you concoct, even if it appears to work may
> not achieve any productive security goals.  Perhaps the best answer is
> to not bother OCSP until you've a better grasp of the fundamentals.
>
> > Do you see any alternative to overall approach?  (For the original
> > problem, please have a look at thread named "Stapled OCSP
> > Response")
>
> What real problem are you actually trying to solve.  How does doing
> something with OCSP solve it?
>
> --
>     Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230410/cf41d7e9/attachment.htm>