Stapled OCSP responses for intermediate certs

Tue Mar 21 13:20:27 UTC 2023

       Thanks Benjamin . Appreciate your inputs. I checked if TLS
Certificate message could be parsed. The problem is a pre-compiled openssl
binary is being used. And from what I could tell, many of the utilities I'd
need to parse are not exposed to the applications. So I'm not sure if that
can be done without modifying our openssl source and that would lead to
other problems like not being compatible with future releases and
certification problems. Let me know if my understanding about the interface
to applications is wrong.
       An alternative approach I could think of is to route the certificate
verification callback (which is otherwise set through
SSL_CTX_set_cert_verify_cb) to be called as a regular function inside the
OCSP callback. But this would need reconstructing an argument to the cert
chain verification callback - X509_STORE_CTX. While I could fill it up with
relevant information, I was not sure if thats identical and what problems
it could create. WIll start a separate thread for that. But do you think
the overall approach here would be ok?
      It's not clean for sure, but couldn't think of other ways in which we
could do a clean fallback from stapling -> client driven OCSP -> CRL.
Let me know what you think

Thanks
Akshath

On Mon, Mar 6, 2023 at 10:41 PM Benjamin Kaduk <bkaduk at akamai.com> wrote:

> Hi Akshath,
>
> I don't know of any APIs provided by OpenSSL for parsing the Certificate
> message
> (the ones I think you found for the ClientHello are specific to the
> context of the
> client_hello callback I mentioned, and even they leave a fair amount of
> parsing to the caller).
>
> The internal parser code is roughly at
>
> https://github.com/openssl/openssl/blob/master/ssl/statem/statem_clnt.c#L1853
> but extracting it for standalone use would require a fair bit of effort and
> understanding of the wire protocol.  I do recommend using an abstraction
> for counted
> byte buffers akin to the PACKET_* APIs here (or boringssl's CBB APIs) to
> avoid buffer
> overflow attacks when parsing.
>
> -Ben
>
> On Mon, Mar 06, 2023 at 10:05:15PM +0530, Akshath Hegde wrote:
> >    Hi Benjamin,
> >    Thanks a lot for the information. I'm trying out
> >    SSL_CTX_set_msg_callback() now. Are there any parsers available for
> >    extracting contents of Certificate message?. I have been searching
> and I
> >    could see them for ClientHello but not the others.
> >    Thanks
> >    Akshath
> >    On Fri, Mar 3, 2023 at 6:08 AM Benjamin Kaduk <[1]bkaduk at akamai.com>
> >    wrote:
> >
> >      I don't know about (1) offhand, but (inline)
> >
> >      On Thu, Mar 02, 2023 at 05:25:48PM +0530, Akshath Hegde wrote:
> >      >    Hi,
> >      >    I had few questions about OCSP stapling for intermediate
> >      certificates.
> >      >    On the client side I'm adding  "certificate status request"
> >      extension to
> >      >    ClientHello message. For server, Im using an apache httpd
> server
> >      which has
> >      >    OCSP responder details configured in ssl module. THe
> negotiated TLS
> >      >    version is 1.3
> >      >    1)The server has a multi tier cert chain. But it seems to be
> >      sending the
> >      >    OCSP response for only the end entity certificate. Apache
> >      documentation
> >      >    seems to suggest this is expected and multi-stapling is not
> >      supported. Is
> >      >    anyone aware of a http server that supports multi-stapling?
> >      >    2)On the client side, I'm registering for the OCSP response
> >      callback with
> >      >    SSL_CTX_set_tlsext_status_cb.
> >      >    In case of a multi tiered cert chain and OCSP response for each
> >      cert, is
> >      >    this callback called once for each response?, or only one time?
> >      >    If its called only only one time, how are the responses
> accessed?
> >      >    SSL_get_tlsext_status_ocsp_response -> seems to return only one
> >      OCSP
> >      >    response.
> >      >    And I haven't been able to try tis for the lack of
> multi-stapling
> >      support
> >      >    in http server
> >
> >      It looks like it is just called once at the end of processing the
> >      server's first flight.
> >      The API was clearly designed prior to TLS 1.3 and not modernized as
> part
> >      of the TLS 1.3 implementation;
> >      the updates were pretty minimal (see commit
> >      7776a36cfa5853175a858fa32983f22f36513171 that just generalizes
> >      from "process ServerDone" to "process server's first flight").
> >
> >      For TLS 1.3 you only get the response for the end-entity
> certificate; we
> >      specifically ignore the extension for other certificates in the
> chain.
> >
> >      >    3)The OCSP response callback seems to be called after the cert
> >      chain
> >      >    verification callback has ended. Is there any reason for
> this?. The
> >      >    authenticity of OCSP response is established by a different
> chain
> >      (OCSP
> >      >    response -> CA that signed cert), and doesn't need to wait for
> the
> >      server
> >      >    end entity verification?. So instead of CRL, OCSP could have
> been
> >      used
> >      >    during cert chain verification
> >
> >      I did not specifically go dig into the VCS history, but in general
> >      OpenSSL's
> >      callback interfaces are not part of a intentional wholistic design;
> most
> >      were
> >      added as one-offs to meet a specific purpose and they often can
> interact
> >      with
> >      each other in quite unfortunate ways.  On the server side, many of
> the
> >      callbacks are mostly superseded by the "client hello callback" that
> runs
> >      very
> >      early and has well-defined interactions with other callbacks (and
> can
> >      act
> >      before libssl has started processing anything), at the cost of
> needing
> >      to do
> >      more parsing of the data by hand.  That doesn't help you here, of
> >      course; if
> >      you need to see all the OCSP responses you will probably need to
> use a
> >      message
> >      callback (SSL_CTX_set_msg_callback()) in order to get access to the
> >      multi-staple.
> >
> >      -Ben
> >
> > Links:
> > 1. mailto:bkaduk at akamai.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230321/0a2d9cd5/attachment.htm>