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: [Feature Suggestion] Selectively ignore TLS errors
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ray Satiro via curl-users <curl-users_at_cool.haxx.se>
Date: Tue, 2 Feb 2021 16:40:17 -0500
On 2/2/2021 12:59 PM, Ryan via curl-users wrote:
> I ran into a situation today where I needed to curl against a web
> service, outside my control, with an expired SSL certificate. Using
> curl -k works, but is very heavy handed.
>
> This ball gets dropped here and there in production environments.
> Allowing curl to handle this situation gracefully would allow much
> cleaner emergency interim responses that still preserve most of the
> security guarantees of the model.
>
> I examined wget and openssl s_client, and as far as I can tell,
> neither of them offers an option like this.
>
> Suggestions about how to implement it:
>
> 1. --disregard-tls-errors N[,...] to ignore specific TLS subsystem
> errors by ID. Error 557 is "certificate expired", but there may be
> others it makes sense to ignore as well, and you could specify a comma
> separated list to ignore more than one.
>
> 2. --tls-expiry-grace-period T to implement a grace period. It's
> special purpose to this one type of error, but more powerful than the
> general solution above: you could specify an interval, and it would
> consider the certificate valid as long as you were less than that
> interval past the expiration date. This would make it easy to apply a
> time limited fix, e.g., --tls-expiry-grace-period 24h, keeping things
> running while the certificate gets updated.
>
> 3. Maybe there's a better way to do this that I'm not thinking of?
Not a better way but a workaround could be --pinnedpubkey. [1] Refer to
PUBLIC KEY EXTRACTION section in CURLOPT_PINNEDPUBLICKEY.
[1]: https://curl.se/docs/manpage.html#--pinnedpubkey
[2]: https://curl.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2021-02-02
Date: Tue, 2 Feb 2021 16:40:17 -0500
On 2/2/2021 12:59 PM, Ryan via curl-users wrote:
> I ran into a situation today where I needed to curl against a web
> service, outside my control, with an expired SSL certificate. Using
> curl -k works, but is very heavy handed.
>
> This ball gets dropped here and there in production environments.
> Allowing curl to handle this situation gracefully would allow much
> cleaner emergency interim responses that still preserve most of the
> security guarantees of the model.
>
> I examined wget and openssl s_client, and as far as I can tell,
> neither of them offers an option like this.
>
> Suggestions about how to implement it:
>
> 1. --disregard-tls-errors N[,...] to ignore specific TLS subsystem
> errors by ID. Error 557 is "certificate expired", but there may be
> others it makes sense to ignore as well, and you could specify a comma
> separated list to ignore more than one.
>
> 2. --tls-expiry-grace-period T to implement a grace period. It's
> special purpose to this one type of error, but more powerful than the
> general solution above: you could specify an interval, and it would
> consider the certificate valid as long as you were less than that
> interval past the expiration date. This would make it easy to apply a
> time limited fix, e.g., --tls-expiry-grace-period 24h, keeping things
> running while the certificate gets updated.
>
> 3. Maybe there's a better way to do this that I'm not thinking of?
Not a better way but a workaround could be --pinnedpubkey. [1] Refer to
PUBLIC KEY EXTRACTION section in CURLOPT_PINNEDPUBLICKEY.
[1]: https://curl.se/docs/manpage.html#--pinnedpubkey
[2]: https://curl.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2021-02-02