Partial SSL algorithm fetching from providers

[Matt Caswell]

On 01/02/2023 21:35, Dr Paul Dale wrote:
> Try the query string: "?provider=myprov".  This is prefer your provider 
> over other implementations.

Just to expand on this - for the above to work you must make sure that 
your provider actually defines the "provider=myprov" property for all 
algorithms that it supplies.

Matt

> 
> 
> Pauli
> 
> On 2/2/23 08:29, Afshin Pir wrote:
>>
>> Hi
>>
>> Let’s assume that I have a custom provider that supports only RSA 
>> signature/verification and I want to use it in an SSL/TLS connection. 
>> But Since SSL/TLS needs other cryptography operation such as symmetric 
>> encryption/decryption and key exchange too, I want to fall-back on 
>> FIPS(or default) module for these operations.
>>
>> I have used a code like this to load my provider and fall-back 
>> provider and connect them to SSL context:
>>
>> lib = OSSL_LIB_CTX_new();
>>
>> defctxnull = OSSL_PROVIDER_load(NULL, "null");
>>
>> OSSL_LIB_CTX_load_config(lib, "prov.cnf");
>>
>> SSL_CTX *ctx = SSL_CTX_new_ex(lib, NULL, method);
>>
>> From the logs inside my provider, I have noticed that my code works as 
>> I want. Signature is done by my provider and rest of operations by my 
>> fall-back provider. But the problem is that I don’t understand how the 
>> fetching of signature algorithm happens here. How is it guaranteed 
>> that my provider’s signature/verification is used rather than 
>> signature/verification that is surely available in fall-back provider 
>> too? I cannot resolve it by query string because if I use a query 
>> string like this:
>>
>> SSL_CTX *ctx = SSL_CTX_new_ex(lib, “provider=myprov”, method);
>>
>> openssl will not match algorithms from fall-back module and since my 
>> provider does not implement everything, I will not be able to use SSL/TLS.
>>
>> Any idea how I can guarantee that only signature/verification of 
>> SSL/TLS happens from my provider?
>>
>> Best Regards,
>>
>> Afshin
>>
>> ------------------------------------------------------------------------
>> This email is confidential and may contain information subject to 
>> legal privilege. If you are not the intended recipient please advise 
>> us of our error by return e-mail then delete this email and any 
>> attached files. You may not copy, disclose or use the contents in any 
>> way. The views expressed in this email may not be those of Gallagher 
>> Group Ltd or subsidiary companies thereof.
>> ------------------------------------------------------------------------
>