物联网消息队列后端网络/通信【免费下载链接】mosquittoEclipse Mosquitto - An open source MQTT broker项目地址https://gitcode.com/gh_mirrors/mo/mosquitto点击查看免费下载Eclipse Mosquitto 2.0.12 于 2021 年 8 月 31 日发布是一个面向生产环境的安全与缺陷修复security and bugfix版本。本文以官方发布公告 version-2-0-12-released.md 为骨架逐项拆解本次修复涉及的 DoS 风险、keepalive 强制策略、TLS/PSK 行为修正、持久订阅 ACL 回收等核心问题并结合当前仓库源码src、lib、plugins/dynamic-security说明底层实现与验证依据。读完本文你将能够理解max_keepalive、max_connections、TLS-PSK 等配置在 2.0.12 中的真实行为掌握动态安全插件setDefaultACLAccess命令的正确用法并据此评估自己部署是否需要升级。版本定位为什么 2.0.12 值得关注2.0.x 系列自 2.0.0 起引入了全新的配置模型listener段、插件 API v5 等。2.0.12 不包含新功能而是集中修复了三类问题安全漏洞包括可被远程触发的 CPU 耗尽型 DoS、max_keepalive对老协议失效、默认监听器匿名访问的配置陷阱、持久会话客户端 ACL 回收缺失、重连时 QoS 2 未完成消息绕过 ACL 检查Broker 正确性配置解析越界读、连接计数错误、TLS 证书与 TLS-PSK 共存冲突、mount_point未从出站消息剥离、$share订阅恢复等客户端库与工具链TLS-PSK 强制 PSK 密码套件、线程模式可重启、MOSQ_OPT_SSL_CTX置空、Windows 二进制输出等。从 ChangeLog.txt 的版本演进看2.0.12 的修复密度处于 2.0 系列中期的高频维护期其修复结论大多延续到后续 2.0.x 版本具有长期参考价值。Security 修复详解发布公告共列出 5 项安全修复下面逐项结合源码说明其影响面与修复原理。1. MQTT v5 大量 User-Property 导致 CPU 耗尽DoSAn MQTT v5 client connecting with a large number of user-property properties could cause excessive CPU usage, leading to a loss of performance and possible denial of service. This has been fixed.MQTT v5 的 User Property 是属性名/属性值的键值对列表允许一条消息携带多个属性。若恶意客户端在 CONNECT 包中塞入海量 user-propertyBroker 在 property_broker.c 中对属性逐条解析、校验 UTF-8、写入内存解析成本随属性数量线性乃至超线性增长从而拖垮 Broker 单线程事件循环Mosquitto Broker 的事件处理基于 loop.c 的单线程模型形成拒绝服务。2.0.12 对该路径进行了加固限制解析开销这是 MQTT v5 属性解析类攻击的典型缓解方式。2.max_keepalive现在强制作用于 MQTT v3.1.1 与 v3.1Fixmax_keepalivenot applying to MQTT v3.1.1 and v3.1 connections. These clients are now rejected if their keepalive value exceeds max_keepalive. This option allows CVE-2020-13849 ... to be addressed.这是本版本最值得关注的安全修复之一。max_keepalive是 2.0 新增的配置项用于限制客户端允许使用的最大 keepalive 值防止客户端设置超长 keepalive 从而规避断线检测。配置解析见 conf.cmax_keepalive通过conf__parse_int解析并转为uint16_t默认值为0conf.c即不限制。连接时强制见 handle_connect.c当max_keepalive非零且客户端 keepalive 超过该值或为 0时MQTT v5 客户端Broker 通过 CONNACK 中的MQTT_PROP_SERVER_KEEP_ALIVE属性下发被强制的 keepalive 值客户端必须服从MQTT v3.1.1 / v3.1 客户端协议本身没有服务端下发 keepalive 的机制因此 Broker 直接以CONNACK_REFUSED_IDENTIFIER_REJECTED拒绝连接。CVE-2020-13849 是针对 MQTT v3.1.1 协议自身的拒绝服务问题客户端可声明极大 keepalive 使服务端长期维护无效会话状态。Mosquitto 通过max_keepalive让部署者得以在上层规避该协议级缺陷——这正是发布公告强调 rather than an implementation 的含义。此外max_keepalive还决定了 keepalive 环形缓冲区的规模见 keepalive.c缓冲区大小为max_keepalive * 3 / 2 1默认值约 65535 上限可容纳约 10 分钟以上的 tick 记录降低该值时内存占用随之下降。3. 默认监听器配置陷阱cafile等选项导致匿名远程监听器Using certain listener related configuration options e.g.cafile, that apply to the default listener without defining any listener would cause a remotely accessible listener to be opened that was not confined to the local machine but did have anonymous access enabled, contrary to the documentation. This has been fixed. Closes [#2283].Mosquitto 2.0 的配置模型中未显式定义listener时存在一个隐式默认监听器默认仅绑定本机回环地址。问题在于当用户仅写了cafile、keyfile这类监听器相关选项而未定义任何listener段时旧版本会打开一个不受 localhost 限制、且开启匿名访问的远程可访问监听器与文档承诺的默认行为相悖。2.0.12 修复了该行为使未定义 listener 时的监听器严格保持本机回环访问堵住了可能被远程利用的匿名入口。4. 插件回收 ACL 订阅权限后持久客户端保留旧订阅CVE-2021-34434If a plugin had granted ACL subscription access to a durable/non-clean-session client, then removed that access, the client would keep its existing subscription. This has been fixed.持久会话clean sessionfalse客户端的订阅在断线后保留在 Broker 内存数据库中。旧版本中若 ACL 插件先授权某主题的订阅权限、后又撤销持久客户端的既有订阅不会被清除导致权限回收失效CVE-2021-34434。修复使 Broker 在权限变化后重新评估并移除不再被 ACL 允许的订阅。从源码结构看订阅移除的底层入口是 subs.c 中的sub__remove声明于 mosquitto_broker_internal.h而 plugin_public.c 在插件触发订阅清理时会调用它结合连接建立时 handle_connect.c 调用db__check_acl_of_all_messages定义于 database.c重新检查队列消息的 ACL可以看出 2.0.12 强化了ACL 变化后全链路回收的一致性逻辑。5. 重连时未完成 QoS 2 消息绕过 ACL 检查Incoming QoS 2 messages that had not completed the QoS flow were not being checked for ACL access when a clean sessionFalse client was reconnecting. This has been fixed.持久客户端重连时Broker 需要重放其会话队列中的未确认消息。旧版本对处于 QoS 2 中间状态已收到 PUBLISH 但未完成 PUBREC/PUBREL 流程的消息跳过 ACL 检查攻击者可借由持久会话在权限收紧后仍接收到本应被拒绝的内容。2.0.12 将 ACL 复查覆盖到这些半完成消息修复路径同样关联db__check_acl_of_all_messages的调用时机。Broker 修复详解配置解析越界读Fix possible out of bounds memory reads when reading a corrupt/crafted configuration file. Unless your configuration file is writable by untrusted users this is not a risk. Closes [#567213].conf.c 负责逐行解析配置含conf_includedir目录展开见 conf_includedir.c。畸形/被构造的配置文件可能触发越界内存读取发布公告同时给出风险评估仅当配置文件可被不可信用户写入时才构成实际威胁。修复后解析器对异常输入的处理更稳健。max_connections计数修正Fixmax_connectionsoption not being correctly counted.max_connections属于监听器级配置conf.c默认-1即不限制global_max_connections为全局上限conf.c。计数检查逻辑位于 net.cTCP 连接与 websockets.cWebSocket 连接超过上限时记录日志并拒绝连接。2.0.12 修正了计数不准确导致限制形同虚设的问题。TLS 证书与 TLS-PSK 共存、TLS v1.3 禁用Fix TLS certificates and TLS-PSK not being able to be configured at the same time.Disable TLS v1.3 when using TLS-PSK, because it isnt correctly configured.2.0.12 允许同一监听器同时配置证书认证与 PSK 认证并在使用 TLS-PSK 时禁用 TLS 1.3——因为当时 TLS 1.3 下的 PSK 配置路径未被正确支持强行启用会导致握手行为不确定。mount_point未从出站消息剥离Fix listenermount_pointnot being removed on outgoing messages. Closes [#2244].监听器的mount_point为入站消息附加主题前缀出站方向Broker 向客户端投递应剥离该前缀。2.0.12 修复了剥离缺失导致订阅客户端收到带前缀主题的问题这在桥接bridge与多挂载点拓扑中尤为关键。严格协议合规与测试套件Strict protocol compliance fixes, plus test suite.发布公告明确本次包含协议合规性修正及配套测试。仓库 test/broker 下的 Python 测试矩阵覆盖了 keepalive、会话、订阅恢复等场景例如 01-connect-max-keepalive.py、05-clean-session-qos1.py、02-shared-nolocal.py 等均可作为验证 2.0.12 行为的参考用例。$share共享订阅恢复Fix $share subscriptions not being recovered for durable clients that reconnect.$share/group/filter共享订阅在持久客户端重连后需要从持久化存储恢复。2.0.12 修复了恢复缺失导致共享组失效的问题相关订阅存储逻辑位于 persist_read.c、persist_write.c 与 subs.c。其他 Broker 修复password_file指向目录时 Broker 未退出Closes [#2241]配置错误时以明确错误退出而非挂起。插件配置文档更新Closes [#2286]同步了 plugins/README.md 等文档确保插件 v5 API 的配置说明与实现一致。Client library 修复详解TLS-PSK 强制 PSK 密码套件If a client uses TLS-PSK then force the default cipher list to use PSK ciphers only. This means that a client connecting to a broker configured with x509 certificates only will now fail. Prior to this, the client would connect successfully without verifying certificates, because they were not configured.这是本版本客户端库最重要的行为变更。旧版本中仅配置 PSK 的客户端在未显式设置密码套件时可能与仅配置 x509 证书的 Broker 完成握手但不做任何证书校验形成看似加密、实则不验证对端的伪安全连接。修复后PSK 客户端的默认密码套件被强制为PSK见 net_mosq.c设置psk_client_callback且当tls_ciphers未设置时调用SSL_CTX_set_cipher_list(mosq-ssl_ctx, PSK)。对部署的影响如果客户端用 PSK 连接纯证书 Broker2.0.12 起将直接握手失败——这是符合预期的安全收紧而非回归正确的做法是让双方认证方式对齐。TLS v1.3 与 PSK 的客户端侧禁用与 Broker 侧一致客户端在使用 TLS-PSK 时同样禁用 TLS v1.3避免在不正确配置下使用 TLS 1.3 PSK。线程模式可重新启动Threaded mode is deconfigured when themosquitto_loop_start()thread ends, which allowsmosquitto_loop_start()to be called again. Closes [#2242].mosquitto_loop_start()启动后台线程运行事件循环。旧版本线程结束后内部状态未清理再次调用会失败2.0.12 在线程结束时正确反初始化线程模式使循环可被反复启动/停止相关实现见 loop.c 与 thread_mosq.c。MOSQ_OPT_SSL_CTX可置 NULLFixMOSQ_OPT_SSL_CTXnot being able to be set to NULL. Closes [#2289].MOSQ_OPT_SSL_CTX允许用户注入自定义SSL_CTX见 options.c 的选项处理。修复后该选项可被显式置为 NULL 以清除自定义上下文回到默认 TLS 配置路径。重连时 OS 证书 默认值组合问题Fix reconnecting failing whenMOSQ_OPT_TLS_USE_OS_CERTSwas in use, but none ofcapath,cafile,psk, norMOSQ_OPT_SSL_CTXwere set, andMOSQ_OPT_SSL_CTX_WITH_DEFAULTSwas set to the default value of true. Closes [#2288].MOSQ_OPT_TLS_USE_OS_CERTS使用操作系统证书库与MOSQ_OPT_SSL_CTX_WITH_DEFAULTS组合下若未设置任何显式证书源重连会失败。相关校验位于 net_mosq.c当使用MOSQ_OPT_SSL_CTX时必须设置MOSQ_OPT_SSL_CTX_WITH_DEFAULTS为 true或至少指定cafile/capath/psk之一。2.0.12 修正了该组合下重连失败的问题。Apps 与 Clients 修复mosquitto_ctrl dynsec setDefaultACLAccess修复Fixmosquitto_ctrl dynsec setDefaultACLAccesscommand not working.动态安全插件Dynamic Security通过控制命令管理客户端、角色与 ACL命令分发入口见 control.c。setDefaultACLAccess用于设置匿名/默认访问策略其实现位于 default_acl.c接收acls数组逐项解析acltypepublishClientSend、publishClientReceive、subscribe、unsubscribe与allow布尔值写入data-default_access并触发配置批量保存dynsec__config_batch_save。修复后的正确用法对应 dynamic-security/README.mdmosquitto_ctrl dynsec setDefaultACLAccess subscribe deny mosquitto_ctrl dynsec setDefaultACLAccess publishClientSend allow注意命令由两部分组成命令名setDefaultACLAccess 一个acls数组JSON其中每个元素包含acltype与allow字段mosquitto_ctrl的 CLI 形式如setDefaultACLAccess subscribe deny是其一行的便捷写法。mosquitto_sub/mosquitto_rr的 Windows 二进制输出mosquitto_subandmosquitto_rrnow open stdout in binary mode on Windows so binary payloads are not modified when printing.Windows 下 stdout 默认以文本模式打开会将\n转换为\r\n、并在0x1ACtrl-Z处截断导致二进制 payload 被篡改。2.0.12 使mosquitto_sub与mosquitto_rr以二进制模式打开 stdout保证打印内容与收包一致相关代码见 client/sub_client_output.c 与 client/rr_client.c。-p 8883的 TLS 行为文档化Document TLS certificate behaviour when using-p 8883.客户端命令行-p 8883是假定 TLS的快捷端口见 client/client_shared.c。2.0.12 将该端口下证书校验行为的说明写入文档避免使用者误以为默认安全。Build 修复WITH_TLSno安装失败Closes [#2281]无 TLS 构建下的安装规则缺失已修复。libressl 3.4.0 构建Closes [#2198]适配 libressl 3.4.0 的 API 变化并移除部分多余的条件编译保护。MIPS 上的 printf 格式告警Closes [#2271]修正格式化串消除 32 位 MIPS 构建警告。这些修复与 CMakeLists.txt、config.mk 中的构建开关WITH_TLS、WITH_TLS_PSK等直接相关保证了跨平台、跨 TLS 后端的可构建性。升级建议与验证要点必须升级的场景对外暴露 MQTT v5 端口且允许匿名或弱认证客户端——2.0.12 的 user-property DoS 修复直接影响可用性使用持久会话 ACL 插件含 Dynamic Security——涉及 CVE-2021-34434 的权限回收使用 TLS-PSK 客户端——需要核对证书/PSK 认证方式是否对齐避免升级后握手失败配置了max_keepalive或计划启用——升级后 v3.1.1/v3.1 客户端行为发生预期内变化超限即拒连。回归验证可参考仓库 test/broker 与 test/lib 下的测试矩阵重点覆盖 keepalive 强制如 01-connect-max-keepalive.py、持久订阅恢复、TLS-PSK 握手失败路径。文档核对max_keepalive、max_connections、mount_point、cafile等配置的语义以 mosquitto.conf 与 man/mosquitto.conf.5.xml 为准2.0.12 的文档同步已包含插件配置与 TLS 行为说明。总结Mosquitto 2.0.12 虽然只含安全与缺陷修复但其覆盖面横跨 Broker 连接处理、协议合规、TLS 安全边界、持久会话一致性与客户端库生命周期管理。对于任何运行 2.0.0–2.0.11 的部署尤其是暴露公网或依赖 ACL 插件的场景2.0.12 都是一次低风险、高收益的升级。赞分享物联网消息队列后端网络/通信【免费下载链接】mosquittoEclipse Mosquitto - An open source MQTT broker项目地址https://gitcode.com/gh_mirrors/mo/mosquitto点击查看免费下载相关推荐Mosquitto 2.0.15 发布详解安全修复、Broker 关键缺陷与客户端库改进全解析Mosquitto 2.0.15 发布详解安全修复、Broker 关键缺陷与客户端库改进全解析 本文基于官方发布公告与仓库源码系统梳理 Mosquitto后端消息队列消息路由Mosquitto 2.0.13 发布Broker 与客户端库关键缺陷修复全解析Mosquitto 2.0.13 发布Broker 与客户端库关键缺陷修复全解析 Mosquitto 2.0.13 是 Eclipse Mosquitto 在后端消息队列消息路由Eclipse Mosquitto 1.0.3 发布详解Broker 与客户端库关键缺陷修复剖析Eclipse Mosquitto 1.0.3 发布详解Broker 与客户端库关键缺陷修复剖析 导读 本文基于 Mosquitto 官方博客的 1.0.3后端消息队列消息路由上一篇基于Clean Architecture的Go2 ROS2 SDK企业级四足机器人二次开发实战指南下一篇终极指南喜马拉雅FM音频下载器3分钟掌握跨平台免费下载技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考