[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);

[mandree]

Contact Details

(use Gitlab)

Version

v5.6.6-stable-564-g3129e29a1

Description

Apparently OpenSSL fills in the bits into the int pointed to by the 2nd argument of SSL_CIPHER_get_bits(sc, &i); in addition to returning them. I haven't found this documented for OpenSSL, but it's in use in the wild and appears to, once upon a time, have been a means to reveal weakened algorithms that only used, say 40 out of 128 bits.

Reproduction steps

Use WolfSSL's OpenSSL compatibility layer,
establish a TLS client connection,
have it connect and negotiate a cipher (assuming SSL_CIPHER *sc is extant and initialized properly), then call:

int bits1;
int bits2 = -23;
bits1 = SSL_CIPHER_get_bits(sc, &bits2);

and see bits2 unchanged, whereas OpenSSL 1.1.1, 3.0 or 3.1 would fill in 128 or 256 on my typical AES-encrypting ciphers.

Relevant log output

No response

[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);
            }
        }