SMPP di per sé non è cifrato — il system_id e la password del bind attraversano il filo in chiaro su TCP semplice. In produzione lo si protegge facendo transitare SMPP su TLS (avvolgendo la sessione TCP), autenticando con credenziali più allow-list degli IP, imponendo TLS 1.2+ e ruotando le credenziali da un secret manager anziché scriverle nel codice.
bind_transceiverAprire e autenticare la sessionebind_transceiver_respSessione accettatasubmit_smInviare un messaggiosubmit_sm_respAccettato, ID messaggio restituitodeliver_smRicevuta di consegna o messaggio in entratadeliver_sm_respConfermatoenquire_linkKeepalive durante l'inattività
Perché SMPP in chiaro è un rischio
La specifica SMPP non definisce alcuna sicurezza di trasporto. Su un bind TCP in chiaro (porta 2775), il system_id e la password in bind_transmitter/receiver/transceiver, e ogni body di messaggio, viaggiano non cifrati. Su qualsiasi percorso non attendibile questo espone le credenziali all'intercettazione e il traffico all'ascolto. La sicurezza va quindi aggiunta a livello di trasporto, non dal protocollo.
SMPP su TLS
Il controllo standard è far transitare la sessione SMPP all'interno di un tunnel TLS: la connessione TCP completa un handshake TLS prima dell'invio della PDU di bind, così credenziali e payload sono cifrati end-to-end. Non esiste un'unica porta TLS IANA per SMPP, quindi i provider espongono una porta dedicata abilitata al TLS. Imponete TLS 1.2 o superiore, validate la catena di certificati del server, rifiutate certificati scaduti o autofirmati e non disabilitate mai la verifica per 'far funzionare le cose'.
| Aspetto | SMPP in chiaro | SMPP over TLS |
|---|---|---|
| Trasporto | TCP (porta predefinita 2775) | TCP + TLS (porta fornita dal provider) |
| Credenziali in transito | In chiaro | Crittografato |
| Corpi dei messaggi | In chiaro | Crittografato |
| Identità del server | Non verificato | Validato tramite certificato |
Autenticazione e allow-list degli IP
SMPP si autentica con la coppia system_id/password nel bind. Da sola è debole, quindi gli operatori vi sovrappongono l'allow-list degli IP: solo indirizzi IP di origine pre-registrati possono aprire un bind, su entrambe le estremità. L'allow-list è un controllo operatore standard e un modo rapido per contenere una credenziale trafugata — una password rubata è inutile da un IP non in lista. Combinatela con il TLS, non in sua sostituzione.
Igiene delle credenziali
Trattate le credenziali SMPP come qualsiasi altro segreto. Conservatele in un secret manager, mai nel codice sorgente o in configurazioni committate in un repository. Ruotatele su base pianificata e immediatamente a ogni sospetta esposizione. Usate credenziali distinte per ambiente e per integrazione affinché una fuga abbia un raggio d'azione limitato, e monitorate bind da IP inattesi o in orari inattesi.
Domande frequenti
SMPP è cifrato per impostazione predefinita?
No. SMPP non ha cifratura integrata — su TCP in chiaro le credenziali e i body dei messaggi sono inviati in chiaro. La cifratura si aggiunge facendo transitare la sessione SMPP su TLS, cosa che il protocollo non specifica ma che ogni provider serio supporta.
Quale porta usa SMPP su TLS?
Non esiste un'unica porta TLS standardizzata. SMPP in chiaro usa la porta IANA 2775; per il TLS i provider espongono una porta dedicata separata (a volte si usa la 3550). Usate la porta TLS che il vostro provider assegna.
L'allow-list degli IP è sufficiente da sola?
No. L'allow-list degli IP limita chi può connettersi e contiene le credenziali trafugate, ma non cifra il traffico. Combinate l'allow-list con SMPP su TLS affinché siano protette sia l'origine della connessione sia la riservatezza dei dati.
Come dovrei conservare le credenziali SMPP?
In un secret manager, mai nel codice o in configurazioni committate. Usate credenziali separate per ambiente e integrazione, ruotatele su base pianificata e a ogni sospetta fuga, e monitorate bind da IP inattesi.
Specifiche della fonte
Gli standard pubblicati su cui si basa questa pagina. Si apre in una nuova scheda.