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.
Feature request: add a libcurl option to register a callback function to modify the per-connection TLS context object
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: John Scott via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 01 Aug 2023 16:05:32 +0000
Hi,
The subject line is a bit of a mouthful, so let me break it down. Since it's what I'm familiar with, I will be discussing this in OpenSSL parlance, but the concept generalizes to other TLS libraries.
Right now, there is CURLOPT_SSL_CTX_FUNCTION which allows registering a callback function to set options on the global SSL_CTX * context object. There is also curl_easy_info()'s CURLINFO_TLS_SSL_PTR which allows accessing the per-connection SSL * context object. However, CURLINFO_TLS_SSL_PTR is not very useful: if you call curl_easy_info() before curl_easy_perform(), odds are the SSL * context object hasn't even been made yet so you can't set up options on it. That's why the ability to register a callback function when the SSL * gets made is necessary.
I tried to hijack CURLOPT_OPENSOCKETFUNCTION and CURLOPT_SSL_CTX_FUNCTION for this purpose and call curl_easy_info() inside the callback functions, but it appears these are too early and that the SSL * doesn't get made yet. If we try it within a CURLOPT_READFUNCTION, that's too late: the TLS handshake will have already been completed. Thus the only way to get this right it seems is if libcurl adds a new type of callback function.
I propose the following:
CURLOPT_TLS_SSL_FUNCTION and CURLOPT_TLS_SSL_DATA, for the callback function and the caller's data that gets passed along verbatim. The callback function can have the following prototype:
CURLcode callback(CURL *restrict, struct curl_tlssessioninfo[restrict static 1], void *restrict);
Here the last argument is the CURLOPT_TLS_SSL_DATA that libcurl passes along verbatim.
My use case for those who are curious: OpenSSL has DANE support built-in, and I'd like to turn it on. This requires accessing the SSL * before the TLS handshake initiates. Note that since it appears c-ares does not have the ability to query DNSSEC status, implementing DANE in libcurl directly might be challenging, as OpenSSL's DANE API makes the caller responsible for fetching the DNS data and checking authenticity. This is the main reason why I'm not putting my effort into implementing proper support.
Thanks for your consideration!
John
Date: Tue, 01 Aug 2023 16:05:32 +0000
Hi,
The subject line is a bit of a mouthful, so let me break it down. Since it's what I'm familiar with, I will be discussing this in OpenSSL parlance, but the concept generalizes to other TLS libraries.
Right now, there is CURLOPT_SSL_CTX_FUNCTION which allows registering a callback function to set options on the global SSL_CTX * context object. There is also curl_easy_info()'s CURLINFO_TLS_SSL_PTR which allows accessing the per-connection SSL * context object. However, CURLINFO_TLS_SSL_PTR is not very useful: if you call curl_easy_info() before curl_easy_perform(), odds are the SSL * context object hasn't even been made yet so you can't set up options on it. That's why the ability to register a callback function when the SSL * gets made is necessary.
I tried to hijack CURLOPT_OPENSOCKETFUNCTION and CURLOPT_SSL_CTX_FUNCTION for this purpose and call curl_easy_info() inside the callback functions, but it appears these are too early and that the SSL * doesn't get made yet. If we try it within a CURLOPT_READFUNCTION, that's too late: the TLS handshake will have already been completed. Thus the only way to get this right it seems is if libcurl adds a new type of callback function.
I propose the following:
CURLOPT_TLS_SSL_FUNCTION and CURLOPT_TLS_SSL_DATA, for the callback function and the caller's data that gets passed along verbatim. The callback function can have the following prototype:
CURLcode callback(CURL *restrict, struct curl_tlssessioninfo[restrict static 1], void *restrict);
Here the last argument is the CURLOPT_TLS_SSL_DATA that libcurl passes along verbatim.
My use case for those who are curious: OpenSSL has DANE support built-in, and I'd like to turn it on. This requires accessing the SSL * before the TLS handshake initiates. Note that since it appears c-ares does not have the ability to query DNSSEC status, implementing DANE in libcurl directly might be challenging, as OpenSSL's DANE API makes the caller responsible for fetching the DNS data and checking authenticity. This is the main reason why I'm not putting my effort into implementing proper support.
Thanks for your consideration!
John
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-08-01