Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-35579

With WolfSSL server does not chose best TLSv1.3 cipher offered by client

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.6.20, 11.4.4
    • 10.5.29, 10.6.22, 10.11.12, 11.4.6, 11.8.2
    • SSL
    • None
    • Generic Linux binary tarball, or Windows, Install so that WolfSSL is statically compiled in instead of using OpenSSL

    Description

      When using a MariaDB server built against a current version of OpenSSL and connect to it using the command line client from the same version, using encryption, the client and server agree on using TLS v1.3 and TLS_AES_256_GCM_SHA384 as the cipher.

      When doing the same with a generic binary tarball release, or on Windows, so that the server uses WolfSSL instead of OpenSSL TLS v1.3 and TLS13-AES128-GCM-SHA256 is used. The variant with 256bit AES and 384bit SHA is also offered by the client, but the server decides to use the "lesser" alternative.

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          wlad Vladislav Vaintroub added a comment -

          Please provide a wireshark.

          Is this a bug at all? Why is one cipher better than the other cipher? Is the best cipher documented as being the best?

          wlad Vladislav Vaintroub added a comment - Please provide a wireshark. Is this a bug at all? Why is one cipher better than the other cipher? Is the best cipher documented as being the best?
          hholzgra Hartmut Holzgraefe added a comment - - edited

          I'm naively assuming "bigger numbers -> better", so:

          TLS13-AES256-GCM-SHA384 (0x1302)

          better than

          TLS13-AES128-GCM-SHA256 (0x1301)

          Also the order of preference of the client as per the cipher suite list in ClientHello was

          TLS13-AES256-GCM-SHA384 (0x1302)
          		 
          TLS13-CHACHA20-POLY1305-SHA256 (0x1303)  
          TLS13-AES128-GCM-SHA256 (0x1301) 
          TLS13-AES128-CCM-SHA256 (0x1304) 
          ... TLS v1.2 chiphers ...

          Also when enforcing TLS v1.2 the ECDHE-RSA-AES256-GCM-SHA384 variant is chosen, not the ECDHE-RSA-AES256-GCM-SHA384.

          So why does WolfSSL go for the "bigger numbers" variant with TLSv1.2 but the "smaller numbers" variant with TLSv1.3?

          (cipher names in the text being different than in the Wireshark output as WolfSSL follows a different naming convention than OpenSSL and Wireshark, for whatever reason)

          hholzgra Hartmut Holzgraefe added a comment - - edited I'm naively assuming "bigger numbers -> better", so: TLS13-AES256-GCM-SHA384 (0x1302) better than TLS13-AES128-GCM-SHA256 (0x1301) Also the order of preference of the client as per the cipher suite list in ClientHello was TLS13-AES256-GCM-SHA384 (0x1302) TLS13-CHACHA20-POLY1305-SHA256 (0x1303) TLS13-AES128-GCM-SHA256 (0x1301) TLS13-AES128-CCM-SHA256 (0x1304) ... TLS v1.2 chiphers ... Also when enforcing TLS v1.2 the ECDHE-RSA-AES256-GCM-SHA384 variant is chosen, not the ECDHE-RSA-AES256-GCM-SHA384 . So why does WolfSSL go for the "bigger numbers" variant with TLSv1.2 but the "smaller numbers" variant with TLSv1.3? (cipher names in the text being different than in the Wireshark output as WolfSSL follows a different naming convention than OpenSSL and Wireshark, for whatever reason)
          hholzgra Hartmut Holzgraefe added a comment -

          Upstream problem: https://github.com/wolfSSL/wolfssl/pull/7771

          hholzgra Hartmut Holzgraefe added a comment - Upstream problem: https://github.com/wolfSSL/wolfssl/pull/7771
          hholzgra Hartmut Holzgraefe added a comment -

          Looks as if it is basically already fixed on the WolfSSL side, just not released yet

          hholzgra Hartmut Holzgraefe added a comment - Looks as if it is basically already fixed on the WolfSSL side, just not released yet
          wlad Vladislav Vaintroub added a comment - - edited

          Can't reproduce with the latest releases, that contain updated WolfSSL.

          Although, I do not think client preference is mandatory, or any of TLSv1.3 ciphers would be described by the standard as "worse" or "lesser quality" than others. In short, those ciphers are not broken, and breakage is not yet anticipated.

          wlad Vladislav Vaintroub added a comment - - edited Can't reproduce with the latest releases, that contain updated WolfSSL. Although, I do not think client preference is mandatory, or any of TLSv1.3 ciphers would be described by the standard as "worse" or "lesser quality" than others. In short, those ciphers are not broken, and breakage is not yet anticipated.
          hholzgra Hartmut Holzgraefe added a comment -

          The upstream pull request got merged in Nov. 2024, so current WolfSSL releases should have this fixed

          hholzgra Hartmut Holzgraefe added a comment - The upstream pull request got merged in Nov. 2024, so current WolfSSL releases should have this fixed

          People

            wlad Vladislav Vaintroub
            hholzgra Hartmut Holzgraefe
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.