Názory k článku
Gmail bude jako první velká služba podporovat MTA-STS a TLS reporting

Potvrzuji, včera mi přišel od Google první TLS report. Je smutné, že dávají přednost téhle nedokonalé překomplikované šílenosti jménem MTA-STS namísto jednoduché a funkční záležitosti jménem DANE.

MTA-STS má nižší práh zavedení. Bude jednodušší ho zavést na doménách, kde není pořádný admin, nebo kde je rozstrkaná správa mezi více subdodavatelů.

MTA-DANE vyžaduje základní kooperaci mezi správou DNS a získáváním certifikátu. MTA-STS víceméně ne. Do .well-known se vrazí JSON odpověď (lze nascriptovat asi třemi řádky přímo v nginx) a o zbytek se nikdo nemusí starat.

Oproti tomu MTA-DANE vyžaduje, aby se do DNS dostaly certifikáty (nebo hashe) při každé změně. Pro malé spotřebitele je to dost nepohodlné, představuje to nastavování a správu a riziko, že se DNS rozjede od certifikátu. O to víc rizik je, jak se stává populárnější ověřování ACME a čím dál víc firem používá Let's Encrypt certifikáty. Ty mají platnost jen tři měsíce a četl jsem, že se zvažuje zkrácení jejich platnosti.

Z toho důvodu rozumím tomu, že si někdo (Google) vybere MTA-STS jakožto technologii, kterou začne podporovat. MTA-DANE by ovšem zatratit neměli.

O tom nižším prahu zavedení MTA-STS dost pochybuji. Je třeba udržovat na e-mailových serverech validní certifikáty, při změně MX záznamů je třeba změnu opakovat v MTS-STS politice. Když na to někdo zapomene, má tu DoS. Stejně tak služby, které umožňují hostovat uživatelský obsah na subdoméně, třeba Tumblr nebo Github Pages, musí nově vyhradit subdoménu mta-sts, aby nějaký uživatel nemohl vystavit politiku pro celou doménu.

MTA-DANE nevyžaduje žádnou kooperaci mezi správou DNS a získáním certifikátu, vyžaduje pouze DNS hosting s podporou DNSSEC.

Praktické srovnání: Hypotetický vlastník domény example.com, chce hostovanou službu e-mailů.

• Pro MTA-DANE provozovatel potřebuje pouze mít na doméně example.com DNSSEC a nasměrovat MX (a případně SPF, DMARC, atd) záznamy na hosting, všechno ostatní je v režii e-mailového hostingu.
• Pro MTA-STS musí vlastník domény kromě nasměrování MX ještě navíc získat a udržovat validní certifikát pro jméno mta-sts.example.com a na něm ideálně reverzní HTTPS proxy mířící na obdobnou adresu poskytovatele. Případně je možné mít na daném jménu statický text, ale v takovém případě se může politika rozbít při změně na straně hostingu.

Vychází mi z toho, že MTA-DANE je naopak pro každého výrazně jednodušší. Tím nejtvrdším oříškem je požadavek na DNSSEC na autoritativních DNS serverech e-mailového hostingu. Všechno ostatní jsou banality vyřešitelné za několik málo člověkohodin.

Takze mailservery budou mit potrebu pristupu na veskery https? Plus resit certifikaty pro kazdou prijimanou domenu? To se mi taktez moc nelibi.

Nebudou. Ten, kdo na své doméně nechce MTA-STS zavést, nemusí dělat nic. Google pouze sdělil, že bude MTA-STS ověřovat a respektovat ho, pokud bude nastavené.

Mimochodem, do HTTPS se přidá jen kračiká odpověď v jsonu, dá se to nastavit do nginx např. takto:

location ^~ /.well-known/mta-sts.txt {
default_type "text/plain";
echo_status 200;
echo "\r";
echo "version: STSv1\r";
echo "mode: enforce\r";
echo "mx: my.domain.cz\r";
echo "max_age: 86400\r";
}


Nebude nakonec jednoudušší celé SMTP nakonec zrušit a standardizovat způsob, jak posílat e-maily rovnou zkrz HTTPS?

My jsme <s>Borg</s>Google. Sklopte své štíty a vzdejte se. Vaše biologické a technologické charakteristiky budou přidány k našim. Vaše kultura nám bude sloužit. Odpor je marný.

Dlouho z povzdálí sleduji problematiku e-mailové komunikace a nepřestává mě fascinovat, co za bordel kolem zasílání (a kódování) lze vymyslet. Pochopil jsem správně, že celé toto sraní je pouze kvůli tomu, že e-mailový server zdrojové a cílové adresy spolu (jako u Jabberu) nemusejí komunikovat přímo, ale přes neurčené meziservery?

Ne. Je to kvůli tomu, aby se e-maily přes internet přenášely šifrovaně a nemohl si je tedy přečíst každý, kdo jde zrovna kolem.

Přesně o tom mluvím. Jestliže spolu komunikují pouze server zdrojové a cílové domény (tj. jeden skok, z definice protokolu např. u Jabberu), a odesílatel ovládá užití šifrování a může jej tedy vynutit (případně je povinné), není co řešit. Jestliže e-mail je přeposílán (z podstaty) více skoky přes více serverů, kdy šifrování je nepovinné, přičemž původní server jeho použití nemůže řídit, je to v pr*eli. Vše ostatní jsou pak už jen dolepované a hlavně nepovinné, tudíž nespolehlivé záplaty na problém.

Klient, který e-mail odesílá (v této roli vystupuje i server odesílající e-mail) se sám rozhoduje, kam e-mail odešle. E-mail se typicky také neposílá přes víc serverů – typicky ho zdrojový server pošle rovnou na cílový server. Pokud cílový server neukládá e-mail rovnou do schránky, ale distribuuje jej ještě dál v rámci organizace, je už celá ta komunikace pod palcem té cílové organizace – z pohledu odesílatele už by to mělo být jedno. Když pošlete dopis do firmy, také dorazí na recepci nebo na sekretariát, a předpokládáte, že doručení v rámci firmy už mají zabezpečené tak, jak odpovídá povaze dopisů, které dostávají.