STARTTLS, SSL/TLS e SMTP: quale crittografia per le tue email?
Di CaptainDNS
Pubblicato il 17 febbraio 2026
- SSL è obsoleto dal 2015 (RFC 7568): il termine corretto è TLS. STARTTLS non è un protocollo di crittografia, è un comando che attiva TLS su una connessione esistente
- STARTTLS è vulnerabile agli attacchi downgrade: un attaccante di rete può rimuovere l'annuncio STARTTLS e forzare la comunicazione in chiaro. MTA-STS e DANE correggono questa vulnerabilità
- TLS 1.3 è lo standard consigliato per SMTP nel 2026: handshake più rapido (1-RTT), cipher suite più sicure, forward secrecy obbligatoria
- Configura il tuo MTA con TLS obbligatorio in uscita (
smtp_tls_security_level = encryptsu Postfix) e implementa MTA-STS per proteggere le email in entrata
Le tue email transitano davvero crittografate? Nel 2024, Google riporta che oltre il 95% delle email ricevute da Gmail utilizza TLS. Ma questo dato nasconde una realtà più sfumata: STARTTLS è opportunistico di default, gli attacchi downgrade sono documentati e molti server accettano ancora TLS 1.0 o cipher suite deboli.
Questa guida va oltre il semplice confronto STARTTLS vs Implicit TLS. Spiega come funziona la crittografia TLS a livello di handshake, perché TLS 1.3 cambia le carte in tavola per SMTP, quali vulnerabilità sfruttano gli attaccanti e come configurare una crittografia robusta sui MTA più diffusi (Postfix, Exim, Exchange). Che tu gestisca un server di posta o stia verificando un'infrastruttura email, ne uscirai con azioni concrete.
SSL, TLS, STARTTLS: chiarire la terminologia
I termini SSL, TLS e STARTTLS vengono usati in modo intercambiabile nel settore email. È una fonte di confusione importante, perché indicano cose fondamentalmente diverse.
SSL è morto, TLS lo ha sostituito
SSL (Secure Sockets Layer) è il predecessore di TLS. L'ultima versione, SSL 3.0, è stata pubblicata nel 1996 e ufficialmente abbandonata dalla RFC 7568 nel 2015 a causa di vulnerabilità critiche (POODLE, BEAST). Quando un provider email menziona "SSL" nel 2026, in realtà sta parlando di TLS.
| Protocollo | Anno | Stato nel 2026 |
|---|---|---|
| SSL 2.0 | 1995 | Vietato (RFC 6176) |
| SSL 3.0 | 1996 | Vietato (RFC 7568) |
| TLS 1.0 | 1999 | Obsoleto (RFC 8996) |
| TLS 1.1 | 2006 | Obsoleto (RFC 8996) |
| TLS 1.2 | 2008 | Accettabile |
| TLS 1.3 | 2018 | Consigliato |
In pratica: se il tuo server SMTP accetta ancora SSL 3.0 o TLS 1.0, è vulnerabile ad attacchi noti. Disattiva questi protocolli.
STARTTLS non è un protocollo di crittografia
STARTTLS è un comando SMTP (definito nella RFC 3207) che chiede al server di passare da una connessione in chiaro a una connessione crittografata TLS. Non è né SSL, né TLS, né un protocollo autonomo: è un meccanismo di upgrade di una connessione esistente.
La confusione nasce dal nome: "STARTTLS" contiene "TLS", ma non specifica quale versione di TLS verrà utilizzata. La versione negoziata dipende dalla configurazione del client e del server.
Implicit TLS vs Explicit TLS (STARTTLS)
Esistono due modi per stabilire TLS su una connessione SMTP:
| Metodo | Porta tipica | Funzionamento | Analogia web |
|---|---|---|---|
| Explicit TLS (STARTTLS) | 25, 587 | Connessione in chiaro, poi upgrade tramite comando STARTTLS | HTTP poi redirect verso HTTPS |
| Implicit TLS | 465 | Connessione TLS dal primo byte | HTTPS nativo sulla porta 443 |
Con Explicit TLS, c'è sempre un momento in cui la comunicazione è in chiaro (la fase EHLO prima di STARTTLS). Con Implicit TLS, non c'è mai comunicazione in chiaro. È questa differenza che ha conseguenze importanti in termini di sicurezza.
Come funziona la crittografia SMTP in pratica?
Che tu utilizzi STARTTLS o Implicit TLS, la crittografia si basa su un handshake TLS. Questo processo di negoziazione determina la versione del protocollo, la cipher suite utilizzata e lo scambio di chiavi.
Il handshake TLS passo dopo passo
Ecco cosa succede quando un server SMTP negozia TLS (dopo il comando STARTTLS o alla connessione sulla porta 465):
Con TLS 1.2 (4 scambi, 2-RTT):
- ClientHello: il client invia le versioni TLS e le cipher suite supportate
- ServerHello: il server sceglie la versione TLS e la cipher suite, invia il suo certificato
- Scambio di chiavi: il client genera un pre-master secret, lo crittografa con la chiave pubblica del server
- Finished: entrambe le parti confermano che il canale è crittografato
Con TLS 1.3 (2 scambi, 1-RTT):
- ClientHello: il client invia le versioni TLS, le cipher suite e le sue chiavi Diffie-Hellman
- ServerHello + Finished: il server sceglie i parametri, invia il suo certificato e conferma la crittografia
TLS 1.3 unifica diverse fasi: il handshake passa da 2-RTT a 1-RTT, riducendo la latenza di stabilimento della connessione. Per un server MX che gestisce migliaia di connessioni all'ora, questa ottimizzazione è significativa.
TLS 1.2 vs TLS 1.3: quali differenze per SMTP?
| Criterio | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake | 2-RTT | 1-RTT |
| Forward secrecy | Opzionale (dipende dalla cipher) | Obbligatoria |
| Cipher suite | 37 suite (incluse alcune deboli) | 5 suite (tutte robuste) |
| Compressione | Supportata (vulnerabile CRIME) | Rimossa |
| Rinegoziazione | Supportata (vettore d'attacco) | Rimossa |
| 0-RTT resumption | No | Sì (con precauzioni) |
| RFC | RFC 5246 | RFC 8446 |
Il punto chiave per SMTP: TLS 1.3 elimina le cipher suite deboli e rende la forward secrecy obbligatoria. Con TLS 1.2, un server può negoziare RSA senza scambio Diffie-Hellman, il che significa che un attaccante che ottiene la chiave privata del server può decifrare tutte le comunicazioni passate. Con TLS 1.3, ogni sessione utilizza chiavi effimere: anche se la chiave privata viene compromessa, le sessioni passate restano protette.
Cipher suite consigliate nel 2026
Per SMTP, configura il tuo server con queste cipher suite, in questo ordine di preferenza:
TLS 1.3 (nessuna configurazione necessaria, le 5 suite sono tutte sicure):
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256
TLS 1.2 (limitare alle suite con forward secrecy):
ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384ECDHE-ECDSA-CHACHA20-POLY1305ECDHE-RSA-CHACHA20-POLY1305ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256
Cipher suite da vietare: tutto ciò che contiene RC4, DES, 3DES, MD5, NULL, EXPORT, oppure RSA senza ECDHE/DHE (nessuna forward secrecy).
Le vulnerabilità di STARTTLS e come proteggersi
STARTTLS è il meccanismo di crittografia più diffuso per le connessioni SMTP tra server (porta 25). Ma la sua concezione opportunistica introduce vulnerabilità sfruttabili.
L'attacco downgrade STARTTLS
Quando un client SMTP si connette a un server sulla porta 25, invia EHLO e attende la lista delle estensioni. Se il server annuncia 250-STARTTLS, il client sa che può passare a TLS. Il problema: questo scambio avviene in chiaro.
Un attaccante posizionato tra il client e il server (man-in-the-middle) può modificare la risposta EHLO per rimuovere la riga 250-STARTTLS. Il client, non vedendo l'estensione STARTTLS, continua in chiaro. L'attaccante può così leggere e modificare tutte le email in transito.
# Risposta legittima del server
250-mx1.captaindns.com
250-STARTTLS <-- l'attaccante rimuove questa riga
250 OK
# Ciò che vede il client dopo l'attacco
250-mx1.captaindns.com
250 OK <-- nessun STARTTLS, connessione in chiaro
L'attacco STRIPTLS
STRIPTLS è una variante più sofisticata. Invece di rimuovere l'annuncio STARTTLS del server, l'attaccante intercetta il comando STARTTLS inviato dal client e restituisce un errore fasullo (ad esempio 454 TLS not available). Il client abbandona TLS e continua in chiaro, credendo a un problema temporaneo.
Questi due attacchi sono documentati e sono stati osservati su scala nazionale. Nel 2014, dei ricercatori hanno dimostrato che diversi paesi praticavano lo STRIPTLS sulle connessioni SMTP internazionali.
MTA-STS: forzare TLS sulle email in entrata
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) è la risposta dell'IETF agli attacchi downgrade su SMTP. Il principio: il dominio destinatario pubblica una policy che dice "tutti i server che mi inviano email devono usare TLS con un certificato valido".
Come funziona:
- Il dominio
captaindns.compubblica un record DNS TXT_mta-sts.captaindns.comcon un identificativo di policy - Il dominio ospita un file
https://mta-sts.captaindns.com/.well-known/mta-sts.txtcontenente la policy - Il server mittente consulta questa policy prima di connettersi al MX
- Se la policy è in modalità
enforce, il server mittente rifiuta di consegnare in chiaro
# Record DNS
_mta-sts.captaindns.com. TXT "v=STSv1; id=20260217"
# File di policy (HTTPS obbligatorio)
version: STSv1
mode: enforce
mx: mx1.captaindns.com
mx: mx2.captaindns.com
max_age: 604800
Limite: MTA-STS dipende da HTTPS per distribuire la policy. Se l'attaccante blocca l'accesso HTTPS al file di policy, il server mittente non può recuperare la policy e può tornare alla comunicazione in chiaro. È un problema di TOFU (Trust On First Use): la policy è sicura solo dopo il primo recupero riuscito.
DANE (TLSA): autenticare il certificato tramite DNS
DANE (DNS-based Authentication of Named Entities, RFC 7672 per SMTP) risolve il problema in modo diverso. Invece di pubblicare una policy tramite HTTPS, il dominio pubblica un record TLSA nel DNS che contiene l'impronta del certificato TLS atteso.
# Record TLSA per il MX (porta 25)
_25._tcp.mx1.captaindns.com. TLSA 3 1 1 a0b1c2d3e4f5...
Vantaggi di DANE:
- Nessuna dipendenza da HTTPS (a differenza di MTA-STS)
- Autentica il certificato del server tramite DNSSEC (non solo "TLS obbligatorio", ma "TLS con questo certificato")
- Protegge contro gli attacchi downgrade e i certificati falsi
Prerequisito: DANE richiede DNSSEC sul dominio. Senza DNSSEC, i record TLSA non sono autenticati e DANE è inefficace. È il principale ostacolo all'adozione: solo circa il 5% dei domini utilizza DNSSEC nel 2026.
| Meccanismo | Protegge dal downgrade | Autentica il certificato | Prerequisiti |
|---|---|---|---|
| STARTTLS da solo | No | No | Nessuno |
| MTA-STS | Sì (dopo il primo fetch) | Sì (CA pubblica) | HTTPS + DNS TXT |
| DANE | Sì | Sì (impronta esatta) | DNSSEC + DNS TLSA |
| MTA-STS + DANE | Sì (doppia protezione) | Sì (CA + impronta) | DNSSEC + HTTPS |
Configurare la crittografia TLS sul tuo server SMTP
La teoria è chiara. Passiamo alla configurazione concreta sui tre MTA più utilizzati.
Postfix: attivare e rafforzare TLS
Postfix è il MTA più diffuso sui server Linux. La configurazione TLS si fa in main.cf.
TLS in entrata (server, ricezione email):
# Attivare TLS per le connessioni in entrata
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem
smtpd_tls_security_level = may
# Forzare TLS 1.2 come minimo
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2
# Cipher suite (TLS 1.2)
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, MD5, DES, 3DES, RC4
TLS in uscita (client, invio email):
# Attivare TLS per le connessioni in uscita
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
# Forzare TLS 1.2 come minimo in uscita
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2
# Registrare le connessioni TLS (utile per l'audit)
smtp_tls_loglevel = 1
Rafforzare ulteriormente: sostituisci smtp_tls_security_level = may con encrypt per rifiutare qualsiasi connessione in chiaro in uscita. Attenzione: alcuni piccoli server non supportano TLS, le tue email verso questi server verranno bloccate. Usa la modalità dane se DNSSEC è disponibile.
Valore security_level | Comportamento |
|---|---|
none | Nessun TLS (sconsigliato) |
may | TLS opportunistico (default, accetta il chiaro) |
encrypt | TLS obbligatorio (rifiuta il chiaro) |
dane | TLS + verifica DANE tramite DNSSEC |
verify | TLS + verifica dell'hostname del certificato |
Exim: configurazione TLS
Exim utilizza una configurazione modulare. Le direttive TLS si trovano nel blocco principale.
# Certificato e chiave
tls_certificate = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
tls_privatekey = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem
# Annunciare STARTTLS
tls_advertise_hosts = *
# Forzare TLS 1.2 come minimo
openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1
# Richiedere TLS per le connessioni in uscita (opzionale)
tls_require_ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-ECDSA-AES128-GCM-SHA256:\
ECDHE-RSA-AES128-GCM-SHA256
Per verificare la configurazione: exim -bV mostra le funzionalità TLS compilate.
Microsoft Exchange: imporre TLS
Su Exchange (2019+), la configurazione TLS si fa tramite i connettori di ricezione e di invio.
Connettore di ricezione (email in entrata):
# Forzare TLS sul connettore di ricezione
Set-ReceiveConnector "Default Frontend" -RequireTLS $true
# Disattivare i protocolli obsoleti (tramite registro di Windows)
# HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
# Disattivare SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1
Connettore di invio (email in uscita verso un partner specifico):
# Creare un connettore di invio con TLS obbligatorio
New-SendConnector -Name "Verso captaindns.com (TLS)" `
-AddressSpaces "captaindns.com" `
-RequireTLS $true `
-TlsAuthLevel DomainValidation
Nota: RequireTLS $true su un connettore di invio significa che Exchange rifiuta di inviare in chiaro verso quella destinazione. Usalo per i domini partner che supportano TLS, non per un connettore catch-all (alcuni messaggi verrebbero bloccati).
Verificare la crittografia delle tue email
Configurare TLS non basta: bisogna verificare che la crittografia funzioni effettivamente.
Da Gmail: indicatore di crittografia
Gmail mostra un lucchetto nell'header delle email. Un lucchetto grigio significa che l'email ha transitato in TLS (standard). Un lucchetto rosso con un punto esclamativo significa che l'email non è stata crittografata in transito.
Per i dettagli tecnici, clicca su "Mostra originale" in Gmail: l'header Received contiene la versione TLS e la cipher suite utilizzate.
Received: from mx1.captaindns.com (mx1.captaindns.com [203.0.113.10])
by mx.google.com with ESMTPS id abc123
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)
Da riga di comando: openssl s_client
Per testare la crittografia di un server MX dal terminale:
# Test STARTTLS sulla porta 25
openssl s_client -connect mx1.captaindns.com:25 -starttls smtp \
-servername mx1.captaindns.com 2>/dev/null | \
grep -E "Protocol|Cipher|Verify"
# Risultato atteso
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)
Se Protocol mostra TLSv1 o TLSv1.1, il tuo server utilizza un protocollo obsoleto. Se Verify return code è diverso da 0, il certificato ha un problema.
Con lo strumento CaptainDNS
L'SMTP/MX Connectivity Tester di CaptainDNS testa automaticamente tutti i MX di un dominio e verifica per ciascuno: la versione TLS negoziata, la cipher suite, la validità del certificato (scadenza, SAN, catena di fiducia) e il supporto STARTTLS. Il risultato include un punteggio per server MX con codici di diagnostica espliciti.
🎯 Piano d'azione consigliato
- Verifica la tua configurazione attuale: controlla la versione TLS e le cipher suite di ogni MX con
openssl s_cliento l'SMTP/MX Connectivity Tester - Disattiva SSL 3.0, TLS 1.0 e TLS 1.1: questi protocolli sono obsoleti (RFC 8996) e vulnerabili. TLS 1.2 è il minimo, TLS 1.3 è consigliato
- Limita le cipher suite: rimuovi RC4, DES, 3DES, MD5 e le suite senza forward secrecy (ECDHE/DHE obbligatorio)
- Implementa MTA-STS: pubblica una policy
enforceper proteggere le tue email in entrata contro gli attacchi downgrade - Attiva DANE se DNSSEC è disponibile: pubblica dei record TLSA per autenticare i certificati dei tuoi MX tramite DNS
FAQ
Qual è la differenza tra STARTTLS e SSL/TLS?
SSL e TLS sono protocolli di crittografia (SSL è il predecessore obsoleto di TLS). STARTTLS non è né SSL né TLS: è un comando SMTP che attiva la crittografia TLS su una connessione inizialmente in chiaro. Dopo STARTTLS, la connessione utilizza TLS (1.2 o 1.3), ma la fase iniziale prima del comando resta vulnerabile agli attacchi downgrade.
È ancora necessario usare SSL per SMTP?
No. SSL 2.0 e 3.0 sono vietati dalle RFC 6176 e 7568. TLS 1.0 e 1.1 sono obsoleti dalla RFC 8996. Ogni server SMTP deve usare TLS 1.2 come minimo, e TLS 1.3 di preferenza. Se un provider menziona "SSL", in realtà si riferisce a TLS.
Come forzare la crittografia TLS sulle email in uscita?
Su Postfix, configura smtp_tls_security_level = encrypt in main.cf per rifiutare qualsiasi connessione in chiaro in uscita. Su Exchange, attiva RequireTLS sul connettore di invio. Attenzione: le email verso server senza TLS verranno bloccate. Usa la modalità dane o may se devi consegnare a tutti i destinatari.
Cos'è DANE e come protegge SMTP?
DANE (DNS-based Authentication of Named Entities) permette di pubblicare l'impronta del certificato TLS di un server MX in un record DNS TLSA. Il server mittente verifica che il certificato presentato corrisponda all'impronta pubblicata, impedendo gli attacchi con certificati falsi e i downgrade. DANE richiede DNSSEC per garantire l'autenticità dei record DNS.
Come verificare se le mie email transitano in TLS?
Tre metodi: (1) in Gmail, clicca su "Mostra originale" e cerca gli header Received con la versione TLS, (2) da riga di comando, usa openssl s_client -connect mx:25 -starttls smtp per testare la negoziazione, (3) usa l'SMTP/MX Connectivity Tester di CaptainDNS per una diagnostica automatizzata di tutti i tuoi MX.
Quali cipher suite usare per SMTP nel 2026?
Per TLS 1.3: tutte le suite sono sicure (AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305). Per TLS 1.2: usa solo le suite ECDHE con AES-GCM (forward secrecy obbligatoria). Blocca RC4, DES, 3DES, MD5, le suite NULL, EXPORT e gli scambi RSA senza ECDHE/DHE.
Qual è la differenza tra MTA-STS e DANE?
MTA-STS pubblica una policy TLS tramite HTTPS (file .well-known/mta-sts.txt) che indica che il dominio richiede TLS. DANE pubblica l'impronta del certificato tramite un record DNS TLSA protetto da DNSSEC. MTA-STS è più facile da implementare (non richiede DNSSEC) ma soffre del problema TOFU (Trust On First Use). DANE offre un'autenticazione più forte ma richiede DNSSEC. Entrambi possono essere implementati simultaneamente.
Scarica le tabelle comparative
Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.
📖 Glossario
- TLS (Transport Layer Security): Protocollo di crittografia delle comunicazioni di rete. Successore di SSL, versioni attuali: TLS 1.2 e TLS 1.3 (RFC 8446).
- STARTTLS: Comando SMTP (RFC 3207) che richiede l'upgrade di una connessione in chiaro verso TLS. Non è un protocollo di crittografia di per sé.
- Implicit TLS: Modalità di connessione in cui TLS è stabilito dal primo byte, senza fase in chiaro. Utilizzato sulla porta 465 (SMTP) e sulla porta 443 (HTTPS).
- Forward secrecy: Proprietà crittografica che garantisce che la compromissione di una chiave privata non permetta di decifrare le sessioni passate. Assicurata dagli scambi di chiavi ECDHE/DHE.
- Cipher suite: Combinazione di algoritmi utilizzati per una sessione TLS: scambio di chiavi (ECDHE), autenticazione (RSA/ECDSA), crittografia (AES-GCM) e hashing (SHA384).
- DANE: DNS-based Authentication of Named Entities (RFC 7672 per SMTP). Permette di autenticare il certificato TLS di un server tramite un record DNS TLSA protetto da DNSSEC.
- MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Policy pubblicata tramite HTTPS che forza i server mittenti a usare TLS con un certificato valido.
- Attacco downgrade: Attacco di rete che forza una connessione a usare un protocollo meno sicuro, tipicamente rimuovendo l'annuncio STARTTLS o modificando la negoziazione TLS.
- TOFU: Trust On First Use. Modello di sicurezza in cui la fiducia viene stabilita alla prima interazione. MTA-STS soffre di questo problema: il primo recupero della policy è vulnerabile.
Verifica la crittografia TLS dei tuoi server MX: usa il nostro SMTP/MX Connectivity Tester per testare la versione TLS, le cipher suite e la validità del certificato di ogni MX, in pochi secondi.
📚 Guide SMTP e connettività email correlate
- Le porte SMTP spiegate: 25, 465, 587, 2525: ruolo, crittografia e casi d'uso di ogni porta SMTP
- Come testare la connettività SMTP dei tuoi server MX: guida passo dopo passo con telnet e openssl
- Porta 25 bloccata: diagnostica e soluzioni per provider (prossimamente)
