MQTT

Was ist MQTT?

MQTT ist ein leichtgewichtiges Publish/Subscribe-Nachrichtenprotokoll für Geräte mit begrenzter Bandbreite, Energie und Rechenleistung. Clients sprechen nicht miteinander; sie verbinden sich mit einem Broker, veröffentlichen Nachrichten auf Topics und abonnieren Topics. Topics sind hierarchische Zeichenketten wie werk/linie3/roboter7/temperatur, und Abonnements können Wildcards nutzen: + für eine Ebene, # für alles darunter. Drei Quality-of-Service-Stufen (0, 1, 2) regeln die Zustellgarantien. Retained Messages halten den letzten Wert eines Topics für neue Abonnenten vor, und eine Last-Will-Nachricht veröffentlicht der Broker, wenn ein Client unerwartet die Verbindung verliert.

Das Protokoll läuft über TCP, üblicherweise auf Port 1883 für Klartext und 8883 für TLS, und über WebSockets für Browser. Es ist das dominierende Protokoll in IoT-Flotten, Smart-Home-Produkten, Fahrzeug-Backends und Industrie-4.0-Datenpipelines, einschließlich OPC UA PubSub über MQTT und Sparkplug B.

Wo ist es definiert?

MQTT wird von OASIS standardisiert. Version 3.1.1 (2014) ist auch als ISO/IEC 20922:2016 veröffentlicht; Version 5.0 (2019) ergänzt Reason Codes, Nachrichteneigenschaften, Nachrichtenablauf, Shared Subscriptions, serverseitige Limits und die erweiterte Authentifizierung über das AUTH-Paket. Das Sicherheitskapitel beider Spezifikationen ist ausdrücklich nicht normativ: Es empfiehlt TLS, Authentifizierung von Clients und Servern, Autorisierung des Zugriffs auf Topics und Schutz des Brokers, schreibt aber nichts davon vor. Sicherheit kommt also aus der Broker-Konfiguration und der Client-Implementierung, nicht aus dem Protokoll.

Für Gerätehersteller gilt der Cyber Resilience Act: Anhang I verlangt Schutz von Daten bei Übertragung und Speicherung, Zugriffskontrolle und Schutz vor unbefugtem Zugriff, was für ein MQTT-angebundenes Produkt TLS, Authentifizierung pro Gerät und Autorisierung auf dem Broker bedeutet.

Was es in der Praxis bedeutet

Wir haben MQTT-Broker, die angebundenen Geräte und die Cloud-Backends dahinter in einer Reihe von IoT-Penetrationstests geprüft, von ESP32-basierten Kommunikationsmodulen bis zu Geräteflotten. Die Findings wiederholen sich:

• Anonymer Zugang. Der Broker nimmt Verbindungen ohne Zugangsdaten an, meist ein Überbleibsel aus der Entwicklung.
• Kein TLS oder TLS ohne Prüfung. Klartext auf 1883 ins Internet oder eine Gerätefirmware, die jedes Serverzertifikat akzeptiert, was das Abfangen von Zugangsdaten und Befehlen in jedem Netz trivial macht, dem das Gerät beitritt.
• Ein Zugangsdatensatz für die Flotte. Benutzername und Passwort oder ein Client-Zertifikat, fest in die Firmware jedes Geräts eingebacken. Firmware-Extraktion aus einem Gerät liefert Zugriff auf alle.
• Keine Topic-Autorisierung. Jeder authentifizierte Client darf # abonnieren und überall veröffentlichen. Daten aller Kunden und Befehle an alle Geräte werden les- und schreibbar, das MQTT-Gegenstück zu einer IDOR.
• Identität nicht an Topics gebunden. Das Gerät veröffentlicht unter devices/<seriennummer>/..., und der Broker prüft nie, ob der authentifizierte Client diese Seriennummer ist.
• Retained Messages und Wills, die Zustand leaken. Zugangsdaten, WLAN-Passwörter oder Standortdaten in Retained-Payloads, die jeder Abonnent beim Verbinden bekommt.
• Exponierte Verwaltung. Broker-Dashboards, WebSocket-Listener und Metrik-Endpunkte aus dem Internet erreichbar, mit Standardzugangsdaten.
• Client-ID-Kollisionen. Vorhersagbare Client-IDs erlauben einem Angreifer, legitime Geräte zu trennen, indem er sich mit derselben ID verbindet.

Die Fixes sind Standard: TLS überall mit Zertifikatsprüfung und idealerweise Pinning auf dem Gerät, Zugangsdaten oder Client-Zertifikate pro Gerät mit einem Weg zum Widerruf, Zugriffslisten, die jede Identität an ihr eigenes Topic-Präfix binden, Raten- und Payload-Limits und ein Broker, der nicht weiter erreichbar ist, als die Architektur es braucht. Zyberum testet MQTT-Umgebungen Ende zu Ende: Broker, Geräte (inklusive Firmware-Analyse), Mobile Apps und Cloud-APIs.

Häufige Missverständnisse

TLS ist keine Autorisierung; eine verschlüsselte Verbindung zu einem Broker ohne ACLs zeigt trotzdem allen alles. Ein gemanagter Broker in der Cloud ist nicht von sich aus sicher; ACLs und Identitäten musst du weiterhin selbst konfigurieren. Und MQTT ist weder ein reines Industrie- noch ein reines Consumer-Protokoll; dieselben Fehler tauchen in beiden Welten auf.