Vad du behöver veta om att använda SSL/TLS för att kryptera anslutningar från dina e-postservrar

När jag blev tillfrågad
om ämnet för det här blogginlägget gick jag gärna med på det. Här är en parafras
av hur det gick till:

”Skulle du kunna
skriva ett inlägg om vikten av TLS i e-postservrar?” frågade Patrick.

”Visst”, sa jag.

Whew, det var en galen
konversation att återuppleva! Som en virvelvind!

Då började jag tänka lite på det. Finns det verkligen e-postservrar där ute som inte använder kryptering för transitering? Jag talar inte om end-to-end-kryptering som vi har behandlat tidigare (S/MIME, PGP osv.). Jag talar om kryptering från server till server eller allt däremellan för att skydda data längs vägen.

Säkerligen skulle ingen i vår tid lämna sin inkommande/utgående post i klartext på väg genom Gud vet vilken väg för att bli avlyssnad och utnyttjad. Många människor använder e-posttjänster och det finns inte en chans att de skulle utesluta transitkryptering från sin tjänst. Dataintrång kostar dem miljoner i
stämningar och förlust av affärer och skam……Hmmmmmm…..

Jag gick tillbaka till Patrick
med en fråga.

”Har vi statistik
eller information om e-postservrar som inte använder kryptering? Min gissning är att det skulle
vara lågt. Med andra ord, vad fick dig att fråga mig om den här artikeln?”

Patrick svarade: ”Det vet jag
faktiskt inte. Jag tänkte att det skulle vara ett bra ämne med tanke på vikten
av e-post och alla de aspekter som behövs för säkerheten.”

OK. Det låter vettigt. Det finns förmodligen en del e-postservrar där ute som inte använder det alls, även om det otvivelaktigt finns en mycket större andel som kanske använder föråldrade protokoll eller utgånget certifikat och som kanske bara behöver en uppfräschning.

Denna artikel kommer att gå
över var vi befinner oss med e-post- och transitkryptering för att se till att du
arbetar på en optimal säkerhetsnivå som är tillgänglig.

Kryptering i e-postservrar

I det här läget har vi förmodligen en allmän förståelse för hur TLS fungerar, men låt oss sammanfatta om du är nybörjare.

Person A vill skicka
säker kommunikation människa B. Person A och människa B har ett i förväg upprättat
certifikat. Person A använder certifikatet för att kryptera informationen och skickar
den krypterade informationen till människa B. Informationen är oläsbar tills människa
B använder certifikatet för att dekryptera den krypterade informationen.

Om människa B vill
svara tillbaka till person A med krypterad information skulle människa B använda
certifikatet för att kryptera uppgifterna och person A skulle använda certifikatet för att
avkryptera meddelandet.

Detta är i allmänhet hur
kryptering/avkryptering fungerar. Ersätt nu de personer som anges i det här exemplet med
servrar och andra sådana förbindelser. Samma koncept.

Om människa B nu vill svara tillbaka till person A med krypterad information, använder människa B den symmetriska nyckel som just genererades och de kan nu både kryptera och skicka, och ta emot och dekryptera data till varandra.

Detta är i allmänhet hur kryptering/avkryptering med SSL/TLS fungerar. Ersätt nu de personer som anges i det här exemplet med servrar och andra sådana anslutningar. Samma koncept. Så här fungerar TLS med e-post, vilket är lite annorlunda än hur det underlättar en HTTPS-anslutning på grund av att e-post använder olika protokoll. Men det finns ändå några tydliga likheter:

• En handshake sker
• Autentisering sker (även om båda parter autentiseras i detta sammanhang)
• Sessionsnycklar används för att överföra flödet av e-postmeddelanden.

Ebb and (Mail) Flow

Nästa steg i den här
”förstå varför till”-artikeln är ”förstå hur”-delen.

I korthet skickar en e-postklient ett e-postmeddelande till den utgående servern. Den utgående servern gör en DNS-sökning, baserad på e-postdomänen för destinationen, och DNS:s MX-post bestämmer vilken server som e-postmeddelandet ska skickas till, och eventuellt bestämmer den servern om det behöver vidarebefordras tills det når e-postmeddelandet i målinboxens Mail Delivery Agent (MDA).

Det räcker inte att
förtro DNS MX records, vilket är en helt annan förtroendefråga, utan SMTP
-servern (post som skickas ut, MTA etc.) och posten som kommer in (via POP3, IMAP,
Exchange) måste kunna identifiera varandra och ha rätt nycklar för att
kommunicera med varandra. Och beroende på rutten kan det finnas mer
än bara en e-postserverkommunikation med ett enda hopp. Mail Exchanger, proxy
servrar och annat kan finnas på plats längs rutten. Varje hopp (bör) kräva
en krypterad länk. Ofta är det så. Ibland gör den det inte. Användarna föredrar att känslig information krypteras längs vägen. End-to-End-kryptering
hjälper till att säkerställa att det finns någon form av kryptering hela vägen, men
lager av säkerhet är alltid, eh, bättre.

Respektera ditt Securi-Tie

För kännedom,
Securi-Tie är inte ett riktigt ord. Jag hittade bara på det ordet för att det rimmar. Det är
en lek med ordet säkerhet.

För att på sätt och vis ta avstamp i det föregående avsnittet bör vi tala om säkerhetsalternativ som, även om
de skulle ställas in från klientsidan, faktiskt skulle ge några instruktioner
till e-postserverns sida för säkerhetsrelaterade syften.

När man konfigurerar en
e-postklient (Outlook, Thunderbird osv.) är standardkonfigurationen okrypterad
. Men, som är poängen med den här artikeln, vill vi vanligtvis
gå till det krypterade alternativet. På sätt och vis är det inte helt och hållet upp till klienten: det
beror på vad serversidan kan stödja. Om du antar att dina inkommande
och utgående servrar kan stödja kryptering, varför skulle du inte göra det? Om du beställer en biff på en restaurang och de erbjuder dig valfri ryggbiff eller Kobe (wagyu) ribeye till samma pris, varför skulle du då inte beställa den bättre kvaliteten?

Så, om du vill använda
TLS/SSL på din e-post (detta är för transiteringsdelen och inte för end-to-end,
S/MIME-delen som diskuteras i andra blogginlägg), slå på det. Använd portarna 465
eller 587 för SMTP (’member, utgående post) och 993 (IMAP) eller 995 (POP3) för
inkommande trafik.

Det finns ett
intressant krypteringsprotokoll som fortfarande används bland e-postservrar. Det
har sina goda och dåliga sidor som det är med det mesta. I slutändan skulle jag säga att
dess intentioner är goda men den verkliga tillämpningen är inte helt idealisk som den
skulle kunna vara. Mina damer och herrar, det protokollet är STARTTLS.

STARTTLS är ett säkerhetsprotokoll som i princip är SSL/TLS. STARTTLS tar helt enkelt en
existerande klartext och därmed osäker anslutning och försöker omvandla den till en säker anslutning med hjälp av TLS (eller SSL). Säkerhetsnivån mellan
STARTTLS och SSL/TLS skiljer sig alltså inte från varandra. Om allt är rätt inställt kommer båda att kryptera information med hjälp av TLS (eller SSL).

Den huvudsakliga skillnaden är
baserad på en anslutnings tillstånd och/eller initiering av kommunikation. STARTTLS
garanterar inte krypterad kommunikation. Det betyder i princip: ”Om
anslutningen är okrypterad och du kan göra den till en säker
anslutning”. Om anslutningsnoden (troligen en server) inte kan förvandla
anslutningen till en krypterad anslutning, kan det vara upp till klientsidan att
besluta om hur det ska hanteras därifrån.

Men även om jag använde det
kvalificerande begreppet STARTTLS som ”användbart” kan det anses vara mindre säkert
än att välja SSL/TLS. Standardvalet av SSL/TLS är i princip: ”Använd
kryptering eller bryt”. STARTTLS säger: ”Om du kan, var snäll och gör det. Om du inte gör det kan vi fortsätta utifrån andra instruktioner.”

Här är några avgörande uttalanden

Ofta behöver det uppenbara sägas och kanske
överdrivas. Så här är det: Använd kryptering. Särskilt för något som
är så viktigt, så avgörande och integrerat i till synes den stora majoriteten av
någon organisationsstruktur som kan bära information som kan vara avgörande eller brytande. Det är
inte mycket ansträngning som behöver läggas ner på det. Använd både end-to-end- och in-transit-kryptering
. Två är bättre än en.

Om någon anser att det inte är värt den extra ansträngningen att konfigurera en e-postserver för att vara krypterad jämfört med okrypterad, så är den personen inte värd det. Detta är helt enkelt att överdriva det uppenbara. Kryptering från slut till slut, t.ex. S/MIME, kräver ett mer komplicerat tillvägagångssätt, men det är också värt det när man lägger till flera lager av säkerhet. Men det finns ingen ursäkt för att inte ta sig tid att upprätta och underhålla säkra länkar.

När synligheten tillåter bör alla e-postvägar som inte verkar säkra eller komprometterade granskas noggrant. Och med det, var glad i ditt granskande för ett säkrare internet. Skål!

*** Detta är en syndikerad blogg från Security Bloggers Network från Hashed Out by The SSL Store™ författad av Ross Thomas. Läs det ursprungliga inlägget på: https://www.thesslstore.com/blog/encryption-and-email-servers/