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