Hlavní navigace

Gmail bude jako první velká služba podporovat MTA-STS a TLS reporting

12. 4. 2019

Sdílet

GMail Autor: Google

Gmail oznámil, že se brzy stane prvním velkým poskytovatelem e-mailových schránek, který bude podporovat standardy MTA-STS a TLS reporting. Ty rozšiřují protokol SMTP, kterým se stále ještě doručuje elektronická pošta. Oba standardy mají za úkol lépe zabezpečit předávání pošty mezi servery a chránit komunikaci proti útokům typu man-in-the-middle.

MTA-STS je mladý protokol, který dovoluje signalizovat použití důvěryhodných certifikátů při šifrování elektronické pošty během přenosu pomocí SMTP. Oproti protokolu DANE nevyžaduje k nasazení DNSSEC, ale informace o politice se získávají pomocí HTTPS. Standard je kodifikován v RFC 8461.

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

TLS reporting umožňuje mezi servery předávat informace o úspěšném či neúspěšném doručení zpráv do uživatelských schránek. Příjemce může tyto informace získávat, aby identifikoval případné pokusy na útok nebo odhalil chyby v konfiguraci. Standard naleznete v RFC 8460.

Google bude první, kdo tyto standardy na svých serverech nasadí, ale další budou pravděpodobně rychle následovat. Na vývoji standardů se totiž podílela vedle Google řada dalších zvučných jmen jako Microsoft, Yahoo, Oath či Comcast.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 12. 4. 2019 10:18

    Ondřej Caletka
    Zlatý podporovatel

    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.

  • 15. 4. 2019 7:00

    Miroslav Šilhavý

    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.

  • 15. 4. 2019 12:09

    Ondřej Caletka
    Zlatý podporovatel

    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.

  • 12. 4. 2019 10:29

    czechsys

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

  • 15. 4. 2019 7:18

    Miroslav Šilhavý

    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";
    }

  • 12. 4. 2019 13:17

    Ravise
    Stříbrný podporovatel

    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ý.

  • 15. 4. 2019 9:31

    SB

    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?

  • 19. 4. 2019 11:06

    Filip Jirsák
    Stříbrný podporovatel

    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.

  • 23. 4. 2019 9:14

    SB

    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.

  • 16. 5. 2019 9:54

    Filip Jirsák
    Stříbrný podporovatel

    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í.

Byl pro vás článek přínosný?

Autor zprávičky

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.