curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

RE: Adding OCSP Features to Curl

From: VanL via curl-library <>
Date: Fri, 23 Apr 2021 16:31:03 -0500

Great to hear it. A few responses inline:

> If I would add something already now to your little "requirement spec" it
would probably be:
> - cutomizable timeout for the OCSP response for when someone drops all the
> packets to that server
> - possibly an option of how to act on such time-outs (abort or continue)
> - decent error reporting so that users can figure out what went wrong
> a connection is rejected

We can take these as requirements.

> Qeustions:
> - Are you thinking memory-only cache for the OCSP responses or on-disk

The cache could be implemented as a runtime cache or also a persistent
cache. One approach for the interface could be:
 - CURLOPT_SSL_VERIFYCACHING. Pass 1 to enable runtime caching of OCSP
responses. Pass 0 to disable OCSP caching.
 - CURLOPT_SSL_VERIFYCACHING_LOAD. Pass a data structure to inject a
starting cache.
 - CURLINFO_SSL_VERIFYCACHING_GET. Get a data structure of the cache that
can be saved off.
This would allow the persistent cache to be implemented by the user

Another approach for the interface could be:
 - CURLOPT_SSL_VERIFYCACHING. Pass 1 to enable runtime caching of OCSP
responses. Pass 2 to enable persistent caching. Pass 0 to disable OCSP
 - CURLOPT_SSL_VERIFYCACHING_DIR. Pass a directory to store the OCSP cache
into. Pass NULL to disable persistent caching.
This would have the OCSP persistent caching implemented within Curl.

Thoughts on whether one approach or another would be preferable for curl?

One other possibility would be full chain verification - just looping over
all the intermediate certificates as well.

With regard to your further items:

> Challenges I think you might find in your road to landing this:
> - tests - I propose you try to write this with functions that can be
> unit-tested
> - don't bury yourself in a single TLS library's ways of doing things so
> there's a chance for other TLS backends to follow suit later on
(because I
> just presume you'll aim at doing this work for a single TLS library
> - needless to say perhaps, but everything needs to be done non-blocking
> - For the OCSP caching, will you parse HTTP caching headers for that?
> - Considered a CURL_LOCK_DATA_OCSP to share OCSP details between easy
> handles?

We haven't thought about these yet, but will. As a practical matter, we will
start with OpenSSL.

> - This is a rather big work. Try to split it up so that commits can be
> reviewed without require super humans to do it.

We will do our best!


Van Lindberg
OSPOCO: Open Source Program Office as a Service | 210.201.2024

This message and any attachments may contain privileged or confidential
All applicable rights and privileges, including attorney-client privilege,
are reserved and
asserted. If you are not the intended recipient or believe that you have
received this
communication in error, please do not print, copy, share, or otherwise use
the information.

Received on 2021-04-23