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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 23 Apr 2021 23:19:09 +0200 (CEST)
On Fri, 23 Apr 2021, VanL via curl-library wrote:
> We would like to expand Curl's support for OCSP verification beyond OCSP
> stapling to include online OCSP.
> We wanted to get commentary on this as a feature, as well as the proposed
> flow, before creating an issue with a proposed pull request.
Awesome! I was previously in conversations with a customer about OCSP as well,
so I've had a chance to think about this already before.
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
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
Qeustions:
- Are you thinking memory-only cache for the OCSP responses or on-disk too?
- 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?
Proposal:
- This is a rather big work. Try to split it up so that commits can be
reviewed without require super humans to do it.
Good luck!
Date: Fri, 23 Apr 2021 23:19:09 +0200 (CEST)
On Fri, 23 Apr 2021, VanL via curl-library wrote:
> We would like to expand Curl's support for OCSP verification beyond OCSP
> stapling to include online OCSP.
> We wanted to get commentary on this as a feature, as well as the proposed
> flow, before creating an issue with a proposed pull request.
Awesome! I was previously in conversations with a customer about OCSP as well,
so I've had a chance to think about this already before.
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
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
Qeustions:
- Are you thinking memory-only cache for the OCSP responses or on-disk too?
- 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?
Proposal:
- This is a rather big work. Try to split it up so that commits can be
reviewed without require super humans to do it.
Good luck!
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2021-04-23