Cosa devi sapere sull’uso di SSL/TLS per crittografare le connessioni dei tuoi server di posta elettronica

Quando mi è stato proposto
l’argomento per questo post, ho accettato volentieri. Ecco qualche parafrasi
di come è andata:

“Saresti in grado di
scrivere un post sull’importanza di TLS nei server di posta elettronica?” ha chiesto Patrick.

“Certo,” ho detto.

Whew, è stata una conversazione pazzesca
da rivivere! Come un turbine!

Poi ho iniziato a pensarci un po’. Ci sono davvero server di posta elettronica là fuori che non usano la crittografia per il transito? Non sto parlando di crittografia end-to-end come abbiamo trattato in passato (S/MIME, PGP, ecc). Mi riferisco alla crittografia da server a server o a tutto ciò che sta in mezzo per proteggere i dati lungo il percorso di attraversamento.

Sicuramente, al giorno d’oggi, nessuno lascerebbe la sua posta in entrata/uscita in chiaro che attraversa Dio sa quale percorso per essere intercettata e sfruttata. Molte persone usano servizi di posta elettronica e non è possibile che escludano la crittografia del transito dal loro servizio. Le violazioni dei dati costano milioni in
citazioni legali e perdita di affari e vergogna……Hmmmm…..

Sono tornato da Patrick
con una domanda.

“Abbiamo statistiche
o informazioni sui server di posta elettronica che non utilizzano la crittografia? La mia ipotesi è che sarebbero
bassi. In altre parole, cosa ti ha spinto a chiedermi di questo articolo?”

Patrick ha risposto: “Io
in realtà no. Ho pensato che sarebbe stato un buon argomento considerando l’importanza
della posta elettronica e tutti gli aspetti necessari per la sicurezza.”

OK. Questo ha senso. Probabilmente ci sono alcuni server di posta elettronica là fuori che non lo usano affatto, anche se senza dubbio una percentuale molto più grande può usare protocolli non aggiornati o certificazioni scadute e può avere solo bisogno di una rinfrescata.

Questo articolo andrà
oltre al punto in cui ci troviamo con la crittografia delle email e del transito per assicurarsi che stiate
operando ad un livello di sicurezza ottimale che è disponibile.

Crittografia nei server di posta elettronica

A questo punto, probabilmente abbiamo una comprensione generale di come funziona TLS, ma riassumiamo nel caso tu sia nuovo a questo.

La persona A vuole inviare una comunicazione
sicura all’uomo B. La persona A e l’uomo B hanno un certificato
prestabilito. La persona A usa il certificato per crittografare le informazioni e invia
le informazioni crittografate all’Umano B. Le informazioni sono illeggibili finché l’Umano B non usa il certificato per decifrare le informazioni crittografate.

Se l’Umano B vuole
rispondere alla Persona A con informazioni criptate, allora l’Umano B userebbe il
certificato per criptare i dati e la Persona A userebbe il certificato per
decriptare il messaggio.

Questo è generalmente il modo in cui funziona la
criptazione/decriptazione. Ora sostituisci le persone elencate in questo esempio con
server e altre connessioni simili. Stesso concetto.

Ora se l’Umano B vuole rispondere alla Persona A con informazioni criptate, allora l’Umano B usa la chiave simmetrica che è stata appena generata e ora possono sia criptare e inviare, sia ricevere e decriptare i dati l’uno all’altro.

Questo è generalmente il modo in cui funziona la crittografia/decrittografia con SSL/TLS. Ora sostituisci le persone elencate in questo esempio con server e altre connessioni di questo tipo. Stesso concetto. Questo è il modo in cui TLS funziona con la posta elettronica, che è un po’ diverso da come facilita una connessione HTTPS a causa del fatto che la posta elettronica utilizza protocolli diversi. Ma ci sono ancora alcune distinte somiglianze:

• Si verifica un handshake
• Si verifica un’autenticazione (anche se entrambe le parti si autenticano in questo contesto)
• Le chiavi di sessione sono usate per trasmettere il flusso di email.

Ebb e (Mail) Flow

Il prossimo passo di questo articolo
“capire perché” è la parte “capire come”.

In breve, un client di posta elettronica invia un’email al server in uscita. Il server in uscita farà una ricerca DNS, basata sul dominio di destinazione dell’email, e il record MX del DNS determinerà il server a cui inviare l’email e, eventualmente, quel server determinerà se ha bisogno di essere inoltrata fino a quando non colpisce il Mail Delivery Agent (MDA) della casella di posta di destinazione.

Non basta
fidarsi dei record DNS MX, che è tutta un’altra questione di fiducia, ma il server SMTP
(posta in uscita, MTA, ecc.) e la posta in entrata (via POP3, IMAP,
Exchange) devono essere in grado di identificarsi a vicenda e avere le chiavi corrette per
comunicare tra loro. E, a seconda del percorso, ci possono essere più
di una semplice comunicazione tra server di posta elettronica. Mail Exchanger, proxy
servers e altro potrebbero essere presenti lungo il percorso. Ogni hop (dovrebbe) richiedere
un collegamento criptato. Spesso lo fa. A volte, non lo fa. Gli utenti preferirebbero
che le informazioni sensibili fossero criptate lungo il percorso. La crittografia end-to-end
aiuta ad assicurare che ci sia una sorta di crittografia lungo tutto il percorso, ma
gli strati di sicurezza sono sempre, uh, migliori.

Rispetta il tuo Securi-Tie

Per la cronaca,
Securi-Tie non è una vera parola. Ho inventato questa parola solo perché faceva rima. È
un gioco della parola sicurezza.

Per fare una specie di trampolino di lancio
dalla sezione precedente, dovremmo parlare delle opzioni di sicurezza che, mentre
saranno impostate dal lato client, in realtà forniranno alcune istruzioni
al lato server di posta per scopi legati alla sicurezza.

Quando si configura un
client di posta elettronica (Outlook, Thunderbird, ecc.), l’impostazione predefinita è una configurazione non criptata
. Ma, come è il punto di questo articolo, tipicamente vogliamo andare per l’opzione crittografata. In un certo senso, non dipende interamente dal client: dipende da ciò che il lato server è in grado di supportare. Supponendo che i vostri server in entrata
e in uscita possano supportare la crittografia, perché non dovreste? Se ordinate una
bistecca al ristorante e vi offrono una lombata di prima scelta o una costata di Kobe (wagyu) allo stesso prezzo, perché non dovreste ordinare il taglio di migliore qualità?

Quindi, se vuoi usare
TLS/SSL sulla tua email (questo è per la parte di transito e non per la parte end-to-end,
S/MIME che è discussa in altri post del blog), attivala. Usa le porte 465
o 587 per SMTP (‘membro, posta in uscita) e 993 (IMAP) o 995 (POP3) per
il traffico in entrata.

C’è un
interessante protocollo di cifratura che è ancora usato tra i server di posta elettronica. Ha il suo bene e il suo male, come la maggior parte delle cose. In definitiva, direi che
le sue intenzioni sono buone ma l’applicazione nel mondo reale non è del tutto ideale come potrebbe. Signore e signori, quel protocollo è STARTTLS.

STARTTLS è un protocollo di sicurezza
che fondamentalmente è SSL/TLS. Molto semplicemente, STARTTLS prende una
connessione esistente in chiaro e, quindi, non sicura, e tenta di convertirla
in una connessione sicura usando TLS (o SSL). Quindi, il livello di sicurezza di
STARTTLS vs SSL/TLS non è in realtà diverso. Se tutto è impostato correttamente, entrambi
crittograferanno le informazioni usando TLS (o SSL).

La differenza principale è
basata sullo stato di una connessione e/o sull’inizio della comunicazione. STARTTLS
non garantisce una comunicazione criptata. Significa fondamentalmente, ‘se la
connessione non è criptata e tu sei in grado di farlo, trasformala in una
connessione sicura’. Se il nodo di connessione (probabilmente un server) non è in grado di trasformare la
connessione in una connessione criptata, potrebbe essere compito del client decidere come gestirla da lì.

Mentre ho usato il termine
qualificante di STARTTLS come “utile”, potrebbe essere considerato meno sicuro
che selezionare SSL/TLS. La selezione standard di SSL/TLS è fondamentalmente, “Usa
la crittografia o sei fottuto”. STARTTLS sta dicendo: “Um, se puoi, per favore fallo. Se
non puoi, possiamo procedere in base ad altre istruzioni”.

Ecco alcune dichiarazioni conclusive

Spesso, l’ovvio ha bisogno di essere affermato e forse
esaltato. Quindi eccola qui: Usate la crittografia. Specialmente per qualcosa che
è così importante, così cruciale e integrato in apparentemente la stragrande maggioranza di
qualsiasi struttura organizzativa che può trasportare informazioni di make or break. Non c’è
non c’è molto sforzo da fare. Usare sia la crittografia end-to-end che quella in-transit
. Due è meglio di uno.

Se qualcuno pensa che lo sforzo extra per configurare un server di posta elettronica per essere criptato rispetto a quello non criptato non ne valga la pena, allora quel qualcuno è
non ne vale la pena. Questo è semplicemente esagerare l’ovvio. La crittografia end-to-end, come S/MIME, richiede un approccio
più complesso, ma ne vale la pena anche quando si aggiungono strati e strati di
sicurezza. Ma non ci sono scuse per non prendersi il tempo di impostare e mantenere
collegamenti sicuri.

Quando la visibilità lo permette, qualsiasi percorso e-mail che potrebbe non sembrare sicuro o compromesso dovrebbe essere tenuto sotto controllo. E con questo, siate felici nel vostro scrutare per un internet più sicuro. Salute!

*** Questo è un blog di Security Bloggers Network sindacato da Hashed Out by The SSL Store™ scritto da Ross Thomas. Leggi il post originale a: https://www.thesslstore.com/blog/encryption-and-email-servers/