Tutto quello che devi sapere sulla sicurezza SMTP

Quali sono le minacce alla sicurezza SMTP?

C’è una serie di cose di cui essere consapevoli quando si trasmette anche una piccola quantità di e-mail. Ecco le più comuni:

Accesso non autorizzato alle tue e-mail e perdita di dati

I criminali informatici potrebbero cercare di accedere al tuo server SMTP attraverso il quale passa tutta la posta in uscita. Questo viene fatto rompendo le vostre procedure di autenticazione con metodi più o meno sofisticati. Una volta entrati, i visitatori indesiderati possono accedere alle vostre e-mail e usarle a loro vantaggio, per esempio facendo trapelare i dati dei vostri utenti o rubando informazioni riservate che stavate inviando ai colleghi.

Spam e Phishing

Quando i truffatori sono in grado di accedere al tuo server SMTP, è anche probabile che lo usino per inviare messaggi non autorizzati sia ai tuoi contatti che ad account esterni (questo è noto come utilizzo del tuo server come Open Relay). Questo viene fatto per inviare spam che, quando viene inviato dal tuo dominio legittimo e (probabilmente) ben noto, potrebbe avere abbastanza successo. O, ancora peggio, il vostro server può essere usato per inviare email malevole, per esempio chiedendo ai vostri utenti di condividere le loro credenziali di accesso o i numeri di carta di credito.

Malware

Gli aggressori usano comunemente le vulnerabilità dell’SMTP per diffondere software malevolo ai destinatari delle vostre email ma anche nella vostra stessa infrastruttura. Questi possono essere virus, cavalli di Troia o qualsiasi altro tipo di worm che vengono poi utilizzati per ostacolare le operazioni, ottenere l’accesso ai server, modificare i privilegi e accedere a dati sicuri. Se non viene combattuto con sufficiente forza, il malware potrebbe continuare a diffondersi, infettando sempre più server e utenti.

Attacchi DoS

Se tutto ciò non sembrasse grave, i criminali informatici possono anche utilizzare il vostro server SMTP per eseguire un attacco Denial-of-Service (DoS). Questo significa fondamentalmente inondare altri server con una quantità enorme di e-mail per influenzare le loro prestazioni o addirittura causare un crash. Il DoS può anche essere usato per inondare una casella di posta per nascondere eventuali messaggi di avvertimento sulle violazioni della sicurezza di un server. Qualunque sia lo scopo di un attacco DoS, non è mai buono.

Questi sono solo alcuni esempi. Ma c’è un modo per rendere sicura la nostra connessione ed evitare un simile destino?

Come rendere sicuro SMTP? Cos’è SSL/TLS?

Anche i provider di posta elettronica hanno notato queste vulnerabilità e fin dai primi giorni della posta elettronica hanno iniziato ad aggiungere livelli di sicurezza al protocollo SMTP. SSL (Secure Sockets Layer) è stato sviluppato nel 1995 da Netscape. La prima versione (1.0) non fu mai condivisa con il pubblico a causa delle sue vulnerabilità, ma la v2.0 divenne rapidamente una caratteristica indispensabile per ogni client di posta elettronica che si rispetti.

Alcuni anni dopo, un nuovo standard chiamato TLS (Transport Layer Security) fu rilasciato e da allora è stato costantemente migliorato. SSL è stato infine deprecato nel 2015 e TLS nella sua versione 1.3 (l’ultima al momento in cui scriviamo) è ora considerato uno standard industriale. Anche se è ancora possibile utilizzare le ultime versioni di SSL, non è raccomandato a causa di varie vulnerabilità che sono state scoperte. Nota, comunque, che i nomi ‘SSL’ e ‘TLS’ sono usati in modo intercambiabile e spesso un fornitore di servizi potrebbe riferirsi a SSL mentre, in realtà, usa TLS.

SSL/TLS fornisce un modo per crittografare i messaggi scambiati tra il tuo client di posta e il server di posta. Quando gli hacker violano la sicurezza di SMTP, vedranno solo una serie di caratteri apparentemente casuali che sostituiscono il contenuto delle e-mail. Possono ancora usare i loro nuovi poteri per causare danni, ma almeno tu e i dati dei tuoi contatti sarete protetti.

TLS supporta anche l’uso di certificati digitali che forniscono un ulteriore livello di sicurezza. Pensate a questi certificati come a ID o passaporti con cui ogni parte del processo si identifica. Questo processo è chiamato Handshake.

Come funziona l’Handshake?

Abbiamo già stabilito che qualsiasi email inviata su SMTP viaggia nel seguente modo:

1. client e-mail del mittente
2. server e-mail del mittente
3. server e-mail del destinatario
4. client e-mail del destinatario

Quando un’e-mail attraversa una di queste fasi, viene avviata una connessione e, quando si usa TLS, entrambe le parti devono stabilire la fiducia reciproca. Questo è chiamato Handshake. Il client del mittente vuole sapere che sta comunicando con il proprio server, non con qualcosa che gli assomiglia ma che in realtà è una trappola. Anche il server vuole conoscere meglio l’altro server prima di affidargli un messaggio di valore. Solo dopo aver controllato le carte dell’altro e stabilito alcune regole di cooperazione, procederanno con la trasmissione.

L’handshake consiste in diversi passi e va come segue:

1. Il client di posta elettronica invia un messaggio di “ciao” in cui dichiara con quali versioni SSL/TLS è compatibile e i tipi di crittografia che supporta.
2. Il server risponde “ciao” ma la sua risposta è diversa. Include il suo certificato digitale TLS e la sua chiave di crittografia pubblica.
3. Il client email verifica se il certificato è legittimo. Se è così, procede con…
4. la generazione di una Shared Secret Key con la chiave di crittografia pubblica del server che ha appena ricevuto due passi fa.
5. Il server decifra quindi la Shared Secret Key ricevuta.
6. Se tutto è andato liscio, entrambi i siti possono ora utilizzare questa Shared Secret Key per cifrare e decifrare i messaggi inviati tra loro.

Se siete interessati ad una descrizione molto più dettagliata di questo incontro, date un’occhiata a questa interessante analisi di ogni byte usato in un handshake TLS.

Nota come la crittografia di questa interazione sia stata, all’inizio, asincrona (entrambe le parti stavano usando chiavi diverse). Nel corso dell’handshake, sono riusciti a stabilire che l’uso della Shared Secret Key era la strada da percorrere e la crittografia è diventata sincrona (e, di conseguenza, più veloce).

Inspetta le tue e-mail

TLS opportunistico vs forzato. STARTTLS spiegato.

Perché una stretta di mano avvenga, la connessione tra le due parti deve essere stabilita. TLS viene fornito con la scelta di due diversi approcci per stabilire la comunicazione:

Con TLS opportunistico (esplicito), un client di posta elettronica durante un Handshake dirà al server di posta elettronica che vuole parlare ma in privato. In altre parole, suggerirà un cambiamento da una connessione SMTP semplice e non criptata a una connessione criptata TLS. Se il tentativo fallisce, tuttavia, inizierà la trasmissione in chiaro, senza alcuna crittografia applicata.

Con Forced (Implicit) TLS, un client di posta elettronica chiederà di parlare in privato (e di usare la connessione criptata) Un server di posta elettronica risponderà se tale accordo funziona per lui o no. Se non è compatibile con la versione di TLS usata dal client, non supporta affatto TLS o la connessione fallisce, la trasmissione verrà interrotta e l’email non verrà spostata ulteriormente.

STARTTLS è il comando SMTP usato per avviare il passaggio a una connessione cifrata quando si usa TLS Opportunistico. Nonostante il suo nome, può anche essere usato per avviare un passaggio a SSL se solo questo protocollo è abilitato per entrambe le parti.

Virtualmente tutti i client di posta elettronica che forniscono la crittografia TLS ai loro utenti offrono TLS opportunistico di default. Il TLS forzato è spesso possibile da abilitare su richiesta dell’utente, ma assicuratevi di considerare prima i pro e i contro di un tale approccio. La scelta si riduce al fatto che si voglia garantire la massima deliverability (TLS opportunistico) o la massima privacy (TLS forzato). Con il primo approccio, si rischia di inviare alcune (probabilmente molto poche) email senza crittografia. Con il secondo, la tua deliverability potrebbe soffrire un po’. La scelta è vostra.

Crittografia end-to-end

Un altro approccio per proteggere la comunicazione via email è la crittografia end-to-end. Come abbiamo detto sopra, SSL/TLS crittografa le email solo durante il loro percorso tra il client di posta elettronica del mittente e il suo server di posta elettronica. Un messaggio viene poi decrittato e viaggia fino alla casella di posta del destinatario senza alcuna crittografia, essendo vulnerabile agli attacchi.

I metodi di crittografia end-to-end forniscono un approccio diverso. Un messaggio viene criptato sul dispositivo del mittente prima ancora di essere inviato da un client. Poi viaggia attraverso la rete (spesso crittografato con TLS durante il tragitto, dandogli ulteriore sicurezza). Quando arriva al client del destinatario, viene decriptato dal destinatario. Durante tutto il corso del trasferimento, il messaggio è sempre criptato. Anche se cade vittima di un dirottamento, i dati saranno inutilizzabili per un ladro.

Per far funzionare la crittografia end-to-end, entrambe le parti devono essere compatibili con un dato metodo di crittografia e avere le chiavi giuste per criptare/decriptare un messaggio. Diciamo che Charlie (un mittente) vorrebbe inviare un messaggio a Mary (un destinatario) usando la crittografia end-to-end. Ecco come sarebbe il processo:

1. Mary genera una chiave pubblica e una privata. D’ora in poi, condividerà la chiave pubblica con chiunque voglia mandarle un messaggio, ma manterrà la sua chiave privata… privata.
2. Charlie ha saputo della chiave pubblica di Mary e la usa per criptare il suo messaggio. Il contenuto di un’email viene trasformato in qualcosa chiamato testo cifrato, quello che sembra un insieme casuale di caratteri.
3. Il messaggio viene inviato dal client di posta di Charlie fino al client di Mary, seguendo le procedure standard. Se qualcuno vedesse il messaggio durante il tragitto, vedrebbe solo un testo cifrato.
4. Il messaggio arriva e Mary usa la sua chiave privata per decifrare il messaggio.

Mary ha capito che ciò che Charlie ha così attentamente criptato sono i biglietti aerei per il suo viaggio di compleanno a sorpresa. Che emozione! Subito dopo, richiede la chiave pubblica di Charlie, scrive la sua risposta e la cripta con la chiave ricevuta. Lui saprà cosa fare, pensò.

I metodi di crittografia end-to-end più popolari

S/MIME

Secure/Multipurpose Internet Mail Extensions è un metodo di crittografia molto popolare. Si basa sulla crittografia asincrona e di nuovo, un insieme di una chiave pubblica e una privata. Come nel caso di TLS, un mittente che vuole criptare un messaggio utilizza la chiave pubblica del destinatario. Quando un messaggio viene ricevuto, un destinatario utilizza la propria chiave privata per vedere il contenuto di un’e-mail. S/MIME permette anche di aggiungere una firma digitale ad un’email, certificando che sei davvero un mittente. Questo aiuta a prevenire lo spoofing. Questo metodo può essere facilmente aggiunto ai popolari client di posta elettronica come Gmail o Outlook.

PGP

Pretty Good Privacy (bisogna amare il nome!) è probabilmente il metodo di crittografia più popolare ed è stato in circolazione dai primi anni ’90. Non è solo usato per crittografare le e-mail, ma anche file, directory e intere partizioni del disco. Per quanto riguarda le e-mail, il modo in cui funziona non è diverso da S/MIME. Si basa anche sulla combinazione di chiavi private e pubbliche, ma un dato criptato è ancora più difficile da decifrare. PGP usa il mix di compressione dei dati, crittografia a chiave pubblica e hashing per ottenere una stringa quasi indistruttibile di caratteri che rappresenta i dati protetti. Per convalidare il mittente, la sua chiave privata è anche usata per certificare la proprietà di un account. Dal 1997, PGP è disponibile come standard non proprietario chiamato OpenPGP e tutti sono liberi di implementarlo nel loro software.

Bitmessage

Bitmessage è spesso definito come il “bitcoin delle comunicazioni” e i suoi utenti affermano che è molto più sicuro e facile da usare dei due metodi precedenti che abbiamo trattato. Per inviare messaggi in questo modo, ogni utente crea un indirizzo Bitmessage che consiste di due chiavi – una pubblica e una privata. Come in tutti i casi precedenti, viene usata una chiave pubblica per criptare i messaggi e una privata per cifrarli. Quando si decifra un messaggio, vengono applicati vari processi aggiuntivi per certificare che si è effettivamente il mittente di un messaggio. Questi possono includere l’hashing, la mappatura dei dati, la “firma” del messaggio e la fornitura di una “proof-of-work”.

Infine, un messaggio viene inviato a una rete pubblica di migliaia di utenti. Ogni membro scarica ogni singolo messaggio ricevuto, ma è in grado di decifrare solo quelli criptati con la propria chiave pubblica. Questo mantiene sia il corpo del messaggio che i metadati assolutamente sicuri e virtualmente impossibili da penetrare sia per gli hacker occasionali che per le sofisticate agenzie governative. Inutile dire che Bitmessage ha avuto una crescita esplosiva dopo lo scandalo del 2013 che ha rivelato le pratiche di sorveglianza delle e-mail della NSA.

I metodi di crittografia end-to-end sono certamente più sicuri di TLS e dovrebbero essere utilizzati quando si inviano dati riservati. Mentre implementare Bitmessage per inviare rapporti settimanali al vostro supervisore potrebbe essere un po’ eccessivo, sia S/MIME che PGP sono da prendere in considerazione. Tieni sempre a mente che entrambe le parti devono essere compatibili con il metodo usato, altrimenti l’altra parte potrebbe non capire quello che avevi veramente in mente.

Altre considerazioni

Una volta che hai impostato TLS e/o la crittografia end-to-end, vale anche la pena dare un’occhiata a come dotare le tue email di metodi di autenticazione aggiuntivi. Sono usati per prevenire lo spoofing della tua comunicazione e anche per migliorare la deliverability delle tue email.

I metodi più comunemente usati sono SPF e DKIM.

SPF è utilizzato per identificare un mittente caricando nei record DNS gli indirizzi IP utilizzati per inviare e-mail per conto di un determinato dominio. Il client ricevente, prima di consegnare un messaggio, controlla se è stato usato l’indirizzo giusto e potrebbe scartare un messaggio se rileva delle anomalie.

DKIM, d’altra parte, è un certificato digitale che viene inviato con una e-mail. Permette al destinatario di un messaggio di verificare se il contenuto di un’email o le intestazioni non sono state modificate (falsificate) durante una trasmissione. Un test DKIM fallito influisce sulla deliverability di un messaggio e potrebbe essere un motivo per cui salta una casella di posta.

DMARC è il più sofisticato di tutti e tre i metodi e sfrutta gli altri due metodi per eseguire controlli aggiuntivi. È l’unico metodo che, a parte l’esecuzione di un test, può anche suggerire a un server ricevente cosa fare se un messaggio non supera un controllo.

Vale la pena di avere tutti e tre i metodi impostati per il tuo dominio. Li copriamo tutti in dettaglio in articoli separati, controllateli ai link qui sopra.

Infine, vale la pena controllare se il vostro server SMTP funziona come previsto. Potete farlo via Telnet o usare un certo numero di strumenti che offrono tali controlli. Vedi il nostro articolo sui test del server SMTP.

Se stai cercando un modo per testare le email in modo sicuro, non hai bisogno di inviarle a utenti reali. Mailtrap crea un falso server SMTP che cattura tutte le tue email di prova senza il rischio di spammare gli utenti reali. È quindi possibile visualizzare in anteprima i messaggi e inoltrarli alle caselle di posta reali prima che vengano implementati in una produzione.

Prova Mailtrap gratuitamente

Sommario

Abbiamo iniziato dicendo quanto sia vulnerabile la connessione SMTP. Fortunatamente, ci sono molti metodi che possono renderla davvero sicura e molti sono già stati implementati in vari client di posta elettronica. Speriamo che vi sia piaciuto leggere questo articolo, date un’occhiata agli altri pezzi del nostro blog dove si parla molto di test e invio di email. Fino alla prossima volta!