[OpenSSL compatibility]: 5.6.6 and/or v5.6.6-stable-564-g3129e29a1 do not fill int pointed to by 2nd argument to SSL_CIPHER_get_bits(sc, &bitsalg); about wolfssl

[anhu]

Hi @mandree,

My name is Anthony and I am a member of the wolfSSL team. Can you please let me know what configuration flags you are using?

*alg_bits is set if you have OPENSSL_ALL defined. If you use configure , add --enable-opensslall .

Can you also please let us know a bit about yourself and your project? For example, Where are you located? Are you using wolfSSL in a personal, academic or professional project? Are there any institutions associated with this project? What are you trying to achieve? We love knowing about how people are using our code. Please feel free to share whatever you comfortable with.

Warm regards, Anthony

[mandree]

Hi Anthony, this is a finding I've had with the open-source fetchmail project (https://www.fetchmail.info/ or https://gitlab.com/fetchmail/fetchmail on the legacy_6x branch) that I maintain and where wolfSSL might be easier to link to license-wise whilst still supporting TLS v1.3.

The most recent I'd tested is wolfSSL from said git commit (see initial report, above) with
a sub-directory to build and then:

CONFIG_SHELL=/bin/sh /bin/sh ../configure -C --enable-context-extra-user-data --enable-debug --enable-opensslall --enable-harden --prefix=/opt/wolfssl CFLAGS='-O2 -DOPENSSL_COMPATIBLE_DEFAULTS -g'

I am running this with wolfSSL 5 against two sites, once forcing TLSv1.2, once forcing TLSv1.3, and get:

Mar 30 15:50:46 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256/-9999 secret/processed bits
Mar 30 15:50:46 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 128/-9999 secret/processed bits
Mar 30 15:50:47 fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/-9999 secret/processed bits
Mar 30 15:50:47 fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_128_GCM_SHA256, 128/-9999 secret/processed bits

Compare this with an OpenSSL 3.1.1 (probably with some patches) provided for Fedora Linux:

fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-ECDSA-CHACHA20-POLY1305, 256/256 secret/processed bits
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits

Example code - I already initialize the output field to -9999 here to mark it's not being dealt with - and "garbage" might be whatever we find on the stack, and I previously saw that and worked around it in fetchmail.

        if (outlevel >= O_VERBOSE) {
            SSL_CIPHER const *sc;
            int bitsalg = -9999, bitsused; /* initialize bitsalg to avoid picking up random garbage with WolfSSL, which does not fill this, as of 5.6.6 */

            const char *vers;

            vers = SSL_get_version(_ssl_context[sock]);

            sc = SSL_get_current_cipher(_ssl_context[sock]);
            if (!sc) {
                report (stderr, GT_("Cannot obtain current SSL/TLS cipher - no session established?\n"));
            } else {
                bitsused = SSL_CIPHER_get_bits(sc, &bitsalg);
                report(stdout, ("SSL/TLS: using protocol %s, cipher %s, %d/%d secret/processed bits\n"),
                        vers, SSL_CIPHER_get_name(sc), bitsused, bitsalg);
            }
        }