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 flags to SChannel cred
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ray Satiro via curl-library <curl-library_at_cool.haxx.se>
Date: Sun, 28 Feb 2021 16:34:46 -0500
On 2/28/2021 4:14 PM, Morten Minde Neergaard via curl-library wrote:
> At 17:11, Sat 2021-02-27, Ray Satiro via curl-library wrote:
>> On 2/26/2021 2:56 PM, Morten Minde Neergaard via curl-library wrote:
> [...]
>>> The first thing that came to mind would be to add an option
>>> CURLOPT_SSL_BACKEND_FLAGS where each backend could use these flags as
>>> desired. The implementation-specific part of the patch would be like
>>> this for SChannel:
>>>
>>> --- a/lib/vtls/schannel.c
>>> +++ b/lib/vtls/schannel.c
>>> _at__at_ -557,6 +557,8 _at__at_ schannel_connect_step1(struct Curl_easy *data, struct connectdata *conn,
>>> "names in server certificates.\n"));
>>> }
>>> + schannel_cred.dwFlags |= SSL_CONN_CONFIG(backend_flags);
>>> +
>>> switch(conn->ssl_config.version) {
>>> case CURL_SSLVERSION_DEFAULT:
>>> case CURL_SSLVERSION_TLSv1:
> [...]
>> I've proposed two PRs to address the auto credentials issue. One would leave
>> auto credentials as the default and add an option to disable it [1], and the
>> other would disable auto credentials as the default (breaking change) and
>> add an option to enable it [2]. Please take any discussion about it to the
>> latter PR.
> Cool, agree with the change. Since I'm not too familiar with the libcurl
> code base, I'd hardly call my looking at the code a review, but gave it
> a try nonetheless =)
>
>> Regarding strong ciphers, CURLOPT_SSL_CIPHER_LIST [3] (--ciphers for the
>> curl tool [4]) can be used with Schannel to set some algorithms but unlike
>> other SSL backends it's relatively limited without ciphersuite support or
>> umbrella terms like "USE_STRONG_CRYPTO". We would consider a patch for that
>> to signal strong crypto.
> To be clear, you're suggesting this should be possible?
>
> curl_easy_setopt(curl, CURLOPT_SSL_CIPHER_LIST, "USE_STRONG_CRYPTO");
>
> ... and that would also be possible to combine with the current ALGID
> stuff? Not that it's a particularly sane use case, but would this be
> acceptable?
>
> curl_easy_setopt(curl, CURLOPT_SSL_CIPHER_LIST,
> "CALG_RSA_SIGN:CALG_DH_EPHEM:CALG_AES_256:CALG_SHA_384:USE_STRONG_CRYPTO");
Looks fine to me. Older versions should (and already will) error if the
term is not supported. For example,
> curld --ciphers "USE_STRONG_CRYPTO" https://google.com
curl: (59) Unable to set ciphers to passed via SSL_CONN_CONFIG
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-02-28
Date: Sun, 28 Feb 2021 16:34:46 -0500
On 2/28/2021 4:14 PM, Morten Minde Neergaard via curl-library wrote:
> At 17:11, Sat 2021-02-27, Ray Satiro via curl-library wrote:
>> On 2/26/2021 2:56 PM, Morten Minde Neergaard via curl-library wrote:
> [...]
>>> The first thing that came to mind would be to add an option
>>> CURLOPT_SSL_BACKEND_FLAGS where each backend could use these flags as
>>> desired. The implementation-specific part of the patch would be like
>>> this for SChannel:
>>>
>>> --- a/lib/vtls/schannel.c
>>> +++ b/lib/vtls/schannel.c
>>> _at__at_ -557,6 +557,8 _at__at_ schannel_connect_step1(struct Curl_easy *data, struct connectdata *conn,
>>> "names in server certificates.\n"));
>>> }
>>> + schannel_cred.dwFlags |= SSL_CONN_CONFIG(backend_flags);
>>> +
>>> switch(conn->ssl_config.version) {
>>> case CURL_SSLVERSION_DEFAULT:
>>> case CURL_SSLVERSION_TLSv1:
> [...]
>> I've proposed two PRs to address the auto credentials issue. One would leave
>> auto credentials as the default and add an option to disable it [1], and the
>> other would disable auto credentials as the default (breaking change) and
>> add an option to enable it [2]. Please take any discussion about it to the
>> latter PR.
> Cool, agree with the change. Since I'm not too familiar with the libcurl
> code base, I'd hardly call my looking at the code a review, but gave it
> a try nonetheless =)
>
>> Regarding strong ciphers, CURLOPT_SSL_CIPHER_LIST [3] (--ciphers for the
>> curl tool [4]) can be used with Schannel to set some algorithms but unlike
>> other SSL backends it's relatively limited without ciphersuite support or
>> umbrella terms like "USE_STRONG_CRYPTO". We would consider a patch for that
>> to signal strong crypto.
> To be clear, you're suggesting this should be possible?
>
> curl_easy_setopt(curl, CURLOPT_SSL_CIPHER_LIST, "USE_STRONG_CRYPTO");
>
> ... and that would also be possible to combine with the current ALGID
> stuff? Not that it's a particularly sane use case, but would this be
> acceptable?
>
> curl_easy_setopt(curl, CURLOPT_SSL_CIPHER_LIST,
> "CALG_RSA_SIGN:CALG_DH_EPHEM:CALG_AES_256:CALG_SHA_384:USE_STRONG_CRYPTO");
Looks fine to me. Older versions should (and already will) error if the
term is not supported. For example,
> curld --ciphers "USE_STRONG_CRYPTO" https://google.com
curl: (59) Unable to set ciphers to passed via SSL_CONN_CONFIG
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-02-28