Référence des ports
Port 8883 (TCP) – MQTT over TLS
Port par défaut de MQTT sécurisé par TLS, la variante chiffrée du protocole publication/abonnement IoT qui tourne en clair sur 1883.
État par défaut
Réservé au MQTT enveloppé dans TLS. Le chiffrement est en place, mais les brokers peuvent toujours autoriser l'accès anonyme, accepter des certificats faibles ou exposer aussi le 1883 en clair, sapant la protection.
Attaques courantes
- Connexion anonyme ou par identifiants faibles malgré TLS activé
- Repli vers MQTT en clair sur 1883 quand les deux ports sont ouverts
- Exploitation de configurations TLS faibles ou de l'absence de vérification de certificat client
- Abonnement aux topics avec le joker # une fois authentifié
Durcissement
- Exiger l'authentification client (mots de passe ou certificats TLS mutuels)
- Désactiver le 1883 en clair pour empêcher le repli des clients
- Utiliser des versions TLS modernes et des suites de chiffrement fortes ; valider les certificats
- Imposer des ACL de topics par client pour limiter la portée abonnement/publication
- Lier à une interface privée, limiter 8883 par pare-feu et maintenir le broker à jour
Commande nmap
nmap -p8883 --script ssl-cert,mqtt-subscribe <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Que tourne sur le port 8883 ?
Le port 8883 est le port par défaut de MQTT sur TLS — la forme chiffrée du protocole publication/abonnement léger utilisé par les appareils IoT. C'est le même MQTT que sur le 1883 en clair, mais enveloppé dans TLS afin que topics, charges utiles et identifiants soient protégés en transit. Les clients se connectent à un broker central pour publier et s'abonner sur un canal chiffré.
Pourquoi c'est important pour la sécurité
Le 8883 existe pour combler le défaut de confidentialité du MQTT en clair, mais TLS n'est pas un contrôle d'accès. Les brokers peuvent toujours autoriser l'accès anonyme, accepter des certificats faibles ou exposer aussi le 1883 en clair, permettant aux attaquants de revenir en arrière. Comme MQTT transporte la télémétrie et les commandes IoT, un broker à l'authentification faible fuit toujours des données et laisse contrôler des appareils.
Comment c'est attaqué
Les attaquants tentent des connexions anonymes ou par identifiants faibles même
sur TLS, puis s'abonnent à # pour lire tous les topics. Là où les deux ports
sont ouverts, ils rabaissent les clients vers le 1883 en clair. Les
configurations TLS faibles et l'absence de vérification de certificat client sont
sondées pour intercepter ou usurper, et les topics de contrôle sont détournés pour
actionner des appareils.
Liste de durcissement
Exigez l'authentification client — mots de passe ou certificats TLS mutuels — et désactivez le 1883 en clair pour empêcher le repli des clients. Utilisez des versions TLS modernes et des chiffrements forts, et validez les certificats. Imposez des ACL de topics par client, liez à une interface privée, limitez 8883 par pare-feu et maintenez le broker à jour. Utilisez l'extrait nmap ci-dessus pour vérifier l'exposition sur les brokers que vous êtes autorisé à tester.
Ports liés
Questions fréquentes
- En quoi le port 8883 diffère-t-il du 1883 ?
- Le port 8883 transporte MQTT dans un tunnel TLS, chiffrant topics, charges utiles et identifiants. Le port 1883 est le même protocole en clair. Utilisez 8883 et désactivez 1883 si possible.
- Le TLS sur 8883 rend-il MQTT sûr à lui seul ?
- Non. TLS protège les données en transit mais pas le contrôle d'accès. Il faut toujours l'authentification, des ACL de topics par client et une validation forte des certificats, sinon un attaquant peut s'authentifier et lire ou injecter des messages.