EFF ha denunciato il fatto che alcuni provider americani e tailandesi impediscono ai client di posta elettronica di inviare messaggi su un canale sicuro.
Quelli segnalati da EFF sono i casi di cui si ha evidenza, ma è possibile che altri provider o altri fornitori di servizi di connettività, anche occasionale via WiFi, implementino le medesime politiche lesive della privacy.
Quello che viene bloccato è l’equivalente HTTPS del protocollo SMTP utilizzato per inviare la posta elettronica dal client (posta in uscita) oppure per trasmettere i messaggi email tra server differenti.
Il blocco in questione non ha nulla a che fare con eventuali metodi di cifratura del testo del messaggio. Se il testo del messaggio è cifrato, tale resta.
Quello che viene impedito è che tutto il dialogo con il server di posta elettronica sia cifrato e, quindi, impossibile da analizzare, spiare o archiviare in chiaro. Nel caso di un messaggio cifrato, con questa pratica scorretta diventano palesi i metadati: nome del mittente, del destinatario, data e ora del messaggio, credenziali utilizzate, eccetera.
Questo blocco può essere applicato in un qualsiasi punto del percorso della mail. Se viene applicato alla connettività del client, questo manderà la mail in chiaro al suo server della posta in uscita; se viene applicato alla connettività del server finale o di un server in transito il dialogo tra i server sarà in chiaro e non cifrato.
Naturalmente è possibile applicare su comando questo filtro, quindi un servizio di hosting su cui ci sono dei mail server potrebbe attivare il filtro solamente, ad esempio, per un’ora e registrare tutte le mail in transito durante quel periodo di tempo. In questo caso sarebbe molto difficile accorgersi del misfatto se non analizzando i log del server.
Il metodo con cui viene bloccato il dialogo cifrato è molto semplice.
A differenza di HTTP in cui c’è una porta dedicata (443) alle trasmissioni cifrate e una dedicata alle trasmissioni in chiaro (80), il protocollo SMTP prevede sempre e comunque, indipendentemente dalla porta su cui è configurato, un dialogo iniziale in chiaro.
Di seguito si parla di client e di server SMTP. In questo contesto i due termini sono da intendersi a livello di ruolo. Quando un client di posta elettronica invia un messaggio il ruolo è ovvio. Quando due MTA (questo sarebbe il termine corretto per indicare un “server” SMTP) si collegano tra di loro uno è client (quello che invia), l’altro è server (quello che riceve).
La parte iniziale di un dialogo SMTP tipico senza filtri o blocchi di sorta è fatta così (le righe che iniziano con un numero sono le risposte del server, EHLO è il comando inviato dal client)
220 mail.siamogeek.com ESMTP Postfix EHLO client.siamogeek.com 250-mail.siamogeek.com 250-PIPELINING 250-SIZE 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
Teoricamente il client dovrebbe dare il comando EHLO solamente se nella prima riga c’è la stringa ESMTP, altrimenti dovrebbe dare il comando HELO. EHLO provoca come risposta l’elenco dei comandi avanzati supportati da quel server, AUTH è ripetuto due volte per far fronte ad un errore di implementazione da parte di alcuni vecchi programmi di Microsoft.
Se il client vede STARTTLS tra i comandi avanzati è sua facoltà (ma non è obbligato, a meno di sue configurazioni particolari) iniziare una sessione TLS sicura.
Se tra client e server c’è un firewall, come ad esempio un CISCO PIX/ASA, che impedisce il dialogo cifrato la medesima sessione tra client e server diventa questa
220 ****************************** EHLO client.siamogeek.com 250-mail.siamogeek.com 250-PIPELINING 250-SIZE 250-ETRN 250-XXXXXXXA 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
La riga di benvenuto del server viene oscurata con una serie di asterischi anche per impedire che il client legga ESMTP. Tuttavia molti client sanno che il PIX/ASA maschera la riga di benvenuto in questo modo e provano ad inviare il comando EHLO; la risposta del server, però al posto di STARTTLS riporta XXXXXXXA.
Se il client dovesse tentare comunque di inviare il comando STARTTLS avrebbe poco successo:
STARTTLS 502 5.5.2 Error: command not recognized
perché il PIX/ASA converte STARTTLS in XXXXXXXA anche quando il client invia il comando al server, per il quale XXXXXXXA non ha alcun significato.
Questo metodo di blocco delle connessioni cifrate è molto insidioso perché, in condizioni normali, è poco rilevabile o aggirabile.
Se il client dispone di questa possibilità, potrebbe essere configurato per stabilire solamente sessioni TLS con il proprio server della posta in uscita. Questo impedirebbe che fornitori occasionali di connettività forzino le connessioni in chiaro. Un’opzione simile dovrebbe essere presente in ogni client di posta dei dispositivi mobili.
Gli MTA, se lo permettono, potrebbero essere configurati per stabilire solamente sessioni TLS con una serie di MTA di cui il SysAdmin è certo che supportino TLS, ma è un lavoro improbo e comunque poco efficace: se qualcuno vuole monitorare il traffico della destinazione della mail è sufficiente aggiungere un MTA al percorso della mail. L’MTA intermedio accetta sessioni TLS dal mondo, ma quando le invia al destinatario finale lo fa tramite un firewall che blocca TLS.
Lascia un commento