RE: Adding OCSP Features to Curl

From: VanL via curl-library <curl-library_at_cool.haxx.se>
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
when
> a connection is rejected

We can take these as requirements.

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

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
application.

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
caching.
 - 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
that
> 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
first)
> - 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!

Thanks,
Van

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

This message and any attachments may contain privileged or confidential
information.
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.

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-04-23