feat: expand MQTT contract and reliability lessons
This commit is contained in:
@@ -4,6 +4,10 @@ Continue the same isolated lab. This lesson explains the MQTT security design an
|
||||
|
||||
## 1. Trace the checks in order
|
||||
|
||||
**❓ Question:** **A device publishes `{"device_id":"device-001"}` on another device's topic. Which component can establish who sent it, and which component rejects the mismatch?**
|
||||
|
||||
**💬 Answer:** The broker authenticates the MQTT client and applies that client's topic ACL before routing. Paho receives the packet and invokes the handler; the application then validates topic and payload identity agreement. The JSON field is a claim, not proof of identity. If the topic is allowed for the authenticated client but the body conflicts, the application rejects it. A prior PUBACK or other MQTT acknowledgement does not get reversed by that application rejection.
|
||||
|
||||
```text
|
||||
TCP → TLS certificate verification → MQTT CONNECT authentication
|
||||
→ topic authorization → application identity/schema validation
|
||||
@@ -16,6 +20,10 @@ A Client ID is session identity, not a secret. A payload `device_id` is a claim.
|
||||
|
||||
## 2. Configure verified TLS in Go
|
||||
|
||||
**❓ Question:** **The CA is trusted, but the certificate is for `broker.lab` and the client connects to `127.0.0.1`. Why can verification still fail?**
|
||||
|
||||
**💬 Answer:** Trust-chain validation and server-name verification are separate checks. The certificate must include the DNS name or IP the client verifies. Fix the URL or certificate identity; do not disable verification.
|
||||
|
||||
Provision a lab CA and server certificate for the exact DNS name or IP used in the client URL. An IP connection needs that IP in the certificate's Subject Alternative Name. Keep the CA private key outside the broker; the broker needs its server key and certificate. Mount files with broker-readable permissions. Configure Mosquitto's TLS listener using `certfile` and `keyfile`; require client certificates only when deliberately introducing mutual TLS.
|
||||
|
||||
This fragment belongs in your configuration/transport setup and requires `crypto/tls`, `crypto/x509`, `fmt`, and `os`. `caPath` is a configured path to the public lab CA certificate and `brokerHostname` is the validated URL hostname (without a port):
|
||||
@@ -53,7 +61,7 @@ Use the official [Mosquitto TLS configuration reference](https://mosquitto.org/m
|
||||
| Permitted topic, mismatched body device | Application validation | Rejection before any state mutation |
|
||||
| Valid API user, unauthorized target device | HTTP business authorization | Denial before creating/publishing a command |
|
||||
|
||||
Never fix an ACL test by replacing narrow permissions with `#`. A successful broad SUBACK alone is not proof of cross-device access: test actual delivery. Restrict Response Topic before replying so a device cannot be used to publish a response into an unexpected namespace.
|
||||
Never fix an ACL test by replacing narrow permissions with `#`. A successful broad SUBACK alone is not proof of cross-device access: test actual delivery. The device or simulator checks that a command's Response Topic is exactly the response destination authorized for that device before publishing. The command service separately matches the resulting application response to its pending command. Correlation Data identifies the request to match; it does not authorize the destination or authenticate the publisher.
|
||||
|
||||
## 4. Rotate credentials without confusing state
|
||||
|
||||
|
||||
Reference in New Issue
Block a user