Hvad du skal vide om at bruge SSL/TLS til at kryptere forbindelser fra dine e-mail-servere

Da jeg blev kontaktet
med emnet for dette blogindlæg, gik jeg gerne med til det. Her er en omskrivning
af, hvordan det foregik:

“Vil du kunne
skrive et indlæg om betydningen af TLS i e-mail-servere?” spurgte Patrick.

“Selvfølgelig,” sagde jeg.

Whew, det var en vanvittig
samtale at genopleve! Som en hvirvelvind!

Så begyndte jeg at tænke lidt over det. Er der virkelig e-mail-servere derude, der ikke bruger kryptering til transit? Jeg taler ikke om end-to-end-kryptering, som vi har dækket i fortiden (S/MIME, PGP osv.). Jeg tænker på kryptering fra server til server eller alt derimellem for at beskytte dataene undervejs.

Sikkert er det, at ingen i vore dage ville lade deres indgående/udgående post ligge i klartekst på en rute, som Gud ved hvilken rute for at blive opsnappet og udnyttet. Mange mennesker bruger e-mail-tjenester, og der er ingen måde, hvorpå de ville udelukke transit-kryptering fra deres tjeneste. Databrud koster dem millioner i
sager og tab af forretning og skam……Hmmmmmm…..

Jeg gik tilbage til Patrick
med et spørgsmål.

“Har vi statistik
eller oplysninger om e-mail-servere, der ikke bruger kryptering? Mit gæt er, at det ville
være lavt. Med andre ord, hvad fik dig til at spørge mig om denne artikel?”

Patrick svarede: “Det
har jeg
faktisk ikke. Jeg tænkte, at det ville være et godt emne i betragtning af vigtigheden
af e-mail og alle de aspekter, der er nødvendige for sikkerheden.”

OK. Det giver mening. Der er sikkert nogle e-mail-servere derude, der slet ikke bruger det, selv om der utvivlsomt er en langt større procentdel, der måske bruger forældede protokoller eller udløbne certifikater og måske bare har brug for en opdatering.

Denne artikel vil gå
over hvor vi står med e-mail og transitkryptering for at sikre, at du
driver på et optimalt sikkerhedsniveau, der er tilgængeligt.

Kryptering i e-mail-servere

På dette tidspunkt har vi sandsynligvis en generel forståelse af, hvordan TLS fungerer, men lad os opsummere i tilfælde af, at du er ny på dette.

Person A ønsker at sende
sikker kommunikation menneske B. Person A og menneske B har et på forhånd etableret
certifikat. Person A bruger certifikatet til at kryptere oplysningerne og sender
de krypterede oplysninger til menneske B. Oplysningerne er ulæselige, indtil menneske
B bruger certifikatet til at dekryptere de krypterede oplysninger.

Hvis menneske B ønsker at
svaret tilbage til person A med krypterede oplysninger, vil menneske B bruge
certifikatet til at kryptere dataene, og person A vil bruge certifikatet til at
afkryptere meddelelsen.

Det er generelt sådan, hvordan
kryptering/dekryptering fungerer. Udskift nu de personer, der er anført i dette eksempel, med
servere og andre sådanne forbindelser. Samme koncept.

Hvis menneske B nu ønsker at svare tilbage til person A med krypterede oplysninger, så bruger menneske B den symmetriske nøgle, der netop er blevet genereret, og de kan nu både kryptere og sende og modtage og dekryptere data til hinanden.

Det er generelt sådan, hvordan kryptering/afkryptering med SSL/TLS fungerer. Nu erstatter du de personer, der er nævnt i dette eksempel, med servere og andre sådanne forbindelser. Samme koncept. Sådan fungerer TLS med e-mail, hvilket er en smule anderledes end hvordan det letter en HTTPS-forbindelse på grund af det faktum, at e-mail anvender andre protokoller. Men der er stadig nogle tydelige ligheder:

• Der sker et handshake
• Der sker autentificering (selv om begge parter autentificerer i denne sammenhæng)
• Sessionsnøgler bruges til at overføre strømmen af e-mails.

Ebb and (Mail) Flow

Det næste skridt i denne
“forstå hvorfor til”-artikel er “forstå hvordan”-delen.

Kort sagt sender en e-mail-klient en e-mail til den udgående server. Den udgående server vil foretage et DNS-opslag baseret på destinationens e-mail-domæne, og denne DNS’s MX-post vil bestemme, hvilken server der skal sende e-mailen til, og eventuelt vil denne server bestemme, om den skal videresendes, indtil den når frem til destinationens indbakke’s Mail Delivery Agent (MDA).

Det er ikke nok at
tillid til DNS MX records, hvilket er et helt andet tillidsspørgsmål, men SMTP
(mail, der sendes ud, MTA osv.) serveren og den mail, der kommer ind ( via POP3, IMAP,
Exchange) skal kunne identificere hinanden og have de rigtige nøgler til at
kommunikere med hinanden. Og afhængigt af ruten kan der være mere
end blot et enkelt hop e-mailserverkommunikation. Mail Exchangers, proxy
servere og andet kan være på plads langs ruten. Hvert hop (bør) kræve
en krypteret forbindelse. Ofte er det tilfældet. Nogle gange er det ikke tilfældet. Brugerne foretrækker, at følsomme oplysninger er krypteret undervejs. End-to-End-kryptering
hjælper med at sikre, at der er en eller anden form for kryptering hele vejen igennem, men
sikkerhedslager er altid, øh, bedre.

Respekt Thy Securi-Tie

For the record,
Securi-Tie er ikke et rigtigt ord. Jeg fandt kun på det ord, fordi det rimmede. Det er
en leg med ordet sikkerhed.

For ligesom at tage udgangspunkt
i det foregående afsnit bør vi tale om sikkerhedsindstillinger, der, selv om
de ville blive indstillet fra klientsiden, faktisk ville give nogle instrukser
til mailserversiden med henblik på sikkerhedsrelaterede formål.

Når man konfigurerer en
emailklient (Outlook, Thunderbird osv.), er standardindstillingen en ukrypteret
konfiguration. Men, som det er pointen med denne artikel, ønsker vi typisk at gå
for den krypterede mulighed. I en vis forstand er det ikke helt op til klienten: det
afhænger af, hvad serversiden er i stand til at understøtte. Hvis vi går ud fra, at dine indgående
og udgående servere kan understøtte kryptering, hvorfor skulle du så ikke gøre det? Hvis du bestiller en bøf på en restaurant, og de tilbyder dig valgfrit oksefilet eller Kobe (wagyu) ribeye til samme pris, hvorfor ville du så ikke bestille den bedre kvalitet?

Så, hvis du ønsker at bruge
TLS/SSL på din e-mail (dette er for transitdelen og ikke for end-to-end,
S/MIME-delen, som behandles i andre blogindlæg), skal du slå det til. Brug port 465
eller 587 for SMTP (‘member, udgående post) og 993 (IMAP) eller 995 (POP3) for
indgående trafik.

Der findes en
interessant krypteringsprotokol, som stadig bruges blandt e-mail-servere. Den
har sine gode med dårlige som det er sådan med de fleste ting. I sidste ende vil jeg sige, at
de intentioner er gode, men den reelle anvendelse er ikke helt ideel, som den
kunne være. Mine damer og herrer, denne protokol er STARTTLS.

STARTTLS er en sikkerhedsprotokol, som grundlæggende er SSL/TLS. STARTTLS tager ganske enkelt en
eksisterende klartekstforbindelse, som derfor er usikker, og forsøger at omdanne den til en sikker forbindelse ved hjælp af TLS (eller SSL). Så sikkerhedsniveauet for
STARTTLS og SSL/TLS er faktisk ikke forskelligt. Hvis alt er indstillet korrekt, vil de begge
kryptere oplysninger ved hjælp af TLS (eller SSL).

Den vigtigste forskel er
baseret på en forbindelses tilstand og/eller på initieringen af kommunikationen. STARTTLS
garantierer ikke krypteret kommunikation. Det betyder grundlæggende: “Hvis
forbindelsen er ukrypteret, og du er i stand til det, så gør den til en sikker
forbindelse”. Hvis forbindelsesknuden (sandsynligvis en server) ikke er i stand til at omdanne
forbindelsen til en krypteret forbindelse, kan det være op til klienten at
afgøre, hvordan den skal håndtere det derfra.

Selv om jeg brugte det
kvalificerende udtryk STARTTLS som “nyttigt”, kan det betragtes som mindre sikkert
end at vælge SSL/TLS. Standard SSL/TLS valg er dybest set: “Use
encryption or bust”. STARTTLS siger: “Øh, hvis du kan, så gør det. Hvis du ikke gør det, kan vi fortsætte på grundlag af andre instruktioner.”

Her er nogle konkluderende udsagn

Ofte gange skal det indlysende siges og måske
overstås. Så her er det, ahem: Brug kryptering. Især for noget, der
er så vigtigt, så afgørende og integreret i tilsyneladende langt størstedelen af
nogen organisatorisk struktur, som kan bære oplysninger, der kan være afgørende eller ødelæggende. Der er
ikke mange anstrengelser, der behøver at blive lagt i det. Brug både end-to-end- og in-transit
kryptering. To er bedre end en.

Hvis nogen føler, at den ekstra indsats for at konfigurere en e-mail
server til at være krypteret i forhold til ukrypteret ikke er det værd, så er den pågældende person
ikke det værd. Dette er simpelthen en overdrivelse af det indlysende. End-to-end-kryptering, som f.eks. S/MIME, kræver en
mere omfattende fremgangsmåde, men det er også det værd, når man tilføjer flere og flere lag af
sikkerhed. Men der er ingen undskyldning for ikke at tage sig tid til at oprette og vedligeholde
sikre forbindelser.

Når synligheden tillader det, bør enhver e-mail-sti, der ikke virker sikker eller kompromitteret, undersøges nøje. Og med det, så vær glad for din kontrol med henblik på et mere sikkert internet. Skål!

*** Dette er en syndikeret blog fra Security Bloggers Network fra Hashed Out by The SSL Store™, som er skrevet af Ross Thomas. Læs det oprindelige indlæg på: https://www.thesslstore.com/blog/encryption-and-email-servers/