curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Designing a runtime-loaded CURL TLS provider

From: Matthew Whitehead <MWHITEHEAD_at_uk.ibm.com>
Date: Thu, 9 Feb 2017 16:36:06 +0000
> That's a bit of an unusual requirement, I think.
 
We ship a TLS provider with our product (IBM MQ) which happens to be GSKit, so there are various benefits to cURL re-using that TLS provider rather than an arbitrary one.
 
> You'll have a long row
> to hoe to try to convince this list that adding this kind of run-time linking
> back into libcurl is a good idea.
 
That's understandable, especially if it's caused problems with LDAP in the past. However the approach would leave the existing link-time TLS providers unaffected and would simply be an alternative means of implementing a TLS provider.
 
> If you link your shim into its own static library (that exports a GSKit-like
> API) then you could just point libcurl to the shim instead of the real GSKit.
 
That's certainly something for us to consider and it might be possible to achieve the requirements I've listed by going that route. We do get other tangential benefits from having such a thin TLS layer. We have the ability to implement our own TLS behaviour that might never be contributed back to cURl, and we're able to minimise the time we spend in cURL before control is back in our code so for example we can log/trace TLS flows and diagnostics using our own mechanisms.
 
Matt Whitehead
 
 
----- Original message -----
From: Dan Fandrich <dan@coneharvesters.com>
Sent by: "curl-library" <curl-library-bounces@cool.haxx.se>
To: curl-library@cool.haxx.se
Cc:
Subject: Re: Designing a runtime-loaded CURL TLS provider
Date: Mon, Feb 6, 2017 9:42 PM
 
On Mon, Feb 06, 2017 at 09:49:05AM +0000, Matthew Whitehead wrote:
> This is a general discussion topic relating to a project we're currently using
> curl for. If I've used the wrong mailing list for that sort of discussion
> please let me know.

Nope, it's the right one.

> We build curl to use for HTTP & FTP support but we're now looking to extend
> this to use HTTPS/FTPS. The TLS provider has to be GSKit but for a few
> reasons we don't want to build with USE_GSKIT support. Reasons for not wanting
> to build with USE_GSKIT are:

That's a bit of an unusual requirement, I think.

>  - We'd like control over which version of GSKit is loaded and where it is
> loaded from.
>  - We don't require users to install GSKit so we'd like to have more control
> over the behaviour of curl if it tries to find the GSKit libraries and can't.
>  - We already have libraries that manage the loading and unloading of GSKit,
> including handling the differences on various platforms.
>  - The current implementation in gskit.c only supports OS400.
>  
> Our current approach is to implement a generic, very thin curl TLS provider
> that we pass function pointers to before global_init. In the thin TLS provider
> we implement the various TLS functions (Curl_genssl_init, Curl_gensll_connect,
> Curl_genssl_cleanup etc.), each of which calls the associated function pointer,
> for example:
>  
> int Curl_genssl_init(void)
> {
>   return (sslProviderFPs.Curl_generic_ssl_init == NULL ?
>           1 : sslProviderFPs.Curl_generic_ssl_init());
> }
>  
> The concrete implementation is in Curl_generic_ssl_init() {...}  et al, which
> calls our existing libraries to load GSKit, fail cleanly if it isn't installed,
> and make the relevant GSKit calls if it is.
>  
> This may seem a little convoluted but it's a solution that satisfies the
> requirements above. We're looking for feedback and general discussion on our
> approach and a view to whether this is something that could be contributed back
> to the project.

It is a bit convoluted. curl used a similar approach in the past to load the
LDAP libraries, and it's caused us trouble. Eventually, we ripped that out and
switched to the traditional link-time binding for LDAP. You'll have a long row
to hoe to try to convince this list that adding this kind of run-time linking
back into libcurl is a good idea.

It seems to me you could implement this without any changes to libcurl, though.
If you link your shim into its own static library (that exports a GSKit-like
API) then you could just point libcurl to the shim instead of the real GSKit.
The shim could do whatever it wants and libcurl wouldn't be the wiser.

>>> Dan
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-02-09