# Protezione di SMPP: TLS, autenticazione e allow-list degli IP

> 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.

- URL canonico: https://www.broadnet.me/it/reference/smpp-over-tls-security
- Lingua: it
- Ultimo aggiornamento: 2026-07-18
- Editore: BroadNet (https://www.broadnet.me)

SMPP non prevede cifratura nativa. Come proteggere un bind in produzione: SMPP su TLS, autenticazione basata su credenziali e IP, allow-list e igiene delle credenziali.

## 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'.

*SMPP in chiaro vs su TLS*

| 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.

## Fonti

- [SMPP v3.4 specification](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [RFC 8446 — TLS 1.3](https://datatracker.ietf.org/doc/html/rfc8446)

## Correlati

- [Operazioni di bind SMPP](https://www.broadnet.me/it/reference/smpp-bind-operations)
- [Best practice di integrazione SMPP](https://www.broadnet.me/it/reference/smpp-integration-best-practices)
- [Checklist di integrazione SMPP (guida)](https://www.broadnet.me/it/guides/smpp-integration-checklist)
- [Gateway SMSC (operatori)](https://www.broadnet.me/it/operators/smsc-gateway)
- [Documentazione per sviluppatori](https://www.broadnet.me/it/developers)