4、MQTT安全：MQTT协议基础、MQTT over TLS、用户名密码认证、客户端证书认证

好，咱们今天聊聊MQTT安全。说实话，MQTT在物联网里太常见了，几乎成了事实标准。但很多人用MQTT的时候，安全意识还停留在“能用就行”的阶段。我见过太多项目，设备连上Broker就开始裸奔，数据在网络上明文传输，跟在大街上喊密码没什么区别。

这一章，我会带你从MQTT协议的基础开始，一步步把安全机制加进去。从最简单的TLS加密，到用户名密码，再到客户端证书认证。嗯，这些都是我在实际项目中踩过坑、填过坑的经验。

4.1 MQTT协议基础回顾

MQTT，全称Message Queuing Telemetry Transport。说白了，就是一个轻量级的发布/订阅模型。你想想看，设备A发布一条消息到某个主题，设备B订阅了这个主题，就能收到。就这么简单。

MQTT的核心概念其实就三个：

  • Broker：消息的中转站，所有消息都经过它
  • Topic：消息的主题，类似邮件的地址
  • Client：发布者或订阅者

MQTT协议本身是明文传输的。什么意思？就是你的设备发送的每条消息，包括用户名、密码、数据内容，在网络抓包工具里都是一目了然的。我在一个智能家居项目里就遇到过，客户说他们的传感器数据被邻居“不小心”看到了。嗯，其实就是没加密。

重要提醒：MQTT协议本身不提供任何加密机制。所有安全措施都需要我们手动加上去。

4.2 MQTT over TLS：给通信加把锁

MQTT over TLS，就是在MQTT协议外面套一层TLS加密。TLS就是HTTPS用的那个加密协议。说白了，就是把你的MQTT消息装进一个加密的管道里，外面的人看不到里面是什么。

配置MQTT over TLS，你需要做三件事：

  1. Broker端配置证书：Broker需要有一个服务器证书，用来证明自己的身份
  2. 客户端配置信任链：客户端需要信任Broker的证书颁发机构
  3. 修改连接端口：MQTT over TLS默认使用8883端口，而不是1883

举个例子，用Mosquitto Broker配置TLS：

# mosquitto.conf
listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/server.crt
keyfile /etc/mosquitto/server.key
tls_version tlsv1.2

客户端连接时，只需要指定CA证书和TLS选项：

# Python示例
import paho.mqtt.client as mqtt

client = mqtt.Client()
client.tls_set(ca_certs="ca.crt")
client.connect("broker.example.com", 8883, 60)

我曾经在一个工业项目里，发现有人把TLS配置成了tlsv1.0。嗯，那跟没配差不多。现在至少要用TLS 1.2，最好用TLS 1.3。

我的建议：如果你用的是自签名证书，记得把CA证书分发到每个设备上。不然客户端会报证书验证失败。

4.3 用户名密码认证：最基础的防线

TLS加密了通信内容，但谁来连接Broker呢？这时候就需要认证了。MQTT协议支持在CONNECT报文里携带用户名和密码。

配置用户名密码认证，Broker端需要做：

# mosquitto.conf
allow_anonymous false
password_file /etc/mosquitto/passwd

生成密码文件：

mosquitto_passwd -c /etc/mosquitto/passwd device1
# 然后输入密码

客户端连接时：

client.username_pw_set("device1", "mypassword")
client.connect("broker.example.com", 8883, 60)

这里有个坑。用户名密码是在MQTT的CONNECT报文里传输的。如果你没有启用TLS，那用户名密码就是明文传输的。我见过有人只配了用户名密码，没配TLS，还觉得挺安全。嗯，那跟没配一样。

注意：用户名密码认证必须配合TLS使用，否则密码会被直接暴露在网络中。

4.4 客户端证书认证：更高级的身份验证

用户名密码认证有个问题：密码可能会泄露，而且管理起来麻烦。你想想看，成百上千个设备，每个都要记住密码，密码还得定期更换。这工作量太大了。

客户端证书认证就解决了这个问题。每个设备有一个唯一的客户端证书，Broker通过验证这个证书来确认设备的身份。

配置客户端证书认证，Broker端需要：

# mosquitto.conf
listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/server.crt
keyfile /etc/mosquitto/server.key
require_certificate true
use_identity_as_username true

注意require_certificate true这一行，它告诉Broker必须验证客户端证书。

客户端连接时：

client.tls_set(
    ca_certs="ca.crt",
    certfile="device1.crt",
    keyfile="device1.key"
)
client.connect("broker.example.com", 8883, 60)

客户端证书认证的好处很明显：

  • 安全性更高：证书比密码更难伪造
  • 管理更方便：证书可以设置有效期，到期自动失效
  • 支持吊销：设备丢失后，可以吊销它的证书

我在一个车联网项目里，用了客户端证书认证。每辆车出厂时烧录一个唯一的证书。车辆联网时，Broker通过证书识别车辆身份。这样即使有人拿到了车辆的密码，没有证书也连不上Broker。

最佳实践：生产环境中，建议同时使用TLS加密和客户端证书认证。这样既保证了通信安全，又实现了设备身份验证。

4.5 三种安全机制的对比

咱们来总结一下这三种安全机制：

安全机制 保护内容 安全性 管理复杂度 适用场景
MQTT over TLS 通信内容加密 高 中 所有需要加密通信的场景
用户名密码认证 设备身份验证 中（需配合TLS） 低 设备数量少，管理简单的场景
客户端证书认证 设备身份验证 高 高 设备数量多，安全性要求高的场景

我个人习惯的做法是：

  • 开发测试环境：只用TLS，用户名密码随便设
  • 小规模生产环境：TLS + 用户名密码
  • 大规模生产环境：TLS + 客户端证书认证

嗯，这里要注意。不管用哪种方式，TLS是必须的。没有TLS，其他安全措施都是空中楼阁。

避坑指南：我曾经在一个项目里，把客户端证书和私钥直接硬编码在代码里。后来发现代码被反编译了，私钥泄露了。正确的做法是把证书和私钥放在安全存储区，比如HSM或者安全芯片里。

好了，这一章的内容就到这里。MQTT安全其实不难，关键是要理解每个机制的作用，然后根据实际场景选择合适的组合。下一章我们会聊到CoAP协议的安全，那也是物联网里另一个重要的协议。

← 上一章 📖 返回目录 下一章 →