| Roger,
Why when TLS 1.1 is deprecated and has been for a while.
TLS 1.1 is deprecated and considered insecure; leaving it enabled increases your attack surface and can break compliance requirements. Main security risksInherent protocol weaknesses: TLS 1.1 (and 1.0) have structural design issues that cannot be fully fixed without moving to newer protocol versions. Legacy cipher suites: Supporting TLS 1.1 typically means supporting older, weaker cipher suites (e.g., CBC modes, smaller keys) and missing modern recommended suites. Known attack classes: Older TLS versions are susceptible to attacks like BEAST and variants of POODLE against CBC-mode ciphers, which can leak or decrypt portions of encrypted traffic under the right conditions. Weak integrity primitives: TLS 1.1 relies heavily on SHA‑1 for handshake integrity, which is considered weak and enables more feasible downgrade or forgery-style attacks compared with TLS 1.2+. Downgrade attack exposure: Just having TLS 1.1 enabled allows an active MitM to try to force clients off stronger protocols (1.2/1.3) onto 1.1, then exploit its weaknesses. Larger configuration attack surface: Maintaining support for TLS 1.1 increases complexity and the chance of misconfiguration (e.g., accidentally permitting very weak ciphers or accepting noncompliant clients).
TLS 1.1 was formally deprecated by the IETF in early 2021, and there is no single universal “end of support” date; vendors are phasing it out on their own timelines. Standards deprecationThe IETF moved TLS 1.0 and 1.1 to Historic status in RFC 8996, published in March 2021, which is the formal protocol deprecation point. From that moment, TLS 1.2+ became the only recommended versions in IETF best‑practice guidance.
Vendor / platform timelines (examples)These are policy dates, not protocol-level dates: Windows: Microsoft is disabling TLS 1.0/1.1 by default starting with Windows 11 and Windows Server Insider Preview builds in 2024; they indicate legacy support “may be removed completely in the future” but do not give a hard OS end-of-support date for 1.1 yet. Azure: Azure’s announced end of support for TLS 1.0/1.1 on its services is August 31, 2025 (extended from an earlier date), after which connections must use TLS 1.2+.
Because end-of-support is vendor‑specific, for any particular product (browser, OS, cloud, appliance) you have to check that vendor’s lifecycle / deprecation notice to get the exact cutoff date.
John
John C. Fowler
jcfowler(at)pacbell.net
858.278.6636
619.606.8502
Respond when you want to, if you want to!
On Jan 27, 2026, at 09:21, Roger Light via mosquitto-dev <mosquitto-dev@xxxxxxxxxxx> wrote:
Hi Greg, There's a big difference between "unencrypted is insecure" and "TLS 1.1 is insecure" - there's no expectation for unencrypted to be secure. I'll see about adding 1.1 support back in, although I would say that TLS 1.2 existed before the mosquitto project existed! Cheers, Roger On Sun, 25 Jan 2026 at 20:10, Greg Troxel via mosquitto-dev <mosquitto-dev@xxxxxxxxxxx> wrote:
I built packages on a staging server and then did a "upgrade packages"
which installed deps and moved mosquitto from 2.0.22 to 2.1.0rc3.
Starting it:
Starting mosquitto.
1769370293: The 'per_listener_settings' option is now deprecated and will be removed in version 3.0. Please see the documentation for how to achieve the same effect.
1769370293: Warning: dhparamfile is no longer required.
1769370293: You are using the 'allow_anonymous' option with 'per_listener_settings true'. Please replace this with 'listener_allow_anonymous'.
1769370293: Info: running mosquitto as user: mosquitto.
but in the logs
Jan 25 14:44:43 foo mosquitto[546]: 1769370283: mosquitto version 2.0.22 terminating
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: mosquitto version 2.1.0 starting
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Config loaded from /usr/pkg/etc/mosquitto.conf.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Bridge support available.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Persistence support available.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: TLS support available.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: TLS-PSK support available.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Websockets support available.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Plugin builtin-security has registered to receive 'basic-auth' events.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Plugin builtin-security has registered to receive 'acl-check' events.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Opening ipv6 listen socket on port 8883.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Opening ipv4 listen socket on port 8883.
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: Error: Unsupported tls_version "tlsv1.1".
Jan 25 14:44:53 foo mosquitto[14275]: 1769370293: mosquitto version 2.1.0 terminating
This particular machine needs to support tlsv1.1 because there are
deployed and non-reachable nodemcu devices that connect via tlsv1.1.
Rereading NodeMCU docs, I may be off; it talks about 1.2. But what
matters to me is what is flashed in a particular device deployed in
2019, that is far away and operational only sometimes. I suspect others
have similar "embedded/deployed stuff" constraints.
Is there a technical reason why omitting tlsv1.1 is necessary in the
code? If it's "that's insecure; you shouldn't do that", then non-TLS
connections should also be rejected. (I'm not objecting to "tls 1.1
isn't allowed if you don't ask for it".)
I put back the two lines to have tlsv1.1 work:
$NetBSD$
--- src/net.c.orig 2026-01-25 09:16:52.000000000 +0000
+++ src/net.c
@@ -446,6 +446,8 @@ int net__tls_server_ctx(struct mosquitto
#endif
}else if(!strcmp(listener->tls_version, "tlsv1.2")){
SSL_CTX_set_options(listener->ssl_ctx, SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1);
+ }else if(!strcmp(listener->tls_version, "tlsv1.1")){
+ SSL_CTX_set_options(listener->ssl_ctx, SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 );
}else{
log__printf(NULL, MOSQ_LOG_ERR, "Error: Unsupported tls_version \"%s\".", listener->tls_version);
return MOSQ_ERR_TLS;
and now it starts ok with my custom config. openssl s_client is able to
connect with TLSv1.1.
And, the good news is that everything else seems to be working. I'll
update other instances and let them run.
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev
_______________________________________________ mosquitto-dev mailing list mosquitto-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev
|
