Client complains about certificate not matching hostname after updating to 1.4

[Tremolo4]

Description

I just updated my client from 1.3.4 to 1.4.287. I only read about the installer weirdness afterwards, so I uninstalled both from the Windows settings and then installed 1.4.287 again. My server still runs on 1.3.4.

When connecting to my TLS-secured server, the client complains about a SHA-1 fingerprint mismatch. It shows two different SHA-1 fingerprints, even though the server certificate has not been changed. The old client connected without complaining, immediately before updating.

The message also states that the host name did not match any of the names in the certificate, which is incorrect. Clicking the "View Certificate" button reveals the correct Common Name in the certificate.

Clicking "Yes" to ignore this works.

To test this further, I have temporarily removed my mumble.sqlite from AppData. Connecting to my server again results in a warning. (Now it is just about the certificate not matching the host name, and not also mismatching SHA-1 fingerprints.)

Steps to reproduce

1. Have a server with valid TLS certificate from Let's Encrypt.
2. Connect to it using client version 1.3.4.
3. Update the client to 1.4.287.
4. Attempt to connect to the same server.

Mumble version

1.4.287

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

No response

Relevant log output

No response

Screenshots

No response

[Krzmbrzl]

Could you share your server's address so that we could try to connect ourselves?

[Tremolo4]

Could you share your server's address so that we could try to connect ourselves?

I'd rather avoid posting it publicly if possible, so I've sent you an email.

[Krzmbrzl]

Thanks. I was able to reproduce the issue. If time allows, I will have a look at this.

[Tremolo4]

Thanks. I was able to reproduce the issue. If time allows, I will have a look at this.

Nice! Let me know if there's more information I can provide.

[Krzmbrzl]

I traced where in the code the SSL verification happens and I am quite certain that the verification itself is done by Qt (Inside the QSslSocket class). We did upgrade the used Qt version between the 1.3 release and the 1.4 one, so based on that I would argue that this is most likely a bug that was introduced in Qt and that we can't really do anything about (other than perhaps upgrade Qt).

Therefore, I'm closing this as an upstream issue.

[Tremolo4]

Thank you for looking into it! The results are concerning.

Note that I'm also getting the "no matching hosts" error message if I install a fresh 1.4 client, not just when upgrading from 1.3. If my understanding is correct, this essentially means that TLS server authentication is broken for v1.4 clients connecting to v1.3 servers. I have not tested connecting to a v1.4 server.

Is my understanding correct?

[Krzmbrzl]

Depending on the version of Qt used, that may indeed be the case.

However, now that I think about this again, the interesting thing about this is that I am using one of the latest Qt versions, whereas the static Windows binary necessarily uses a slightly older Qt version. Therefore, the error would have to have persisted through multiple Qt releases, which is a bit doubtful as one would assume this to be a reasonably severe bug :thinking:

Maybe I'll have to look into this some more after all :thinking:

[Tremolo4]

Sounds reasonable!

My most recent test (2 hours ago) was on Fedora Workstation 37, using the official mumble+qt packages. Back when I opened the ticket, I used the Mumble Windows builds. My server was and is using the official Debian bullseye packages. I'll try to test with some more versions, maybe I'll discover something.