DomainKeys - nová antispamová technologie

Systém přenosu emailů po Internetu byl navržen ještě v dobách, kdy se bezpečností nebylo potřeba příliš zabývat - a je to na něm poznat. Bohužel od doby jeho vzniku nebylo v tomto ohledu uděláno takřka nic. Dnes vás chceme seznámit s technologií, která by mohla u emailů omezit možnost podvržení adresy odesílatele.

S technologií DomainKeys, která je momentálně ve stavu návrhu standardu, přišlo Yahoo. Jejím cílem je umožnit ověření, že odesílatel poslal mail z počítače, který je oprávněn odesílat maily pro doménu uvedenou v adrese odesílatele. Nic víc a nic méně. Nezaručuje tedy sama o sobě, že odesílatelem je opravdu uvedený člověk. Na druhou stranu tento přístup vyžaduje pouze nastavení serveru a u uživatele se nic měnit nemusí. Takže její uvedení do praxe je jednodušší, protože technologie vyžadující změnu (u) každé emailové schránky má o hodně menší šance na prosazení.

Zamezení podvržení adresy má dva cíle:

  1. Omezit spam. Idea je, že když bude jistá doména odesílatele, bude možné mít u každé domény její „pověst“ a domény používané spammery budou rychle získávat „špatnou pověst“.
  2. Omezit rhybaření (phishing). Pokud vám přijde dopis s odesílací adresou @ebay.com, budete si moci být jisti, že jej opravdu poslala společnost eBay. Na druhou stranu toto se dá částečně obejít používáním podobných domén, například získat doménu e.bay.com a poslat dopis z ní.

Jak to funguje

Základem algoritmu je elektronická signatura nebo – chcete-li – elektronický podpis obsahu emailu a (některých) položek v jeho hlavičce. Veřejný klíč k podpisu je potom možno získat přes systém DNS, takže je dost vysoká šance, že dopis opravdu podepsal/odeslal někdo, kdo je k tomu zmocněný držitelem domény.

Za dobře vyřešené považuji uložení klíče. Ukládá se sice do TXT záznamu, ale ne vlastní domény, nýbrž do domény <selektor>._domainkey.domena.cz. Tím je jednak možno využít TXT záznam původní domény (i když tak málokdo činí) a hlavně je možné mít k doméně jednoduše více klíčů. Ty mohou být jednak přidělovány jednotlivým serverům oprávněným posílat odchozí poštu, ale hlavně bez problémů revokovány, a je jednoduše umožněna i cyklická obměna klíčů.

Samozřejmě zcela čisté by bylo nepoužívat TXT, ale vytvořit nový typ záznamu. Nicméně standardizace a hlavně implementace takového rozšíření by byla časově dosti náročná.

Problémy rozšíření

Všechna rozšíření snažící se zavést více důvěryhodnosti do systému elektronické pošty naráží na značnou volnost současné architektury. Je velmi těžké je vymyslet tak, aby nepřestalo fungovat mnoho dnes používaných věcí. Problémy činí zejména:

  1. Mailing listy. Mailing list dostane dopis, částečně pozmění (většinou Subject a přidá headery do hlavičky) a rozdistribuuje mnoha uživatelům.
  2. Přeposílání pošty. V současnosti může email jít přes mnoho SMTP serverů (pokud jsou ochotny jej přijmout). Rozhodně neplatí, že by všechny dopisy šly od odesílatele přímo k příjemci.
  3. Při přeposílání pošty je SMTP server oprávněn dopis zcela předělat: změnit hlavičky, předělat MIME strukturu, překódovat MIME přílohy atp.
  4. Odesílání a přijímání pošty jsou dvě různé služby. Uživatel se může klidně připojit z domova a odesílat poštu přes SMTP server svého ISP.

Problémy číslo 1 a 4 se řeší použitím políčka Sender v hlavičce emailu. Ve From je adresa odesílatele, která „má být vidět“, ale pro účely ověření emailu se do Sender dá adresa z domény, pro kterou je odesílací SMTP server oprávněn odesílat, a bude se posuzovat důvěryhodnost této domény.

Poznámka: tento mechanismus ovšem poněkud smazává odolnost proti rhybaření, minimálně do doby, něž budou emailoví klienti schopni rozdílné From a Sender rozumně prezentovat uživateli. A i potom je otázka, kolik laických uživatelů bude schopno poznat případné podvodně podepsané dopisy.

Problém číslo 4 je možno řešit ještě tím, že uživatel bude odesílat firemní poštu vždy přes firemní SMTP, k němuž se připojí pomocí vlan nebo autentizuje přes SMTP autentizaci.

S přeposíláním pošty (problém číslo 2) DomainKeys nekolidují. Je ale nutno se zastavit u problému číslo 3 a konstatovat, že obecně proti němu DomainKeys nemají ochranu. Jediným řešením by bylo, aby server po té, co dopis přestaví, tento podepsal a odeslal za „svoji“ doménu.

Naštěstí pokud takové SMTP servery existují, tak jsou to ve většině případů okrajové (border) SMTP servery společností. S těmi ale problémy nejsou. Ty mohou při odeslání emailu tento podepsat za doménu společnosti a při přijetí naopak ověřit signaturu. Při putování dopisu po firemní síti již další ověřování není potřeba.

S modifikací (jenom) hlaviček si naštěstí DomainKeys poradit umí. Při vytvoření podpisu lze specifikovat, které hlavičky byly vzaty v potaz a v jakém pořadí. Takže když jsou hlavičky jinak uspořádány nebo je nějaká přidána, stále je možno platnost podpisu ověřit.

Dále je možno hlavičky „předpřipravit“ algoritmem, který spojí položky rozdělené na více řádků, takže jejich případné přerozdělení nemá na signaturu dopisu vliv.

Problémy algoritmu

Samotný algoritmus se mi docela zamlouvá, našel jsem v něm pouze jednu podstatnou vadu, a tou je zranitelnost pomocí „replay attacku“. Jde o to, že v případě, kdy můžete poslat mail libovolného obsahu z dané domény (což například u freemailů můžete), je možné takový mail poslat „sám sobě“. Příchozí mail bude samozřejmě mít správnou signaturu. Pak už je možno jej odeslat z libovolného serveru různým uživatelům (změnou adres v SMTP obálce) a bude stále korektně podepsaný.

Pro zamezení tomuto útoku by bylo nutné do algoritmu ještě přidat kontrolu adresáta (adresátů) v obálce. Zde se ovšem dostáváme do komplikací, pokud jde o email pro více příjemců, jelikož na různé servery odchází s různými obálkami. Nicméně mám za to, že i tento problém je řešitelný.

EBF16

Implementace

Pro účinnost toho standardu má samozřejmě zásadní význam jeho co největší rozšíření, přinejmenším na odesílací straně (tedy podepisování). V této oblasti toho zatím mnoho podniknuto nebylo. Yahoo, autor standardu, oznámilo jeho podporu, ale zatím ji neuvedlo do praxe. Zato GMail DomainKeys již na odesílací straně implementoval.

Ani jeden běžný mailserver zatím DomainKeys nepodporuje, nicméně podle slov autorů se pracuje na implementaci do Sendmailu.

Závěr


Vývoj na poli antispamových technologií sleduji již nějakou dobu. Z návrhů, které se objevily, mi DomainKeys přijdou jako nejrozumnější a nejméně konfliktní při poměrně slušné účinnosti.

Anketa

Jakou používáte antispamovou technologii?

59 názorů Vstoupit do diskuse
poslední názor přidán 1. 11. 2004 16:12

Školení App Store optimalizace

  •  
    Jak dostat svou mobilní aplikaci mezi lidi
  • Jak na akvizici uživatelů mobilních aplikací na českém i světovém trhu
  • Jak správně spustit, propagovat, měřit a vyhodnotit svoji aplikaci v Google Play i v Apple App Store

Detailní informace o školení App Store optimalizace »