Le SMPP lui-même n'est pas chiffré — le system_id et le password du bind transitent en clair sur du TCP brut. En production, on le sécurise en faisant passer le SMPP sur TLS (en enveloppant la session TCP), en s'authentifiant par identifiants plus liste d'IP autorisées, en imposant TLS 1.2+, et en effectuant la rotation des identifiants depuis un gestionnaire de secrets plutôt que de les coder en dur.
bind_transceiverOuvrir et authentifier la sessionbind_transceiver_respSession acceptéesubmit_smEnvoyer un messagesubmit_sm_respAccepté, ID du message renvoyédeliver_smAccusé de réception ou message entrantdeliver_sm_respConfirméenquire_linkKeepalive en cas d'inactivité
Pourquoi le SMPP en clair est un risque
La spécification SMPP ne définit aucune sécurité de transport. Sur un bind TCP en clair (port 2775), le system_id et le password dans bind_transmitter/receiver/transceiver, ainsi que chaque corps de message, transitent sans chiffrement. Sur tout chemin non fiable, cela expose les identifiants à l'interception et le trafic à l'écoute. La sécurité s'ajoute donc au niveau du transport, pas par le protocole.
SMPP sur TLS
Le contrôle standard consiste à faire fonctionner la session SMPP dans un tunnel TLS : la connexion TCP achève un handshake TLS avant l'envoi de la PDU de bind, si bien que les identifiants et les charges utiles sont chiffrés de bout en bout. Il n'existe pas de port TLS IANA unique pour le SMPP ; les fournisseurs exposent donc un port dédié compatible TLS. Imposez TLS 1.2 ou supérieur, validez la chaîne de certificats du serveur, rejetez les certificats expirés ou auto-signés, et ne désactivez jamais la vérification « pour que ça marche ».
| Aspect | SMPP en clair | SMPP over TLS |
|---|---|---|
| Transport | TCP (port par défaut 2775) | TCP + TLS (port fourni par le fournisseur) |
| Identifiants transmis en clair sur le réseau | En clair | Chiffré |
| Corps de message | En clair | Chiffré |
| Identité du serveur | Non vérifié | Validé par certificat |
Authentification et liste d'IP autorisées
Le SMPP s'authentifie avec la paire system_id/password du bind. C'est faible en soi ; les opérateurs superposent donc une liste d'IP autorisées : seules des adresses IP source préenregistrées peuvent ouvrir un bind, aux deux extrémités. La liste d'autorisation est un contrôle opérateur standard et un moyen rapide de contenir un identifiant fuité — un mot de passe volé est inutile depuis une IP non listée. Combinez-la avec TLS, sans la substituer à lui.
Hygiène des identifiants
Traitez les identifiants SMPP comme tout autre secret. Stockez-les dans un gestionnaire de secrets, jamais dans le code source ni dans une configuration versionnée. Effectuez la rotation selon un calendrier et immédiatement en cas d'exposition soupçonnée. Utilisez des identifiants distincts par environnement et par intégration afin qu'une fuite ait un rayon d'impact limité, et surveillez les binds provenant d'IP inattendues ou à des heures inhabituelles.
Questions fréquemment posées
Le SMPP est-il chiffré par défaut ?
Non. Le SMPP n'a aucun chiffrement intégré — sur du TCP brut, les identifiants et les corps de message sont envoyés en clair. Le chiffrement s'ajoute en faisant passer la session SMPP sur TLS, ce que le protocole ne spécifie pas mais que tout fournisseur sérieux prend en charge.
Quel port pour le SMPP sur TLS ?
Il n'y a pas de port TLS standardisé unique. Le SMPP en clair utilise le port IANA 2775 ; pour TLS, les fournisseurs exposent un port provisionné distinct (3550 est parfois utilisé). Utilisez le port TLS que votre fournisseur attribue.
La liste d'IP autorisées suffit-elle à elle seule ?
Non. La liste d'IP autorisées limite qui peut se connecter et contient les identifiants fuités, mais elle ne chiffre pas le trafic. Combinez-la avec le SMPP sur TLS pour protéger à la fois l'origine de la connexion et la confidentialité des données.
Comment stocker les identifiants SMPP ?
Dans un gestionnaire de secrets, jamais dans le code ni la configuration versionnée. Utilisez des identifiants distincts par environnement et intégration, effectuez leur rotation selon un calendrier et à toute fuite soupçonnée, et surveillez les binds depuis des IP inattendues.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.