MQTT over TLS giúp bảo vệ dữ liệu khi thiết bị nhà máy kết nối với MQTT broker. Với MQTT qua TCP không mã hóa, thường dùng port 1883, người bắt được lưu lượng có thể phân tích gói tin để đọc topic, dữ liệu và thông tin đăng nhập nếu chúng được gửi trong gói CONNECT.
Khi dữ liệu sản xuất đi qua Internet hoặc 4G, rủi ro này cần được xử lý ngay từ thiết kế. Bài viết giải thích MQTTS, cách hoạt động, lựa chọn cổng và cấu hình Mosquitto cơ bản cho dự án IIoT.
I. MQTT over TLS là gì?
1. Khái niệm cơ bản về MQTT
MQTT hoạt động theo cơ chế publish/subscribe. Client gửi bản tin lên một topic; broker nhận và phân phối tới những client đăng ký topic phù hợp. Ví dụ, gateway gửi nhiệt độ lên factory/line1/temperature, còn phần mềm giám sát đăng ký nhận dữ liệu đó.
Giao thức nhẹ, tách bên gửi khỏi bên nhận, phù hợp nhiều bài toán IIoT. Có thể xem thêm bài giao thức truyền thông công nghiệp để phân biệt MQTT với các giao thức kết nối thiết bị tại máy.
2. Định nghĩa MQTT over TLS (MQTTS)
MQTTS là cách gọi phổ biến của MQTT over TLS: MQTT được truyền bên trong kênh TLS. Kết nối thường dùng TCP port 8883; nhiều thư viện hỗ trợ địa chỉ dạng mqtts://broker.example.com:8883.
MQTT 3.1.1 hoặc MQTT 5.0 vẫn giữ cơ chế topic, QoS và publish/subscribe. TLS bổ sung bảo vệ ở lớp truyền tải, không tạo ra một phiên bản MQTT mới. Có thể hình dung MQTT không mã hóa như bưu thiếp; TLS giống phong bì được khóa trên đường vận chuyển.
II. Vì sao MQTT cần TLS trong nhà máy?
Một IoT Box có thể gửi sản lượng, mã lỗi hoặc trạng thái PLC lên cloud. Nếu đường truyền không được bảo vệ, dữ liệu có nguy cơ bị nghe lén. Kẻ tấn công nằm giữa hai bên cũng có thể giả mạo điểm kết nối hoặc can thiệp bản tin.
TLS cung cấp ba lớp bảo vệ:
- Mã hóa: che nội dung trao đổi khỏi người quan sát đường truyền.
- Toàn vẹn: phát hiện dữ liệu bị thay đổi trong quá trình truyền.
- Xác thực: giúp client kiểm tra broker; có thể xác thực thêm thiết bị bằng mTLS.
Cần hiểu đúng phạm vi: TLS bảo vệ từng kết nối client–broker. Broker vẫn đọc được bản tin sau khi giải mã; muốn giữ bí mật cả với broker phải thiết kế mã hóa payload riêng. TLS cũng không thay thế phân quyền topic hay cơ chế an toàn khi điều khiển máy từ xa.
III. MQTT over TLS hoạt động như thế nào?
1. Quy trình bắt tay TLS
Với kết nối mới sử dụng chứng chỉ, quy trình có thể tóm tắt như sau:
- Client mở kết nối TCP, gửi ClientHello để đề xuất tham số TLS.
- Server phản hồi ServerHello, gửi chứng chỉ và các thông điệp bắt tay tương ứng.
- Client kiểm tra chuỗi tin cậy, thời hạn và tên broker trong chứng chỉ.
- Hai bên hoàn tất thỏa thuận khóa và kiểm tra thông điệp Finished. Nếu dùng mTLS, broker kiểm tra chứng chỉ client.
- Khi kênh TLS sẵn sàng, client gửi MQTT CONNECT; broker xử lý xác thực, chính sách và trả CONNACK.
Client / GatewayMQTT brokerClientHelloServerHello, chứng chỉ và thông điệp TLSKiểm tra chứng chỉ, thỏa thuận khóavà hoàn tất bắt tay TLSMQTT CONNECT — đã mã hóaMQTT CONNACK — đã mã hóa.
Sơ đồ khái quát. Thứ tự thông điệp chi tiết phụ thuộc phiên bản TLS và chế độ xác thực.
Ở TLS 1.3, nhiều thông điệp bắt tay sau ServerHello đã được mã hóa. Vì vậy, sơ đồ trên không có nghĩa chứng chỉ luôn được gửi rõ trên mạng. [2]
2. TLS một chiều
Client dùng CA tin cậy để xác minh chứng chỉ broker. Thiết bị có thể đăng nhập ở lớp MQTT bằng username/password hoặc token, tùy nền tảng. TLS một chiều không yêu cầu client cung cấp chứng chỉ riêng.
3. Mutual TLS: xác thực hai chiều
Với mutual TLS (mTLS), broker cũng yêu cầu chứng chỉ client và bằng chứng sở hữu khóa riêng. Nên cân nhắc mTLS cho thiết bị hiện trường khi có khả năng cấp, bảo vệ và xoay vòng chứng chỉ. Mỗi thiết bị dùng danh tính riêng để dễ cô lập khi có sự cố.
4. Các chứng chỉ cần chuẩn bị
- CA certificate: làm cơ sở kiểm tra chuỗi tin cậy.
- Server certificate và private key: dùng cho broker.
- Client certificate và private key: cần khi dùng mTLS.
CA công cộng thuận tiện khi client đã có kho tin cậy phù hợp. CA nội bộ phù hợp hệ thống được quản lý tập trung. Chứng chỉ server tự ký vẫn dùng được nếu được tin cậy rõ ràng; không được xử lý bằng cách bỏ kiểm tra chứng chỉ. Khóa riêng phải được giữ bí mật, không nhúng chung cho toàn bộ thiết bị.
IV. So sánh port MQTT 1883, 8883 và 443
| Port thường dùng | Kiểu kết nối | Mã hóa | Khi nào dùng? |
| 1883/TCP | MQTT trực tiếp qua TCP | Không có TLS | Thử nghiệm cô lập hoặc kiến trúc có lớp bảo vệ riêng đã đánh giá. |
| 8883/TCP | MQTT over TLS | Có | Gateway, thiết bị kết nối broker bảo mật; IANA đăng ký tên secure-mqtt. |
| 443/TCP | Thường là MQTT over WSS | Có TLS | Client WebSocket, trình duyệt hoặc mạng chỉ cho phép HTTPS/WSS. |
Port 8883 là cổng đăng ký cho Secure MQTT, nhưng chọn đúng số cổng chưa đủ: broker và client phải thực sự bật TLS.
Không nên mở listener 1883 ra Internet; hãy tắt nếu production không cần. Nếu 8883 bị chặn bởi firewall, APN hoặc chính sách mạng, cần kiểm tra trước với bên quản trị. Chuyển sang 443 chỉ hoạt động khi cả hai phía hỗ trợ đúng kiểu kết nối. Một số dịch vụ cho MQTT/TLS trực tiếp qua 443 với yêu cầu riêng; không thể mặc định coi mọi cổng 443 là WSS. [5]
V. Ưu điểm và hạn chế của MQTT over TLS
Ưu điểm chính là bảo vệ thông tin trên đường truyền và xác minh điểm kết nối. Đây là nền tảng để thiết kế hệ thống đáp ứng yêu cầu bảo mật của khách hàng, nhưng không tự chứng minh hệ thống đạt mọi tiêu chuẩn hoặc yêu cầu nghiệm thu.
Đổi lại, mã hóa cần CPU, RAM và thêm dung lượng truyền. Handshake có thể gây tải đáng kể khi gateway yếu hoặc nhiều thiết bị đồng loạt kết nối lại. Vận hành còn bao gồm cấp, gia hạn và thu hồi chứng chỉ.
Để giảm overhead, duy trì kết nối ổn định, chọn MQTT Keep Alive phù hợp và dùng TLS session resumption khi hai phía hỗ trợ. Ưu tiên TLS 1.3 nếu tương thích, đồng thời đo độ trễ và bộ nhớ trên thiết bị thực tế. Session resumption của TLS khác với phiên lưu subscription của MQTT.
VI. Hướng dẫn cấu hình MQTT over TLS cơ bản
1. Cấu hình broker Mosquitto
Ví dụ dưới đây dùng Mosquitto 2.x, TLS một chiều và tài khoản MQTT. Chuẩn bị chứng chỉ broker có SAN khớp tên miền, khóa riêng, file mật khẩu và ACL trước khi khởi động:
listener 8883
protocol mqtt
certfile /etc/mosquitto/certs/server-fullchain.pem
keyfile /etc/mosquitto/certs/server.key
tls_version tlsv1.2
require_certificate false
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl
Trong Mosquitto 2.x, tls_version tlsv1.2 đặt phiên bản tối thiểu. Để chuyển listener này sang mTLS với CA thiết bị riêng, thay dòng require_certificate false và bổ sung:
cafile /etc/mosquitto/certs/device-ca.pem
require_certificate true
use_identity_as_username true
Chế độ này dùng CN của chứng chỉ client làm username để áp ACL; password_file không còn được dùng cho listener đó. CA phía broker tin cậy chứng chỉ thiết bị; CA phía client tin cậy chứng chỉ broker. Hai CA không bắt buộc giống nhau.
Ví dụ ACL cho thiết bị có username hoặc CN là device01:
user device01
topic write factory/device01/telemetry
topic read factory/device01/command
Đảm bảo tiến trình Mosquitto đọc được file cần thiết và khóa riêng có quyền truy cập hạn chế. Rà soát toàn bộ cấu hình để tránh còn listener 1883 ngoài ý muốn.
2. Cấu hình client hoặc thiết bị
Nạp CA tin cậy, dùng hostname đúng SAN, chọn 8883 và bật kiểm tra chứng chỉ. Ví dụ publish bằng mTLS, tương ứng cấu hình broker đã chuyển sang mTLS:
mosquitto_pub -h broker.example.com -p 8883 \
–cafile server-ca.pem \
–cert device01.crt –key device01.key \
-i device01 -t factory/device01/telemetry \
-m ‘{“temperature”:32.5}’
Thay tên miền và đường dẫn bằng giá trị thật. Với TLS một chiều, bỏ –cert, –key và cấu hình tài khoản MQTT; nên lưu thông tin đăng nhập trong file cấu hình được hạn chế quyền đọc. Không dùng –insecure để bỏ kiểm tra hostname khi vận hành. [5]
3. Các lỗi thường gặp
- Certificate verify failed: kiểm tra CA tin cậy và chuỗi intermediate.
- Sai hostname: đối chiếu SAN; kết nối bằng IP cần IP SAN phù hợp.
- Chứng chỉ hết hạn hoặc chưa hiệu lực: kiểm tra thời hạn và đồng bộ giờ thiết bị.
- Timeout: kiểm tra DNS, listener, firewall và chính sách mạng.
- TLS thành công nhưng MQTT bị từ chối: kiểm tra tài khoản, ánh xạ danh tính và ACL.
VII. Checklist triển khai MQTT over TLS trong IIoT
- Chỉ cho phép TLS 1.2 trở lên; ưu tiên TLS 1.3 khi tương thích.
- Tắt listener 1883 nếu không cần; giới hạn đường truy cập broker.
- Cân nhắc mTLS, mỗi thiết bị một chứng chỉ và khóa riêng.
- Cấp ACL tối thiểu theo topic, tách quyền gửi dữ liệu và nhận lệnh.
- Theo dõi hạn chứng chỉ, có quy trình rotation và thu hồi thực sự được broker áp dụng.
- Kiểm tra firmware gateway, IoT Box, thư viện TLS và module 4G; xác định thành phần nào thực hiện TLS.
- Thử mất mạng, khởi động lại, sai chứng chỉ và truy cập topic trái phép trước nghiệm thu.
Trong kiến trúc hệ thống IoT công nghiệp, cần bảo vệ cả đoạn PLC–gateway và gateway–cloud. Nếu xử lý tại chỗ, tham khảo edge computing IIoT để bố trí luồng dữ liệu phù hợp.
Để áp dụng checklist trên vào hệ thống thực tế, doanh nghiệp cần đối chiếu yêu cầu bảo mật với khả năng của PLC, gateway và nền tảng cloud.
Nếu anh/chị đang lên phương án giám sát máy móc từ xa, hãy gửi Tự động hoá toàn cầu model PLC, sơ đồ kết nối và các thông số cần thu thập để được tư vấn lựa chọn thiết bị IoT công nghiệp phù hợp.
Zalo Miền Bắc