MTA-STS: bezpečné doručování pošty s platnými TLS certifikáty

Přenos elektronické pošty využívá takzvaného oportunistického šifrování. Klientská strana se připojí k serveru, oznámí mu svůj záměr komunikaci šifrovat pomocí STARTTLS (RFC 3207) a naváže anonymní TLS spojení, tedy bez ověření identity protistrany. Pokud se cokoliv na začátku komunikace nepovede, klient přejde na záložní plán a pošta se přenese nešifrovaně.

Správně nastavené poštovní servery tak uživatele chrání jen před pasivním odposlechem. Pokud má někdo možnost do komunikace cíleně zasáhnout, může provoz ovlivnit tím, že do něj podstrčí vlastní certifikáty nebo šifrování zablokuje úplně. Ve zmiňovaném RFC je dokonce explicitně napsáno, že se šifrování vynucovat nesmí kvůli interoperabilitě mezi servery.

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure.

To přece už řeší DANE (TLSA)

Pravidelní čtenáři jistě vědí, že tento problém už nějakou dobu řeší TLSA záznamy v doméně. Ty dokáží signalizovat, že poštovní server používá dogmatické šifrování a nedomluvíte se s ním pomocí otevřeného protokolu. Zároveň se tímto záznamem do zóny dostává otisk veřejného klíče či celého certifikátu, takže je zaručen bezpečný přenos.

Aby tohle celé fungovalo a neumožňovalo to opět útočníkovi nabourat komunikaci, jsou TLSA záznamy podepsány pomocí DNSSEC. Tady je právě kámen úrazu, protože velcí poskytovatelé nechtějí podepisování domén implementovat a tím pádem u nich celé nasazení TLSA padá. Přestože jsme na tom v .CZ s nasazením DNSSEC velmi dobře a každá druhá doména je podepsaná, internet jako celek je na tom mnohem hůře.

Velké společnosti jako Microsoft, Google, Oath či Comcast se spojily a vytvořily nový standard (RFC 8461), který stejný problém řeší úplně jinak. Komplikovaněji, ale zato bez nutnosti používat DNSSEC na obou stranách komunikace.

MTA-STS je bratrem HSTS

Ve světě HTTPS je dnes už docela rozšířená HTTP hlavička HSTS (HTTP Strict Transport Security), která lapidárně řečeno prohlížeči signalizuje, že na daném webu je povinné šifrování důvěryhodnými certifikáty a že si má tuto informaci po stanovenou dobu zapamatovat. Psali jsme o tom v samostatném článku.

Jakmile uživatel web poprvé navštíví, jeho prohlížeč tuto informaci obdrží a příště už bude šifrování vyžadovat a nenechá se obelhat nikým po cestě. První návštěva ještě zabezpečená není, ale každá další už ano. Tomuto principu se říká TOFU – Trust On First Use. Prohlížeč už se dokonce odmítne připojit na nešifrované HTTP (TCP port 80) a rovnou zamíří na šifrované HTTPS (TCP port 443), kde bude vyžadovat platný certifikát.

Přesně tímto principem se inspirovali tvůrci protokolu MTA-STS, plným názvem tedy SMTP MTA Strict Transport Security. Řeší dva komplementárně spojené problémy:

• napevno spojuje doménu s jejími MX servery
• vynucuje politiku dogmatického šifrování a autorizaci důvěryhodnými certifikáty

Bez použití DNSSEC si totiž nemůžeme být jisti, že nám někdo už na začátku komunikace nepodvrhl MX záznamy a nebudeme odesílat poštu na jiné servery:

$ dig MX gmail.com +short
10 hacker.example.com.
20 phishing.example.com.
30 malware.example.com.

Politika na HTTPS

Nasazení MTA-STS je v praxi realizováno ve dvou krocích. Tím prvním je zveřejnění politiky pomocí HTTPS na specializované doméně, která je odvozena od původní domény, pro kterou chceme doručit poštu. Tedy ne adresy MX serveru. Konkrétní příklad bude lepší než složité vysvětlování:

$ curl https://mta-sts.gmail.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

Vidíte, že na doméně gmail.com je vytvořena subdoména mta-sts a na ní je v cestě /.well-known/mta-sts.txt zveřejněna politika v předem daném formátu. Důležité je, že HTTPS server s politikou používá důvěryhodný certifikát vystavený veřejnou certifikační autoritou. Toto musíte udělat pro všechny domény, pro které přijímáte poštu.

Politika obsahuje verzi (zatím jen STSv1), režim (none/testing/enforce), seznam povolených MX serverů (může jich být více a ve jménech může být hvězdička) a konečně dobu platnosti politiky v sekundách. Tu je doporučováno nastavit alespoň v řádech týdnů a po tu dobu si klient má informace zapamatovat a používat je. Po uplynutí doby se na politiku podívá znovu.

Druhým krokem v nasazení MTA-STS je zveřejnění informace o politice v doméně. Opět začneme příkladem:

$ dig TXT _mta-sts.gmail.com
_mta-sts.gmail.com. 262 IN  TXT "v=STSv1; id=20171114T070707;"

Jedná se o standardní záznam typu TXT, ve kterém je opět uvedena verze politiky a také její ID. To muže být časová značka nebo libovolné náhodné číslo. Důležité je, že když změníte politiku, můžete změnou ID signalizovat ostatním serverům, že si mají znovu stáhnout politiku. Nebo řečeno obráceně: servery se dívají do vaší zóny a pokud narazí na stejné ID jako minule, tak už si nemusí znovu politiku pomocí HTTPS stahovat až do vypršení doby její platnosti. Stará politika platí i v případě, že se ID změnilo, ale novou politiku se nepodařilo stáhnout – to pro případ, že by někdo zasáhl do nezabezpečeného TXT záznamu v DNS.

Tři režimy

Politika volí jeden ze tří režimů:

• none říká, že se mají ostatní servery k politice chovat tak, jako by tam vůbec nebyla – používá se při rušení MTA-STA
• testing říká, že se má pošta doručovat bez ohledu na politiku, ale v případě jejího porušení se má poslat report pomocí TLSRPT (TLS Reporting, RFC 8460) – hodí se pro testování před ostrým nasazením
• enforce říká, že se pošta nesmí doručit na jiné než vyjmenované MX servery a ty navíc musí mít důvěryhodný certifikát vystavený na své jméno

Pro ověření funkčnosti politiky a kontrolu celého nastavení můžete použít webový MTA-STS validátor. Výstup vypadá přibližně takto:

MTA-STS vs. DANE

MTA-STS a DANE jsou sice „konkurenční“ protokoly, ale vzájemně si nepřekáží. RFC dokonce výslovně zmiňuje, že mohou být nasazeny společně a pokud selže validace DANE, nesmí být pošta pomocí MTA-STS doručena.

MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation.

Standard zmiňuje, že MTA-STS je určen do prostředí, kde je nasazení DNSSEC nežádoucí či nepraktické. Zajišťuje bezpečný přenos pošty pomocí TLS za cenu výrazně zvýšené komplexity. Zatímco u DANE stačí přidat jeden záznam do DNS, pro nasazení MTA-STS musíte pro každou doménu spustit web server, pořídit k němu i k poštovnímu serveru důvěryhodný certifikát a udržovat ho platný.

MTA-STS staví na současném veřejném PKI a používá veřejné certifikační autority. DANE se naopak od této struktury odpojuje a vytváří vlastní body důvěry nezávislé na PKI. Nevýhodou nového protokolu MTA-STS také je, že v současnosti nemá žádnou svobodnou implementaci. Na druhou stranu jej zřejmě začnou používat velcí hráči, kteří často volí pravidla hry.

Dalo by se to shrnout tak, že DANE má všechny výhody na své straně. Pokud ale můžete nebo nechcete (což je ještě horší) nasadit DNSSEC, můžete použít MTA-STS jako alternativu.

Za inspiraci děkuji Tomáši Hálovi z Active 24, který o tématu přednášel na LinuxDays 2018.