[Feature] Add support for TLS 1.3

[banjaxedben]

Motivation

At the moment (v1.9.10), when I enable SSL/TLS, the client seems to use TLS version 1.2 by default. TLS 1.3 (RFC 8446) was published in 2018, and offers multiple improvements.

Detailed design

At the moment there is a binary toggle to disable or enable TLS. I suggest providing 3 radio buttons:

• Disabled
• TLS 1.2
• TLS 1.3

[ysfscream]

@banjaxedben Hi.

Thank you for pointing this out. You are correct; this is the first time we have recognized this issue. We greatly appreciate your contribution and attention to our project. We plan to support this feature in the next version.

[ysfscream]

However, I have one more question regarding TLS support. Our system should automatically adapt between TLS 1.2 and TLS 1.3 based on the client's capabilities.

Could you please describe how you determined that it supports only TLS 1.2? Any specific details or replication steps you provide will help us address this more effectively.

Looking forward to hearing your thoughts.

[banjaxedben]

@ysfscream : Thanks for picking this up. I was having trouble getting my client to connect to my broker, so I ran Wireshark to sniff the packets from the client side. See Wireshark packet capture file attached. It displays the Protocol field as TLSv1.2.

mqttx_issue.zip

What did you mean by "Our system should automatically adapt between TLS 1.2 and TLS 1.3 based on the client's capabilities." I am running the MQTTX desktop app on Windows Server 2022 Datacenter. Do you think I need to do something in the OS to enable TLS 1.3?

In my Wireshark data you can see: Extension: supported_versions (len=5) TLS 1.3, TLS 1.2 which tallies with the code snippet you shared. Does MQTTX support TLS 1.3 already?

Apart from possible Windows configuration issues, I believe that the reason my client won't connect is that I am using EdDSA (ed25519) keys. The TLS client (MQTTX) sends Client Hello, and the TLS server (Mosquitto) sends an Alert and immediately tears down the TCP connection. The error message in the broker log is "no suitable signature algorithm".

In my Wireshark data you can also see that the Client Hello message contains the signature_algorithms extension, with 9 algorithms listed, but none of them include EdDSA. I think this is why the server throws an error: it knows that its own leaf cert contains an ed25519 key, so the signature_algorithms supported by the client aren't going to work.

According to RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3) I need ed25519 (0x0807) to be listed.

Note that RFC 8422 is titled "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier". It seems to suggest that EdDSA can be supported in TLSv1.2.

I have 2 options:

1. stay with TLS 1.2 but add support for ed25519 somehow.
2. upgrade to TLS 1.3 and hope that ed25519 just works!

[ysfscream]

1. When I mentioned, "Our system should automatically adapt between TLS 1.2 and TLS 1.3 based on the client's capabilities," I meant that during the TLS handshake, our system will automatically select the highest TLS version supported by both the client and the server for communication.

2. Just to let you know, MQTTX already supports TLS 1.3, I think 🤔. So, you don't need any particular setup for ed25519 if you are using TLS 1.3, as it natively supports the EdDSA algorithm, including ed25519.

3. Please ensure that your system environment and network configurations are updated and set to support TLS 1.3. This typically involves checking for security updates in your operating system and application settings.

I'm hoping it's helpfulp you.

[banjaxedben]

I tried using the openssl s_client command-line utility, and it works fine if I use the -tls1_3 option to force TLS version 1.3. See Wireshark capture attached demonstrating the successful TLS 1.3 handshake.

s_client_1.3.zip

As expected, the signature_algorithms extension in the Client Hello message now includes ed25519 (0x0807).

So my question becomes: if my client system environment and network configurations are able to support TLS 1.3, why doesn't MQTTX use it?

Also, even if MQTTX was able to somehow "automatically adapt between TLS 1.2 and TLS 1.3 based on the client's capabilities", I suggest that the UI could be improved to provide more control to the user. The openssl s_client is an example of a client that allows the user to enable or disable specific TLS versions. The mosquitto command-line clients also provide a --tls-version option.

[ysfscream]

YES, this is also a good option for users. Based on the Node.js documentation, we should be able to implement it. We will try in the next version.

https://nodejs.org/docs/v20.12.1/api/tls.html#tlscreatesecurecontextoptions

Thank you for your suggestion.