Co potřebujete vědět o používání SSL/TLS k šifrování připojení vašich e-mailových serverů

Když jsem byl osloven
s tématem tohoto příspěvku, rád jsem souhlasil. Tady je parafráze
toho, jak to probíhalo:

„Byl bys schopen
napsat příspěvek o důležitosti TLS v e-mailových serverech?“ zeptal se Patrick.

„Jistě,“ řekl jsem.

Uf, to byla šílená
konverzace, kterou je třeba znovu prožít! Jako vichřice!“

Pak jsem o tom začal chvíli přemýšlet. Opravdu existují e-mailové servery, které pro přenos nepoužívají šifrování? Nemluvím o end-to-end šifrování, jakým jsme se zabývali v minulosti (S/MIME, PGP atd.). Mám na mysli šifrování od serveru k serveru nebo všeho mezi nimi, které chrání data na cestě mezi nimi.

Jistě, v dnešní době by nikdo nenechal svou příchozí/odchozí poštu v prostém textu procházet bůhvíjakou trasou, aby ji mohl zachytit a využít. Mnoho lidí používá e-mailové služby a není možné, aby ze svých služeb vylučovali tranzitní šifrování. Úniky dat je stojí miliony na
žalobách a ztrátě obchodu a ostudu……Hmmmm…..

Vrátil jsem se k Patrickovi
s dotazem.

„Máme statistiky
nebo informace o e-mailových serverech, které nepoužívají šifrování? Odhaduji, že by jich bylo
málo. Jinými slovy, co vás vedlo k tomu, abyste se mě zeptal na tento článek?“ „Ano.

Patrick odpověděl: „Já
vlastně ne. Myslel jsem si, že by to bylo dobré téma vzhledem k důležitosti
elektronické pošty a všech aspektů potřebných pro bezpečnost.“

OK. To dává smysl. Pravděpodobně existují e-mailové servery, které ji vůbec nepoužívají, i když nepochybně mnohem větší procento může používat zastaralé protokoly nebo prošlé certifikáty a může potřebovat jen obnovení.

V tomto článku si projdeme
, jak jsme na tom se šifrováním e-mailu a tranzitu, abychom se ujistili, že pracujete
na optimální úrovni bezpečnosti, která je k dispozici.

Šifrování v e-mailových serverech

V tuto chvíli již pravděpodobně máme obecnou představu o tom, jak TLS funguje, ale shrňme si to pro případ, že jste v této oblasti nováčky.

Osoba A chce poslat
zabezpečenou komunikaci člověku B. Osoba A a člověk B mají předem vytvořený
certifikát. Osoba A použije certifikát k zašifrování informace a odešle
zašifrovanou informaci člověku B. Informace je nečitelná, dokud člověk
B nepoužije certifikát k dešifrování zašifrované informace.

Pokud by člověk B chtěl
odpovědět zpět osobě A se zašifrovanými informacemi, pak by člověk B použil
certifikát k zašifrování dat a osoba A by použila certifikát k
dešifrování zprávy.

Takto obecně funguje
šifrování/dešifrování. Nyní nahraďte osoby uvedené v tomto příkladu za
servery a další podobná spojení. Stejný koncept.

Pokud nyní chce člověk B odpovědět zpět osobě A se zašifrovanými informacemi, pak člověk B použije právě vygenerovaný symetrický klíč a nyní si mohou navzájem data jak zašifrovat a odeslat, tak přijmout a dešifrovat.

Takto obecně funguje šifrování/dešifrování pomocí SSL/TLS. Nyní nahraďte osoby uvedené v tomto příkladu servery a dalšími podobnými spojeními. Stejný koncept. Takto funguje TLS s elektronickou poštou, což je trochu jiné než usnadnění spojení HTTPS vzhledem k tomu, že elektronická pošta používá jiné protokoly. Přesto však existují některé zřetelné podobnosti:

• Probíhá handshake
• Probíhá autentizace (i když v tomto kontextu se autentizují obě strany)
• K přenosu toku e-mailů se používají klíče relací.

Ebb a (Mail) Flow

Dalším krokem k tomuto
„pochopení proč k“ článku je část „pochopení jak“.

Krátce řečeno, e-mailový klient odešle e-mail na odchozí server. Odchozí server provede vyhledání DNS na základě cílové e-mailové domény a záznam MX tohoto DNS určí, na který server má být e-mail odeslán, a případně tento server určí, zda je třeba jej předat dál, dokud se nedostane k agentovi pro doručování pošty (MDA) cílové schránky.

Nestačí
důvěřovat záznamům DNS MX, což je úplně jiná otázka důvěryhodnosti, ale server SMTP
(pošta odchází, MTA atd.) a pošta přichází ( přes POP3, IMAP,
Exchange) se musí navzájem identifikovat a mít správné klíče pro
komunikaci mezi sebou. A v závislosti na trase může existovat více
než jen komunikace e-mailového serveru s jedním skokem. Na trase mohou být poštovní výměnné servery, proxy
servery a další. Každý skok (by) měl vyžadovat
šifrované spojení. Často se tak děje. Někdy tomu tak není. Uživatelé by
raději, kdyby citlivé informace byly po cestě šifrované. Koncové šifrování
pomáhá zajistit, že je nějaký druh šifrování po celé cestě, ale
vrstvy zabezpečení jsou vždy, ehm, lepší.

Respect Thy Securi-Tie

Pro pořádek,
Securi-Tie není skutečné slovo. To slovo jsem si vymyslel jen proto, že se rýmovalo. Je to
hříčka se slovem security.

Abychom tak trochu odskočili
od předchozí části, měli bychom si promluvit o možnostech zabezpečení, které by se sice
nastavovaly ze strany klienta, ale ve skutečnosti by poskytovaly nějaké instrukce
na straně poštovního serveru pro účely související s bezpečností.

Při konfiguraci
poštovního klienta (Outlook, Thunderbird atd.) je výchozí konfigurace nešifrovaná
. Jak je však smyslem tohoto článku, obvykle chceme zvolit
šifrovanou možnost. V jistém smyslu to není zcela na klientovi: záleží
na tom, co je schopna podporovat strana serveru. Za předpokladu, že vaše příchozí
a odchozí servery mohou podporovat šifrování, proč byste to neudělali? Pokud si v restauraci objednáte
steak a nabídnou vám výběrovou svíčkovou nebo Kobe(wagyu) ribeye
za stejnou cenu, proč byste si neobjednali kvalitnější kus?

Takže, pokud chcete používat
TLS/SSL ve své elektronické poště (to se týká tranzitní části a ne části end-to-end,
S/MIME, o které se píše v jiných příspěvcích na blogu), zapněte ji. Použijte porty 465
nebo 587 pro SMTP (‚member, odchozí pošta) a 993 (IMAP) nebo 995 (POP3) pro
příchozí provoz.

Existuje
zajímavý šifrovací protokol, který se stále používá mezi e-mailovými servery. Má
své dobré i špatné stránky, jak už to tak u většiny věcí bývá. Nakonec bych řekl, že
jeho záměry jsou dobré, ale reálné použití není zcela ideální, jak by
mohlo. Dámy a pánové, tím protokolem je STARTTLS.

STARTTLS je bezpečnostní
protokol, který je v podstatě SSL/TLS. Jednoduše řečeno, STARTTLS vezme
existující prostý text, a tedy nezabezpečené spojení, a pokusí se ho převést
na zabezpečené spojení pomocí TLS (nebo SSL). Úroveň zabezpečení
STARTTLS a SSL/TLS se tedy ve skutečnosti neliší. Pokud je vše správně nastaveno, budou obě
šifrovat informace pomocí TLS (nebo SSL).

Hlavní rozdíl je
založený na stavu spojení a/nebo zahájení komunikace. STARTTLS
nezaručuje šifrovanou komunikaci. V podstatě znamená: „Pokud je
spojení nešifrované a vy jste toho schopni, vytvořte z něj zabezpečené
spojení“. Pokud připojovací uzel (pravděpodobně server) není schopen přeměnit
připojení na šifrované spojení, může být na straně klienta, aby
rozhodl, jak s ním dále naloží.

Přestože jsem použil
kvalifikační termín STARTTLS jako „užitečný“, lze jej považovat za méně bezpečný
než volbu SSL/TLS. Standardní volba SSL/TLS v podstatě znamená: „Použij
šifrování, nebo zkrachuj“. STARTTLS říká: „Hm, pokud můžete, udělejte to, prosím. Pokud
ne, můžeme pokračovat na základě dalších pokynů.“

Tady je několik přesvědčivých tvrzení

Často se stává, že je třeba konstatovat zřejmé věci a možná
je přehnat. Takže tady to je, ehm: Používejte šifrování. Zvláště u něčeho, co je
tak důležité, tak zásadní a integrované do zdánlivě drtivé většiny
jakékoli organizační struktury, která může nést informace, které rozhodují nebo rozbíjejí. Není
třeba na to vynaložit mnoho úsilí. Používejte koncové i tranzitní
šifrování. Dva jsou lepší než jeden.

Pokud má někdo pocit, že dodatečné úsilí na nastavení e-mailového
serveru tak, aby byl šifrovaný oproti nešifrovanému, nestojí za to, pak ten někdo za to
nestojí. To je prostě přehnané tvrzení. Koncové šifrování, jako je S/MIME, vyžaduje
náročnější přístup, ale při přidávání dalších a dalších vrstev
zabezpečení se také vyplatí. Neexistuje však žádná výmluva, proč nevěnovat čas nastavení a údržbě
zabezpečených spojení.

Když to viditelnost dovolí, měla by být pod drobnohledem každá e-mailová cesta, která se může zdát nezabezpečená nebo ohrožená. A s tím buďte spokojeni při své kontrole pro bezpečnější internet. Na zdraví!

*** Toto je syndikovaný blog Security Bloggers Network od společnosti Hashed Out by The SSL Store™, jehož autorem je Ross Thomas. Původní příspěvek si můžete přečíst na adrese: https://www.thesslstore.com/blog/encryption-and-email-servers/