Linux E X P R E S

Facebook

Bezpečný e-mail bezpečnější díky DANE

email_zamek.jpg

Vyšší bezpečnost e-mailové komunikace a současně kompatibilitu s méně bezpečným světem získáte nasazením DANE/TLSA. Co konkrétně získáte a jak na to, popisoval Ondřej Caletka na konferenci OpenAlt.


Proč používat TLS

Problematika bezpečnosti elektronické pošty je, podobně jako e-mail samotný, starší než Internet. V minulosti se to řešilo doporučením, že se do zpráv nemá psát nic, co by se nedalo napsat na pohlednici. Ale doba pokročila, e-mail se začal používat pro přenos všeho možného a potřeba chránit přenášené zprávy jak proti odposlechu, tak proti jejich změně během přenosu, nabyla na významu.

Z prezentace Ondřeje Caletky – princip SMTP Z prezentace Ondřeje Caletky – princip SMTP

Ondřej Caletka začal svou přednášku na konferenci OpenAlt právě návratem do historie a popisem principu fungování e-mailu, včetně toho, komu se zpráva může dostat do rukou. „Ono to tak úplně není, že by to mohl číst úplně kdokoliv. (…) Takže kdo může poslouchat: server odesílatele, server příjemce. Ale pak dojdeme k tomu, že se ty zprávy šíří většinou nešifrovaně, takže kdokoli s 'odbočkou na kabelu' – a jak se ukázalo, tak takové odbočky asi opravdu existují a tam to někdo nahrává.

Dokument RFC 7258 přímo říká, že masivní sledování komunikace se považuje za útok a při návrhu komunikačních protokolů by se mělo postupovat tak, aby bylo co nejvíce omezeno (pokud to jde).

Existují dvě kategorie řešení, jak se odposlechu (a případně změně) bránit. Jednak je to end-to-end šifrování, například S/MIME-CMSPGP. Druhou kategorií jsou řešení hop-by-hop. Tam patří DKIM (zajišťující kontrolu integrity, běžně se používá v antispamových systémech pro ověřování původce zprávy) a především SMTP over TLS (zajišťuje šifrovaný přenos mezi jednotlivými uzly).

„To má velikou výhodu,“ říká Ondřej Caletka, „že je to bez přímé účasti uživatele, ten o tom vůbec netuší, nemusí to nijak řešit. A vy automaticky eliminujete všechny možné odposlechy po cestě, což byste podle toho RFC 7258 měli dělat.“Na jednotlivých serverech, přes které zpráva putuje, se ale samozřejmě lze k obsahu zprávy dostat.



Oportunistické šifrování

Běžně se v praxi používá tzv. oportunistické šifrování. To znamená, že jeho použití není povinné. Pokud obě strany podporují TLS, použije se pro přenos zprávy, jinak se zpráva přenese v otevřeném, nezašifrovaném tvaru. „Bohužel si za sebou táhneme kouli zpětné kompatibility a není možné ze dne na den říct: teď budeme doručovat pouze šifrovaně. Nějaká část serverů na Internetu totiž to šifrování vůbec nepodporuje“, vysvětluje Caletka.

Spojení přes TLS je zde anonymní, ověřování identity se neprování a lze používat i slabé a nebezpečné šifry (je to totiž stále bezpečnější, než když se nešifruje vůbec). Takový přenos je ale odolný jen proti pasivnímu odposlechu, tedy pokud útočník nemá možnost do komunikace zasahovat.

Ondřej Caletka (v popředí) při přednášce o DANE Ondřej Caletka (v popředí) při přednášce o DANE

Lze sice definovat cíle („lépe nastavené“ servery) s vynuceným šifrováním, v praxi je to ale problém – kde vzít seznam takových cílů a jak ho udržovat? „Asi by to chtělo nějakou společnou databázi, kde bychom si sami navzájem důvěryhodně deklarovali: 'Já přijímám poštu šifrovaně, nedoručuj mi plain text.'  To je to, k čemu tu chci dnes dojít.“

Co je DANE/TLSA a co přináší

Takovou databází může být totiž systém DNS – ale jedině za předpokladu, že se používá DNSSEC, aby DNS komunikace nemohl nikdo zasahovat. „I kdybychom nakrásně měli všechny certifikáty správně vystavené, na správné jméno, pokud nezabezpečíme DNS, je to úplně k ničemu. Útočník změní odpověď na MX záznam na svůj vlastní server, kde bude mít svůj vlastní certifikát, plně důvěryhodný, a jsme tam, kde jsme byli původně.“

Teoreticky by to šlo obejít tím, že by certifikáty byly vystavené na domény, pro které server přijímá poštu. To je ale špatné, velmi nepraktické řešení – server může přijímat poštu pro velké množství domén, jejichž množina se navíc často mění.

DANE (DNS-based Authentication of Named Entities, česky autentizace pojmenovaných entit založená na DNS) je technologie, která umožňuje vynutit šifrování a zajistit snadné ověření certifikátu (dokonce i bez certifikační autority). Do DNS se ukládá otisk serverového certifikátu, a to do zvláštního záznamu typu TLSA.

Použití DANE pro protokol SMTP je standardizováno v dokumentu RFC 7672.

„Teď je otázka, jak se má chovat SMTP klient, který chce posílat poštu tak, aby to bylo bezpečné a zároveň kompatibilní,“ rozvíjí toto téma Ondřej Caletka. „Pokud není MX záznam podepsaný, končíme doručením s oportunistickým šifrováním. (…) Pokud existuje [TLSA záznam] a je podepsaný, máme jistotu, že ten server je správný a že se dobrovolně přihlásil do toho, aby k němu byly e-maily doručovány šifrovaně.“

Z prezentace Ondřeje Caletky – chování SMTP při použití DANE Z prezentace Ondřeje Caletky – chování SMTP při použití DANE

V tu chvíli se přepíná na vynucené šifrování, vynucenou kontrolu na silné šifry a vynucenou kontrolu certifikátu (podle jeho otisku v TLSA záznamu). Validující klient odhalí „downgrade útok“ (snahu o snížení bezpečnosti) a zprávu nedoručí.

Podpora v softwaru a možné problémy

Ze SMTP serverů podporuje DANE aktuálně Postfix, a to od verze 2.11 (z ledna 2014). U serverů Exim a OpenSMTPd je podpora DANE ve vývoji. Na rozdíl od použití na webu nebývá problém s funkčností DNSSEC, protože mají servery obvykle kvalitní přístup k Internetu, nenarušený různými špatně se chovajícími routery a cachujícími DNS servery.

Ovšem pozor – existují dva případy, kdy mohou být s DANE problémy. Jednak je to chybná údržba záznamů TLSA. Při výměně certifikátu je potřeba aktualizovat otisk, navíc se musí vždy nejdřív přidat nový, pak změnit certifikát a následně odstranit původní otisk. Druhou kategorií problémů jsou rozbité autoritativní servery s DNSSEC.

Ondřej Caletka rozhodně doporučuje používat u SMTP jak šifrování, tak DANE, ale současně zachovat určitou míru pozornosti:

  1. Povolte šifrování pro SMTP (lze použít jakýkoli certifikát, i self-signed), nic to nestojí.
  2. Pokud už používáte DNSSEC, máte DANE „zdarma“.
  3. Vyplatí se sledovat výskyt chybových zpráv „Server certificate not trusted“ a dávat problém na vědomí správcům serverů, u kterých tato chyba nastává (například kvůli zapomenuté aktualizaci TLSA záznamu při změně certifikátu).

Další informace k tématu najdete v prezentaci k přednášce.

Konference OpenAlt: naši autoři Jiří Eischmann (vlevo) a František Zatloukal, zde „ve službách“ linuxové distribuce Fedora Konference OpenAlt: naši autoři Jiří Eischmann (vlevo) a František Zatloukal,
zde „ve službách“ linuxové distribuce Fedora

Diskuze (3) Nahoru