Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-99368

TLS handshake fails due to incorrect cipher handling (Secure Transport macOS backend)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P1: Critical
    • Resolution: Fixed
    • Affects Version/s: 6.2.2, 6.2.3
    • Fix Version/s: None
    • Component/s: Network: SSL
    • Labels:
      None
    • Environment:
      macOS 12.1.0
      M1 2020 MacBook Pro 13"
      Prebuilt Qt 6.2.2 with the Secure Transport TLS backend
    • Platform/s:
      macOS

      Description

      This is a regression after upgrading from Qt 5.15.2 to 6.2.2.

      When I send a QNetworkRequest to https://www.netlify.com (or any other site hosted on Netlify) with the Secure Transport TLS backend on an M1 Mac, it fails with a QNetworkReply::RemoteHostClosedError.

      Observations:

      • Netlify supports none of the ciphers from request.sslConfiguration().supportedCiphers(). This makes the handshake fail.
      • However, Secure Transport has support for the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphers that Netlify supports.
      • If I set request.sslConfiguration().ciphers() to an empty QList before sending the request, the request goes through without any errors. Wireshark tells me that it uses one of the two aforementioned ciphers from Secure Transport.
        QSslConfiguration config = request.sslConfiguration();
        config.setCiphers(QList<QSslCipher>());
        request.setSslConfiguration(config);
        
      • This means that Qt 6.2.2 seems to actively prevent Secure Transport from using all available ciphers unless the request's QSslConfiguration has an empty cipher list.
      • The request worked fine on Qt 5.15.2 without the aforementioned workaround.

      This is really unfortunate because

      • Netlify hosts hundreds of thousands of websites
      • While Netlify was quick to drop support for weaker ciphers, other sites will at some point also drop support for the weak ciphers that Qt seems to rely on when connecting to them through the Secure Transport backend

       

      I've attached a minimal reproduction example that sends GET requests to https://www.google.com and https://www.netlify.com with and without the aforementioned fix.
      It compiles on both Qt 5.15.2 and 6.2.2 and illustrates the regression.

       

      Here's the output on Qt 6.2.2:

      Url: "https://www.google.com"
      Ciphers cleared: false
      Status code: 200
      Error: QNetworkReply::NoError
      
      Url: "https://www.netlify.com"
      Ciphers cleared: false
      Status code: 0
      Error: QNetworkReply::RemoteHostClosedError
      
      Url: "https://www.netlify.com"
      Ciphers cleared: true
      Status code: 200
      Error: QNetworkReply::NoError
      

       (Notice the QNetworkReply::RemoteHostClosedError.)

       

      Here's the output on Qt 5.15.2:

      Url: "https://www.google.com"
      Ciphers cleared: false
      Status code: 200
      Error: QNetworkReply::NoError
      
      Url: "https://www.netlify.com"
      Ciphers cleared: false
      Status code: 200
      Error: QNetworkReply::NoError
      
      Url: "https://www.netlify.com"
      Ciphers cleared: true
      Status code: 200
      Error: QNetworkReply::NoError
      

        Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

            Assignee:
            tpochep Timur Pocheptsov
            Reporter:
            nikwen Niklas Wenzel
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes