I have pushed the following commit to implement this:

https://src.fedoraproject.org/rpms/curl/c/0480ac07

... and verified with gdb that the following command:

    curl -svo/dev/null https://...

... really calls:

    SSL_CTX_set_cipher_list (..., "PROFILE=SYSTEM")

In any case, a review would be appreciated!

Thank you. The patch looks good to me. A comment on the upstream code is that at least with newer openssl versions DEFAULT may be a better option to use.

Thanks for review!

Could you please refer to some official statement about the OpenSSL's DEFAULT, preferably with precise info about the minimal version of OpenSSL that supports it?

I can prepare an upstream PR to get it fixed.  But upstream needs to support older versions of OpenSSL, too.  So it will most likely end up with some code conditioned by the version (and supported features?) of OpenSSL...

I'm not sure if there so official statement or so, its just that I see that default is now being maintained more agressively than before. For example:

commit c84f7f4a7405d69be4227d4766290b0950122b3c
Author: Matt Caswell <matt>
Date:   Tue Sep 29 11:14:35 2015 +0100

    Change the DEFAULT ciphersuites to exclude DES, RC4 and RC2
    
    This patch updates the "DEFAULT" cipherstring to be
    "ALL:!COMPLEMENTOFDEFAULT:!eNULL". COMPLEMENTOFDEFAULT is now defined
    internally by a flag on each ciphersuite indicating whether it should be
    excluded from DEFAULT or not. This gives us control at an individual
    ciphersuite level as to exactly what is in DEFAULT and what is not.
    
    Finally all DES, RC4 and RC2 ciphersuites are added to COMPLEMENTOFDEFAULT
    and hence removed from DEFAULT.


Adding Tomas in case I'm wrong in that.

Yes, the OpenSSL upstream currently maintains the default as reasonably secure without breaking compatibility. So at least with current versions of openssl it should not be necessary to call the SSL_CTX_set_cipher_list() at all unless the user explicitly sets it. Note that the Fedora OpenSSL is patched in a way that when the SSL_CTX_set_cipher_list() is not called at all the system cipher list is used. With upstream openssl build not calling the SSL_CTX_set_cipher_list() is equivalent to calling it with "DEFAULT" as the cipher string.

Tomas, thanks for the info!  But you answered my questions only partially.  curl upstream currently supports OpenSSL 0.9.7 and newer.  How can one reliably check whether skipping SSL_CTX_set_cipher_list() is the correct thing to do for a given build of OpenSSL?

Which build-time/run-time check do you recommend for this purpose?

I would simply skip it during build time for OPENSSL_VERSION_NUMBER >= 0x10002000 that means any currently upstream-maintained OpenSSL version.

(In reply to Tomas Mraz from comment #7)
> I would simply skip it during build time for OPENSSL_VERSION_NUMBER >=
> 0x10002000 that means any currently upstream-maintained OpenSSL version.

Upstream pull request:

https://github.com/curl/curl/pull/1846

(In reply to Tomas Mraz from comment #7)
> I would simply skip it during build time for OPENSSL_VERSION_NUMBER >=
> 0x10002000 that means any currently upstream-maintained OpenSSL version.

Upstream says that, under certain circumstances, OpenSSL 1.0.2 can negotiate ciphers that cannot be used for HTTP/2, which would cause a regression in libcurl:

https://github.com/curl/curl/pull/1846#discussion_r136252573

Tomas, could you please review the above statement?

Will it help if we use OpenSSL 1.1 in the condition instead?

I added a comment to the github. Imho using the @STRENGTH is incorrect anyway and the cipher list for HTTP/2 should be properly reduced at the server side and not at the client side.

But yes, using the library/system default only on OpenSSL 1.1 and newer is probably reasonable.

upstream commit:

https://github.com/curl/curl/commit/curl-7_55_1-151-gea142a8