Ce trebuie să știți despre utilizarea SSL/TLS pentru a cripta conexiunile realizate de serverele de e-mail

Când am fost abordat
cu subiectul pentru acest articol de blog, am fost de acord cu plăcere. Iată câteva parafrazări
de cum a decurs totul:

„Ai putea
să scrii un post despre importanța TLS în serverele de e-mail?”, m-a întrebat Patrick.

„Sigur”, am spus eu.

Whew, a fost o conversație nebună
de retrăit! Ca un vârtej de vânt!

Apoi am început să mă gândesc puțin la asta. Chiar există servere de e-mail care nu folosesc criptarea pentru tranzit? Nu mă refer la criptarea end-to-end, așa cum am mai abordat în trecut (S/MIME, PGP, etc). Mă refer la criptarea de la server la server sau la tot ceea ce se află între acestea pentru a proteja datele de-a lungul traseului de traversare.

În mod sigur, în ziua de azi, nimeni nu și-ar lăsa corespondența de intrare/ieșire în clar traversând Dumnezeu știe ce rută pentru a fi interceptată și a se profita de ea. Mulți oameni folosesc servicii de e-mail și nu se poate ca aceștia să excludă criptarea tranzitului din serviciul lor. Breșele de date îi costă milioane de euro în
procese și pierderi de afaceri și rușine……Hmmmm…..

Am revenit la Patrick
cu o întrebare.

„Avem statistici
sau informații despre serverele de e-mail care nu folosesc criptarea? Părerea mea este că ar fi
scăzut. Cu alte cuvinte, ce v-a determinat să mă întrebați despre acest articol?”.

Patrick a răspuns: „Eu
de fapt nu știu. M-am gândit că ar fi un subiect bun, având în vedere importanța
a e-mailului și toate aspectele necesare pentru securitate.”

OK. Asta are sens. Probabil că există unele servere de e-mail care nu o folosesc deloc, deși, fără îndoială, un procent mult mai mare poate folosi protocoale depășite sau certificate expirate și poate avea nevoie doar de o reîmprospătare.

Acest articol va trece
în revistă stadiul în care ne aflăm în ceea ce privește criptarea e-mailurilor și a tranzitului pentru a vă asigura că operați la un nivel optim de siguranță care este disponibil.

Criptarea în serverele de e-mail

În acest punct, probabil că avem o înțelegere generală a modului în care funcționează TLS, dar haideți să rezumăm în cazul în care sunteți nou în acest domeniu.

Persoana A vrea să trimită
comunicarea securizată Omul B. Persoana A și Omul B au un certificat
pre-stabilit. Persoana A utilizează certificatul pentru a cripta informațiile și trimite
informațiile criptate către Omul B. Informațiile sunt ilizibile până când Omul
B utilizează certificatul pentru a decripta informațiile criptate.

Dacă Omul B dorește să
răspundă înapoi la Persoana A cu informații criptate, atunci Omul B ar folosi certificatul
pentru a cripta datele, iar Persoana A ar folosi certificatul pentru a
decripta mesajul.

Acesta este, în general, modul în care funcționează
criptarea/decriptarea. Acum înlocuiți persoanele enumerate în acest exemplu cu
servere și alte conexiuni de acest tip. Același concept.

Acum, dacă Omul B vrea să răspundă înapoi la Persoana A cu informații criptate, atunci Omul B folosește cheia simetrică care tocmai a fost generată și acum pot atât să cripteze și să trimită, cât și să primească și să decripteze date unul către celălalt.

Acesta este, în general, modul în care funcționează criptarea/decriptarea cu SSL/TLS. Acum înlocuiți persoanele enumerate în acest exemplu cu servere și alte conexiuni de acest tip. Același concept. Acesta este modul în care funcționează TLS cu e-mailul, care este puțin diferit de modul în care facilitează o conexiune HTTPS datorită faptului că e-mailul utilizează protocoale diferite. Dar, există totuși câteva asemănări distincte:

• Se produce o strângere de mână
• Se produce o autentificare (deși ambele părți se autentifică în acest context)
• Se folosesc chei de sesiune pentru a transmite fluxul de e-mailuri.

Ebb and (Mail) Flow

Postul următor la acest articol
„înțelegând de ce să” este partea de „înțelegând cum”.

Prin scurt, un client de e-mail trimite un e-mail către serverul de ieșire. Serverul de ieșire va face o căutare DNS, pe baza domeniului de e-mail de destinație, iar înregistrarea MX a acelui DNS va determina serverul către care să trimită e-mailul și, eventual, acel server va determina dacă trebuie să fie redirecționat mai departe până când ajunge la Mail Delivery Agent (MDA) al căsuței de primire a e-mailului de destinație.

Nu este suficient să
avem încredere în înregistrările MX ale DNS, care este o cu totul altă problemă de încredere, dar serverul SMTP
(poșta care iese, MTA, etc.) și poșta care intră ( prin POP3, IMAP,
Exchange) trebuie să se poată identifica reciproc și să aibă cheile corecte pentru a
comunica unul cu celălalt. Și, în funcție de traseu, este posibil să existe mai mult
decât un singur hop de comunicare între serverele de e-mail. De-a lungul traseului ar putea exista schimbătoare de corespondență, servere proxy
și altele. Fiecare salt (ar trebui) să solicite
o legătură criptată. De multe ori, așa se întâmplă. Uneori, nu o face. Utilizatorii ar
prefera ca informațiile sensibile să fie criptate de-a lungul drumului. Criptarea de la un capăt la altul
ajută să se asigure că există un anumit tip de criptare pe tot parcursul drumului, dar
straturile de securitate sunt întotdeauna, ăăă, mai bune.

Respect Thy Securi-Tie

Pentru înregistrare,
Securi-Tie nu este un cuvânt real. Am inventat acest cuvânt doar pentru că rima. Este
un joc de cuvinte de la cuvântul securitate.

Pentru a face un fel de trambulină
de la secțiunea anterioară, ar trebui să vorbim despre opțiunile de securitate care, deși
vor fi setate din partea clientului, ar oferi de fapt unele instrucțiuni
la partea serverului de mail în scopuri legate de securitate.

Când se configurează un
client de poștă electronică (Outlook, Thunderbird, etc.), în mod implicit se optează pentru o configurație necriptată
. Dar, așa cum este și scopul acestui articol, de obicei dorim să optăm
pentru opțiunea criptată. Într-un anumit sens, nu depinde în întregime de client: depinde
de ceea ce este capabil să suporte partea de server. Presupunând că serverele dvs. de intrare
și ieșire pot suporta criptarea, de ce nu ați face-o? Dacă comandați o friptură la un restaurant și vi se oferă cotlet de vită sau cotlet Kobe (wagyu) la același preț, de ce nu ați comanda o friptură de calitate mai bună?

Așadar, dacă doriți să folosiți
TLS/SSL în e-mailul dumneavoastră (aceasta este pentru partea de tranzit și nu pentru partea end-to-end,
S/MIME care este discutată în alte articole de pe blog), activați-o. Folosiți porturile 465
sau 587 pentru SMTP (‘membru, e-mail de ieșire) și 993 (IMAP) sau 995 (POP3) pentru
traficul de intrare.

Există un protocol de criptare
interesant care este încă folosit printre serverele de e-mail. Acesta
are bunele și relele sale, așa cum este cazul cu majoritatea lucrurilor. În cele din urmă, aș spune că
intențiile sale sunt bune, dar aplicarea în lumea reală nu este chiar ideală așa cum
ar putea. Doamnelor și domnilor, acel protocol este STARTTLS.

STARTTLS este un protocol de securitate
care practic este SSL/TLS. Pur și simplu, STARTTLS va lua o conexiune
existentă în text simplu și, prin urmare, nesecurizată, și va încerca să o transforme
într-o conexiune securizată folosind TLS (sau SSL). Așadar, nivelul de securitate dintre
STARTTLS și SSL/TLS nu este de fapt diferit. Dacă totul este setat corect, ambele
vor cripta informațiile folosind TLS (sau SSL).

Diferența principală este
bazată pe starea unei conexiuni și/sau pe inițierea comunicării. STARTTLS
nu garantează o comunicare criptată. În esență, înseamnă: „dacă conexiunea
este necriptată și sunteți în măsură, transformați-o într-o conexiune securizată
„. În cazul în care nodul de conexiune (probabil un server) nu este capabil să transforme conexiunea
într-o conexiune criptată, este posibil ca clientul să
decidă cum să o gestioneze de acolo.

În timp ce am folosit termenul
calificativ de STARTTLS ca fiind „util”, acesta ar putea fi considerat mai puțin sigur
decât selectarea SSL/TLS. Selecția standard SSL/TLS este, practic, „Folosiți
criptare sau pierdeți”. STARTTLS spune: „Um, dacă puteți, vă rugăm să faceți acest lucru. Dacă
nu, putem continua pe baza altor instrucțiuni”.

Iată câteva declarații concludente

De multe ori, ceea ce este evident trebuie să fie afirmat și poate
exagerat. Așa că iată-l, ahem: Folosiți criptarea. Mai ales pentru ceva care
este atât de important, atât de crucial și integrat în aparent marea majoritate a
orice structură organizațională care poate transporta informații care fac sau desfac informații. Nu este
nu este nevoie de prea mult efort care să fie depus în acest sens. Utilizați atât criptarea de la un capăt la altul, cât și în tranzit
. Două sunt mai bune decât una.

Dacă cineva consideră că efortul suplimentar de a configura un server de e-mail
pentru a fi criptat față de cel necriptat nu merită, atunci acel cineva nu merită
. Acest lucru este pur și simplu o exagerare a ceea ce este evident. Criptarea de la un capăt la altul, cum ar fi S/MIME, necesită o abordare
mai implicată, dar merită, de asemenea, atunci când se adaugă straturi și straturi de
securitate. Dar, nu există nicio scuză pentru a nu vă face timp să configurați și să mențineți legături
securizate.

Când vizibilitatea permite, orice cale de e-mail care ar putea să nu pară sigură sau compromisă ar trebui să fie ținută sub observație. Și cu asta, fiți fericiți în scrutările voastre pentru un internet mai sigur. Noroc!

*** Acesta este un blog sindicalizat de Security Bloggers Network de la Hashed Out by The SSL Store™ al cărui autor este Ross Thomas. Citiți postarea originală la: https://www.thesslstore.com/blog/encryption-and-email-servers/