Šifrované doručování: TLS, MTA-STS a DANE

Modul 5: Reputace a velcí poskytovatelé · Doba čtení: 10 minut

Cíl lekce: Po této lekci dokážete vysvětlit, jak mailové servery mezi sebou šifrují, proč to není standardně vynutitelné a co na tom mění MTA-STS, TLS-RPT a DANE. Umíte vyhledat a přečíst příslušné záznamy.

Klíčové pojmy: STARTTLS mezi servery, oportunistické šifrování, downgrade útok, MTA-STS (RFC 8461), záznam _mta-sts, soubor s pravidly (policy), režim testing/enforce/none, TLS-RPT (RFC 8460), záznam _smtp._tls, DANE pro SMTP (RFC 7672), TLSA záznam, DNSSEC

Dva druhy spojení

V lekci 1.4 šlo o spojení mezi Vaším poštovním programem a mailovým serverem Vašeho poskytovatele: port 587 se STARTTLS, nebo 465 s přímým TLS, s přihlášením. Tam máte kontrolu sám/sama. Váš program ví, jaký server očekává, kontroluje certifikát a odmítne se připojit, pokud něco nesedí.

Tato lekce se věnuje dalšímu kroku: spojení mezi odesílajícím serverem a přijímajícím serverem, na portu 25. To probíhá jinak.

Oportunisticky: šifrování, pokud je to možné

Když server doručuje poštu, naváže spojení s MX serverem příjemce. Po EHLO zjistí, zda přijímající server nabízí STARTTLS. Pokud ano, přepne na šifrované spojení. Pokud ne, doručí poštu prostě nešifrovaně.

Tomu se říká oportunistické šifrování: šifrovat, pokud je to možné, jinak ne. A odesílající server většinou nekontroluje certifikát přísně. Prošlý nebo vlastnoručně vytvořený certifikát tedy není důvodem k zastavení.

Proč je to tak nastaveno? Protože pošta musí fungovat vždy, i se staršími servery. Odesílatel nemůže vědět, zda příjemce má mít TLS. To umožňuje dva typy útoků:

1. Downgrade. Někdo, kdo dokáže upravit provoz cestou, odstraní slovo STARTTLS z odpovědi příjemce. Odesílatel si myslí, že šifrování není k dispozici, a doručí poštu nešifrovaně. Útočník ji čte.
2. Falešný MX. Někdo, kdo dokáže zfalšovat DNS odpovědi, uvede jako MX vlastní server. Protože se certifikát nekontroluje, odesílatel nic nepozná.

V dnešní době téměř všechny velké mailové servery šifrují a Gmail dokonce po odesílatelích vyžaduje použití TLS (lekce 5.3). Ale „většinou šifrováno“ je něco jiného než „vždy a se správným serverem“. Pro tento problém existují dvě řešení: MTA-STS a DANE. Obě nastavuje příjemce: dáváte jimi najevo, že pošta na Vaši doménu musí být vždy šifrovaná, u serveru s platným certifikátem.

MTA-STS: pravidla přes webovou stránku

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) funguje se dvěma součástmi.

TXT záznam, který oznamuje, že existují pravidla:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

A soubor s pravidly na pevném místě, přes https s platným certifikátem:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Chytré řešení: odesílatel si pravidla pamatuje po dobu max_age. Útočník, který později odstraní slovo STARTTLS nebo poskytne falešný MX, pak neuspěje: pravidla říkají, že šifrování je povinné a které servery jsou platné. Při úplně první spojení (předtím, než jsou pravidla známá) MTA-STS neochrání; to je jeho známé slabé místo.

Skutečným příkladem je gmail.com: TXT záznam _mta-sts.gmail.com existuje a soubor s pravidly na https://mta-sts.gmail.com/.well-known/mta-sts.txt má mode: enforce.

TLS-RPT: reporty o selhaném šifrování

S MTA-STS v režimu enforce může pošta uvíznout, pokud je něco v nepořádku s Vaším certifikátem. To chcete vědět. Proto existuje TLS-RPT (RFC 8460):

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"

Odesílatelé, kteří podporují TLS-RPT (mimo jiné Google a Microsoft), pak denně posílají report ve formátu JSON: kolik spojení se podařilo a kolik selhalo, s uvedením důvodu (například prošlý certifikát nebo jméno, které není v pravidlech). Stejně jako u DMARC reportů (lekce 4.5) můžete nechat zpracování provést reportovací službou.

Pořadí při zavádění: nejdřív TLS-RPT, pak MTA-STS v režimu testing, pár týdnů čtení reportů, a teprve poté enforce. To se podobá doporučenému postupu u DMARC: nejdřív sledovat, pak přitvrdit.

DANE: certifikát v DNS, zabezpečený pomocí DNSSEC

DANE (DNS-based Authentication of Named Entities) jde na to jinak. Do DNS vložíte TLSA záznam u každého MX serveru, s otiskem certifikátu nebo klíče:

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

_25._tcp znamená: pro SMTP na portu 25. Tři čísla určují, jak se má hodnota číst. Pro mailové servery se nejčastěji používá 3 1 1: „toto je SHA-256 otisk veřejného klíče přesně tohoto serveru“. Vyskytuje se i 2 1 1: pak obsahuje otisk mezilehlého certifikátu.

Odesílatel, který podporuje DANE, vidí TLSA záznam, vyžaduje šifrování a kontroluje, zda certifikát serveru sedí. Pokud nesedí, nedoručí.

Proč je DANE bezpečný proti zfalšovaným DNS odpovědím? Protože funguje pouze s DNSSEC (DNS kurz, lekce 8.1). Bez platného DNSSEC řetězce jsou TLSA záznamy ignorovány. To je zároveň prahová podmínka: podepsaná musí být jak Vaše doména (kvůli MX), tak zóna mailového serveru.

DANE nemá slabinu „první spojení“ jako MTA-STS a je hodně rozšířený v Nizozemsku a Německu. internet.nl na něj testuje. Microsoft podporuje DANE pro příchozí poštu v Exchange Online. Také MX servery internet.nl mají TLSA záznamy.

Past: pokud u mailového serveru s DANE vyměníte certifikát za nový klíč, musí se TLSA záznam změnit spolu s ním, a to předem: nejdřív přidat nový záznam, počkat, až vyprší TTL, a teprve pak začít používat nový klíč. Jinak odesílatelé s DANE Vaši poštu odmítnou. U 3 1 1 to platí jen tehdy, když se mění klíč, nikoli při každém obnovení se stejným klíčem.

MTA-STS nebo DANE?

Můžete je používat vedle sebe. RFC 8461 říká, že odesílatel, který podporuje DANE, dá přednost DANE, pokud existují platné TLSA záznamy.

Kdo to zařizuje?

Toto nastavujete pro přijímanou poštu na Vaší doméně. Pokud Vaše pošta běží u hostingové firmy nebo mailové služby, záleží to na tomto poskytovateli:

• DANE je možný, jen pokud poskytovatel publikuje TLSA záznamy pro své mailové servery a Vaše doména má DNSSEC. U WebOké můžete DANE zapnout například na stejném místě jako DNSSEC (viz článek o internet.nl níže); u jiných poskytovatelů to funguje podobně nebo je to vyřešeno automaticky.
• MTA-STS si někdy můžete nastavit sám/sama, ale pak musí mta-sts.example.com být webová stránka s platným certifikátem a musíte znát jména MX serverů svého poskytovatele.
• TLS-RPT si můžete vždy nastavit sám/sama: je to jen TXT záznam s adresou pro reporty.

Pro Vaši odchozí poštu nemusíte dělat nic: server Vašeho poskytovatele určuje, zda respektuje MTA-STS a DANE příjemců.

Shrnutí

• Mezi mailovými servery je TLS standardně oportunistický: šifrovaný, pokud je to možné, bez přísné kontroly certifikátu. To umožňuje downgrade a falešný MX.
• MTA-STS: TXT _mta-sts plus soubor s pravidly na https://mta-sts.<doména>/.well-known/mta-sts.txt; režim testing nebo enforce.
• TLS-RPT: TXT _smtp._tls s adresou pro reporty, pro denní reporty o selhaném šifrování.
• DANE: TLSA záznam na _25._tcp.<mx-server>, funguje pouze s DNSSEC a chrání i první spojení.
• Zavádějte jako u DMARC: nejdřív reporty (TLS-RPT, testing), pak přitvrdit.

Kvíz

Úkol

Úkol Z5.4: Vyhledání MTA-STS, TLS-RPT a DANE. Vyhledejte u gmail.com MTA-STS záznam a TLS-RPT záznam, otevřete soubor s pravidly a vyplňte režim (enforce, testing nebo none). Poté vyhledejte u MX serveru internet.nl TLSA záznam na _25._tcp.<mx-server> a vyplňte první tři čísla jednoho ze záznamů. Volitelně: stejné otázky pro Vaši vlastní doménu (odpověď zde může být „žádné“). Program vše živě dotáže a porovná.

Další čtení

Kroky v těchto článcích platí pro panely WebOké; u jiných poskytovatelů to funguje podobně.

• Kontrolní seznam Internet.nl
• Co je DNSSEC?
• Bezplatný kurz DNS 8.1: DNSSEC v obyčejné řeči
• internet.nl, otestujte si svůj e-mail (nezávislý test STARTTLS, DANE a dalšího): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE pro SMTP)