Attacchi di downgrade SMTP: come funzionano e come proteggersi

⚡TL;DR

• SMTP trasmette le email in chiaro per impostazione predefinita. STARTTLS aggiunge la crittografia, ma resta vulnerabile agli attacchi di downgrade (STARTTLS stripping)
• Un attaccante posizionato sulla rete può rimuovere l'opzione STARTTLS dalla risposta del server, forzando l'invio in chiaro senza che il mittente se ne accorga
• MTA-STS (RFC 8461) e DANE/TLSA (RFC 7672) impongono la crittografia TLS obbligatoria e bloccano questi attacchi
• Ospitate la vostra policy MTA-STS gratuitamente con CaptainDNS: due record DNS bastano per proteggere i vostri domini in meno di 5 minuti

Ogni giorno, miliardi di email circolano tra server SMTP. La maggior parte utilizza STARTTLS per crittografare la connessione. Ma questa crittografia è opportunistica: se il server remoto non risponde alla richiesta di crittografia, il messaggio viene inviato in chiaro. Un attaccante posizionato sulla rete può forzare questo comportamento con un semplice pacchetto di rete.

Gli attacchi di downgrade SMTP, detti anche STARTTLS stripping, sfruttano questa debolezza. Permettono di intercettare email in chiaro, anche quando entrambi i server supportano la crittografia TLS. Il problema: né il mittente né il destinatario vengono informati dell'attacco.

Questo articolo descrive il meccanismo tecnico di questi attacchi, le loro varianti, il loro impatto reale secondo i dati di Google, e le soluzioni concrete per proteggere i vostri domini. Se gestite server email o la sicurezza di un dominio, questa guida è per voi.

Come SMTP trasmette le email

SMTP (Simple Mail Transfer Protocol, RFC 5321) è il protocollo utilizzato per instradare le email tra server. Progettato nel 1982, non prevede alcuna crittografia nativa. Ogni messaggio transita in chiaro tra il server mittente e il server destinatario.

STARTTLS: una crittografia opportunistica

Nel 2002, la RFC 3207 introduce STARTTLS. Questo meccanismo permette a due server SMTP di negoziare una connessione TLS dopo l'instaurazione della connessione iniziale in chiaro.

Il processo si svolge così:

1. Il server mittente apre una connessione TCP sulla porta 25
2. Il server destinatario risponde con le sue capacità, tra cui 250 STARTTLS
3. Il server mittente invia il comando STARTTLS
4. I due server negoziano una connessione TLS
5. L'email viene trasmessa in modo crittografato

S: 220 mx.captaindns.com ESMTP
C: EHLO mail.captaindns.com
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← il server annuncia il supporto TLS
S: 250 OK
C: STARTTLS            ← il client richiede la crittografia
S: 220 Ready to start TLS
[Negoziazione TLS]
C: EHLO mail.captaindns.com
[Trasmissione crittografata dell'email]

Perché "opportunistica" è un problema

La parola chiave è opportunistica. Se il comando STARTTLS fallisce o non viene proposto, il server mittente invia l'email in chiaro senza avvisare nessuno. È una scelta progettuale: la RFC 3207 privilegia la consegna del messaggio rispetto alla sua riservatezza.

Questa decisione crea la falla sfruttata dagli attacchi di downgrade.

Anatomia di un attacco di downgrade SMTP

Un attacco di downgrade SMTP, o STARTTLS stripping, consiste nell'impedire la negoziazione TLS tra due server email. L'attaccante forza il ritorno a una connessione in chiaro.

Come funziona lo STARTTLS stripping?

L'attaccante deve posizionarsi sul percorso di rete tra i due server (man-in-the-middle). Intercetta i pacchetti TCP e modifica la risposta del server destinatario:

1. Il server mittente invia EHLO al server destinatario
2. Il server destinatario risponde con 250 STARTTLS tra le sue capacità
3. L'attaccante intercetta questa risposta e rimuove la riga 250 STARTTLS
4. Il server mittente riceve una risposta senza menzione di STARTTLS
5. Il server mittente conclude che il destinatario non supporta la crittografia
6. L'email viene inviata in chiaro
7. L'attaccante legge il contenuto del messaggio

[Risposta originale del server destinatario]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← presente
S: 250 OK

[Risposta modificata dall'attaccante]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250 OK              ← STARTTLS rimosso

L'attacco è invisibile per entrambi i server. Il server mittente pensa che il destinatario non supporti TLS. Il server destinatario non sa che un'email gli è stata inviata in chiaro.

Chi può lanciare questo attacco?

Qualsiasi entità posizionata sul percorso di rete:

• Provider di accesso internet (ISP): controllano l'instradamento del traffico
• Operatori di reti intermedie: punti di scambio internet (IXP)
• Attaccanti sulla rete locale: Wi-Fi pubblico, rete aziendale compromessa
• Attori statali: sorveglianza di massa documentata in alcuni paesi

Varianti di attacchi sul trasporto email

Lo STARTTLS stripping è la variante più nota, ma altri attacchi prendono di mira il trasporto email.

Spoofing DNS dei record MX

L'attaccante falsifica la risposta DNS per i record MX del dominio destinatario. Il server mittente invia quindi l'email verso un server falso controllato dall'attaccante.

; Risposta DNS legittima
captaindns.com. MX 10 mx.captaindns.com.

; Risposta DNS falsificata dall'attaccante
captaindns.com. MX 10 mx.attaccante.com.

DNSSEC protegge da questo attacco firmando crittograficamente le risposte DNS.

Attacco al certificato TLS

Anche se STARTTLS viene negoziato, SMTP non valida il certificato del server destinatario per impostazione predefinita. Un attaccante può presentare un certificato auto-firmato o non valido, e il server mittente accetterà la connessione senza verifica.

MTA-STS e DANE impongono la validazione del certificato, bloccando questa variante.

Dirottamento BGP

Un attaccante annuncia false rotte BGP per reindirizzare il traffico di rete verso i propri apparati. Questo attacco colpisce l'infrastruttura di rete e può riguardare tutto il traffico, non solo le email.

Impatto reale: chi è interessato?

I dati di Google

Il Transparency Report di Google sulla crittografia delle email in transito rivela dati concreti:

• Oltre il 90% delle email in entrata verso Gmail sono crittografate con TLS
• Oltre il 90% delle email in uscita da Gmail utilizzano TLS
• Alcune regioni e alcuni provider restano sotto il 70%

Questi dati mostrano che la crittografia SMTP è progredita, ma che persistono delle lacune. Ogni email non crittografata rappresenta un'opportunità per un attacco di downgrade.

Settori più esposti

Settore	Rischio	Motivo
Sanità	Elevato	Dati dei pazienti, conformità HIPAA/GDPR
Finanza	Elevato	Informazioni finanziarie sensibili
Legale	Elevato	Segreto professionale, riservatezza del cliente
Pubblica amministrazione	Medio	Dati dei cittadini, processi interni
PMI	Medio	Infrastruttura email spesso sotto-configurata

Attacchi documentati

Ricerche pubblicate da EFF e APNIC hanno documentato casi di STARTTLS stripping su larga scala da parte di operatori di rete in diversi paesi. Questi attacchi non prendono di mira un dominio specifico: intercettano tutto il traffico SMTP che transita attraverso l'infrastruttura compromessa.

Come proteggersi dagli attacchi di downgrade

Quattro meccanismi complementari permettono di proteggere il trasporto email.

MTA-STS (RFC 8461): la crittografia TLS obbligatoria

MTA-STS permette a un dominio di pubblicare una policy che impone la crittografia TLS ai server mittenti. La policy è ospitata su un server HTTPS, un canale separato e autenticato che l'attaccante non può compromettere con lo STARTTLS stripping.

Funzionamento:

1. Il server mittente scopre il record TXT _mta-sts.captaindns.com
2. Scarica la policy da https://mta-sts.captaindns.com/.well-known/mta-sts.txt
3. La policy indica i server MX autorizzati e la modalità (testing/enforce)
4. In modalità enforce, il server rifiuta di inviare in chiaro

Vantaggio: non richiede DNSSEC. Funziona con qualsiasi registrar.

Limite: la prima richiesta (prima della messa in cache) resta vulnerabile (TOFU, Trust On First Use).

DANE/TLSA (RFC 7672): il certificato ancorato nel DNS

DANE pubblica l'impronta del certificato TLS direttamente in un record TLSA del DNS. Il server mittente verifica che il certificato presentato corrisponda a quello dichiarato nel DNS.

Vantaggio: nessun TOFU. La verifica è immediata fin dalla prima connessione.

Limite: richiede DNSSEC su tutta la catena DNS, il che limita l'adozione.

TLS-RPT (RFC 8460): la visibilità sugli errori

TLS-RPT non blocca gli attacchi, ma li rende visibili. I server mittenti che supportano TLS-RPT inviano report giornalieri sugli errori di negoziazione TLS.

Questi report permettono di rilevare:

• Tentativi di downgrade
• Certificati scaduti o non validi
• Problemi di configurazione sui vostri server MX

Configurate TLS-RPT con il nostro generatore TLS-RPT per ricevere questi report.

DNSSEC: la protezione del DNS

DNSSEC firma crittograficamente le risposte DNS, impedendo lo spoofing dei record MX. È la base di DANE, ma rafforza anche la sicurezza di MTA-STS proteggendo la risoluzione del record _mta-sts.

🎯 Piano d'azione consigliato

1. Verificate la vostra configurazione attuale: utilizzate il verificatore MTA-STS per analizzare lo stato del vostro dominio
2. Attivate MTA-STS in modalità testing: ospitate la vostra policy gratuitamente con CaptainDNS e monitorate i report TLS-RPT per 1-2 settimane
3. Configurate TLS-RPT: ricevete i report di errore TLS per individuare i problemi prima che impattino le vostre email
4. Passate alla modalità enforce: quando i report confermano che tutto funziona, attivate la modalità enforce per bloccare le connessioni non crittografate
5. Valutate DANE: se il vostro registrar e il vostro hosting DNS supportano DNSSEC, aggiungete record TLSA per una protezione senza TOFU

---

Proteggete le vostre email dagli attacchi di downgrade ora: ospitate la vostra policy MTA-STS gratuitamente con CaptainDNS. Due record DNS, zero server web da gestire.

---

FAQ

Cos'è un attacco di downgrade SMTP?

Un attacco di downgrade SMTP (o STARTTLS stripping) consiste nell'impedire la negoziazione della crittografia TLS tra due server email. L'attaccante, posizionato sulla rete, rimuove l'opzione STARTTLS dalla risposta del server destinatario. Il server mittente invia quindi l'email in chiaro, permettendo all'attaccante di leggere il contenuto del messaggio.

Come si rileva un attacco di downgrade sulle email?

Configurate TLS-RPT (RFC 8460) per il vostro dominio. I server mittenti compatibili invieranno report giornalieri che elencano gli errori di negoziazione TLS. Un aumento improvviso degli errori può indicare un tentativo di downgrade. Attivate anche MTA-STS in modalità testing per ricevere report senza bloccare la consegna.

MTA-STS protegge da tutti gli attacchi di downgrade?

MTA-STS protegge dallo STARTTLS stripping e dagli attacchi ai certificati TLS. Non protegge dallo spoofing DNS dei record MX (utilizzate DNSSEC per quello) né dal dirottamento BGP. Per una protezione completa, combinate MTA-STS con DNSSEC e, se possibile, DANE/TLSA.

Qual è la differenza tra MTA-STS e DANE?

MTA-STS pubblica una policy tramite HTTPS e funziona senza DNSSEC. DANE ancora il certificato TLS nel DNS tramite record TLSA e richiede DNSSEC. MTA-STS soffre del problema TOFU (la prima richiesta non è protetta). DANE offre una verifica immediata. I due meccanismi sono complementari.

STARTTLS è sufficiente per proteggere le email?

No. STARTTLS crittografa la connessione in modo opportunistico, ma non protegge dagli attacchi di downgrade né dai certificati non validi. Un attaccante di rete può rimuovere l'opzione STARTTLS o presentare un certificato falso. MTA-STS o DANE sono necessari per imporre la crittografia TLS.

I grandi provider come Gmail e Outlook sono vulnerabili?

Gmail e Microsoft 365 supportano MTA-STS come server mittenti: verificano e rispettano le policy MTA-STS dei domini destinatari. Se il vostro dominio pubblica una policy MTA-STS in modalità enforce, Gmail e Outlook rifiuteranno di inviare in chiaro verso i vostri server, anche in caso di tentativo di downgrade.

È necessario attivare MTA-STS e DANE contemporaneamente?

Non è obbligatorio, ma è consigliato se la vostra infrastruttura lo permette. MTA-STS è più semplice da implementare (non richiede DNSSEC) e copre la maggior parte dei server mittenti. DANE offre una sicurezza aggiuntiva (nessun TOFU) per i server che lo supportano. I due meccanismi coesistono senza conflitti.

📖 Glossario

• STARTTLS: estensione SMTP (RFC 3207) che permette di negoziare una connessione TLS dopo l'instaurazione di una connessione in chiaro sulla porta 25.
• STARTTLS stripping: attacco che consiste nel rimuovere l'annuncio STARTTLS dalla risposta del server per impedire la crittografia.
• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Policy HTTPS che impone la crittografia TLS per la ricezione di email.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672). Meccanismo che ancora il certificato TLS nel DNS tramite record TLSA.
• TLS-RPT: SMTP TLS Reporting (RFC 8460). Meccanismo di report sugli errori di negoziazione TLS tra server email.
• TOFU: Trust On First Use. Modello di sicurezza in cui la prima connessione non è verificata, ma le connessioni successive vengono validate rispetto alla prima.
• DNSSEC: DNS Security Extensions. Sistema di firme crittografiche che autentica le risposte DNS e ne impedisce la falsificazione.

📚 Guide correlate sulla sicurezza del trasporto email

• MTA-STS vs DANE: quale protocollo scegliere per proteggere il trasporto email? (in arrivo)
• Da testing a enforce: strategia di implementazione MTA-STS progressiva (in arrivo)

Fonti

• RFC 5321 - Simple Mail Transfer Protocol
• RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities
• Google Transparency Report - Email encryption in transit