O standardu DomainKeys Identified Mail jsme již před časem psali, detailní popis vyšel také již poměrně dávno na Lupě. Jedná se o systém zabezpečení obsahu e-mailových zpráv před změnou prostřednictvím elektronického podpisu. Od zavedených systémů PGP a S/MIME se liší především tím, že podepisování může provádět kterýkoli článek e-mailové infrastruktury, takže není nezbytně nutné vyžadovat používání této technologie po uživatelích.
Také se zde nepoužívá ani hierarchie veřejných klíčů, ani síť důvěry; veřejný klíč potřebný k ověření podpisu se jednoduše umístí do DNS v podobě TXT záznamu. Ačkoli se zde také používá obecný typ záznamu TXT, kolizi s jinými účely se brání předepsaným prefixem _domainkey, za který je připojena doména, která má být zdrojem podpisu. Aby bylo možné klíče hladce měnit a/nebo používat různé klíče v různých částech organizace, je každý DNS záznam s klíčem uvozen tzv. selektorem, což může být naprosto libovolný řetězec, splňující požadavky na platné DNS jméno.
Nejde o náhradu SPF
Ačkoli se zdá, že účel, ke kterému DKIM existuje, je podobný účelu SPF, které jsme popsali minule, není tomu tak. Připomeňme, že SPF řeší pouze autorizaci e-mailového serveru, či obálkové adresy odesílatele, která je předávána v průběhu SMTP komunikace. SPF nijak nezkoumá ani hlavičky, ani vlastní obsah e-mailové zprávy. Proti šíření nejrůznějších podvržených zpráv, sloužících nejčastěji phishingu, které mají v pořádku obálkovou adresu odesílatele, žádným způsobem nepomáhá.
DKIM naopak autorizuje obsah zprávy, zcela bez ohledu na to, jakým způsobem byla zpráva doručena. Samotný standard DKIM také na rozdíl od SPF nepředepisuje žádnou politiku, která by stanovovala co se má stát se zprávami, jejichž elektronický podpis nevyhoví. Dokonce jeden z cílů DKIMu vyžaduje, aby zprávy s nevalidním DKIM podpisem byly hodnoceny stejně jako zprávy bez jakéhokoli podpisu. To umožňuje DKIM podepisování nasadit beze strachu ze zhoršení spolehlivosti e-mailového systému.
Podepisování snadno a rychle s OpenDKIM
Pro vlastní podepisování a ověřování podpisu je možné použít nástroj OpenDKIM. Ten se chová jako milter, který lze snadno napojit na současné poštovní servery. Nejprve zvolíme selektor (nemáte-li fantazii, letopočet bude dobrou volbou) a vygenerujeme klíč pro podepisování:
$ opendkim-genkey -s 2015 -b 2048 V aktuálním adresáři vzniknou dva soubory s názvem <selektor>.private a <selektor>.txt. První obsahuje privátní klíč, který je potřeba nakopírovat do /etc/dkim, druhý soubor pak obsahuje DNS záznam, který je potřeba vložit do domény, jejímž jménem má být podepisováno:
2015._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIB…QAB" ; ----- DKIM key 2015 for example.com Klíč pro podepisování je následně nutné nastavit v konfiguračním souboru /etc/opendkim.conf spolu s nezbytnými nastaveními pro integraci s Postfixem na Debianu:
Domain example.cz
KeyFile /etc/dkim/2015.private
Selector 2015
Socket local:/var/spool/postfix/opendkim/opendkim.sock
Umask 002 Na straně Postfixu pak stačí nastavit správně práva a zařadit milter jak pro příchozí SMTP zprávy, tak pro lokálně odeslané zprávy:
# mkdir /var/spool/postfix/opendkim
# chown opendkim:opendkim /var/spool/postfix/opendkim
# gpasswd -a postfix opendkim
# postconf -e smtpd_milters=unix:opendkim/opendkim.sock
# postconf -e non_smtpd_milters=unix:opendkim/opendkim.sock
# service postfix restart Od té chvíle OpenDKIM podepisuje zprávy z domény, pro kterou má klíč, a validuje podpisy pro všechny ostatní. Je možné také nastavit více klíčů pro různé domény a podepisovat správným klíčem v závislosti na doméně odesílatele. Další podrobnosti jsou k nalezení v manuálu opendkim.conf.
Kanonizace a přepodepisování hlaviček
Při konfiguraci podepisovacího softwaru jsou k dispozici další volby, které by neměly uniknout administrátorově pozornosti. Tou první je kanonizace, tedy jakási předúprava hlaviček a těla zprávy před provedením vlastního elektronického podpisu. Standardní nastavení na hodnotu simple/simple, žádnou úpravu neprovádí a tak k poškození elektronického podpisu dojde i sémanticky nevýznamnou změnou hlaviček (úprava velikosti písmen názvů hlaviček) či obsahu (přidání či odebrání bílých mezer). Ačkoli asi panuje všeobecná shoda na tom, že systémy předávající poštu by takové úpravy dělat neměly, není od věci zabezpečit DKIM tak, aby i takto upravená zpráva byla validovatelná. K tomu slouží nastavení kanonizace na relaxed/relaxed (první hodnota se vztahuje k hlavičkám, druhá k tělu zprávy).
Další zajímavou volbou je vynucené podepsání některých hlaviček, byť ve zprávě nejsou přítomny. Vzhledem k tomu, že hlavičky se během cesty zprávy sítí přidávají, nepodepisuje DKIM všechny, ale pouze ty, které byly vyjmenovány ve volbě h= v samotném DKIM podpisu. Typicky bude obsahovat něco jako:
h=Date:From:To:Subject:From; Vyskytuje-li se hlavička vícekrát, musí ji i metadata podpisu obsahovat vícekrát; při validaci se přibírají hlavičky postupně odspodu. Hlavičky, které nejsou v seznamu uvedeny, případně další výskyty uvedených hlaviček, nejsou do podpisu zahrnuty. Pokud v nastavení OpenDKIM ponecháme zapnutou volbu OversignHeaders From, bude do podpisu zahrnuta i neexistující druhá hlavička From. Díky tomu případný útočník nemůže do zprávy dodatečně vložit druhou hlavičku From, která by nebyla DKIMem kryta a mohla tak příjemce zprávy uvést v omyl, kdo je skutečným autorem zprávy.
Dlužno ale poznamenat, že RFC 5322 vícenásobné použití hlavičky From zapovídá. Stejný princip je ale možné použít také třeba pro hlavičku Reply-To, čímž bychom útočníkovi zabránili nedetekovatelně odklonit odpovědi na zprávu na jinou adresu.
Ověřování v Thunderbirdu
Protože k ověřování podpisů stačí samotná zpráva, tak jak je uložena v poštovní schránce, je možné podpis ověřovat i přímo v poštovním klientovi. Pro Thunderbird existuje rozšíření DKIM Verifier, které DKIM validuje při načítání zprávy a o výsledku informuje podbarvením adresy odesílatele.
validní podpis, podepsaný autorovou doménou
validní podpis, podepsaný třetí stranou
nevalidní podpis
Politika podepisování ADSP
Samotný DKIM nijak nestanovuje, co se má stát se zprávami, které podepsané nejsou, ani to, jakou váhu má DKIM podpis od jiné domény než té, která je uvedena v adrese odesílatele. Aby mohl DKIM opravdu pomoci proti šíření podvržených zpráv, definuje RFC 5617 politiku Author Domain Signing Practices. Jedná se o další DNS záznam typu TXT na pevně dané subdoméně _adsp._domainkey, který může definovat jednu ze tří politik:
| název | význam |
|---|---|
dkim=unknown |
politika neexistuje (výchozí) |
dkim=all |
všechny zprávy mají být podepsány autorovou doménou |
dkim=discardable |
zprávy, jejichž validace selže, mají být zahozeny |
Nejpřísnější politika discardable je určena výhradně pro domény, které odesílají strojem generované e-maily, u kterých je důležitý boj proti podvrženým zprávám, například automatická sdělení bankovních institucí, případně pro domény, které vůbec nejsou určeny pro e-mail. Tato volba není určena pro domény, ve kterých mají schránky uživatelé. To proto, že existuje několik málo legitimních služeb, případně služeb na hranici, které přísnou podmínku podepsání nesplní, ale je žádoucí, aby byly přesto doručeny. Takovou službou může být posílání e-pohlednic či článků e-mailem, nebo mnohem častěji e-mailové konference.
Problém s e-mailovými konferencemi
Elektronický podpis, který DKIM používá, chrání zprávu a několik jejích hlaviček před modifikací a je tedy nekompatibilní s většinou systémů, které zprávy modifikují. Pokud tedy máte ve své síti antivir, který s oblibou do všech zpráv připíše „Odchozí zpráva neobsahuje viry, zkontrovoláno nejlepším antivirem na světě“, případně vás právní oddělení donutilo ke každému e-mailu připsat „právní doložku“ nutící nahodilé příjemce zprávu okamžitě smazat a všechno, co v ní bylo napsáno, zapomenout, je nutné takové systémy buď nepoužívat, nebo zařadit ještě před vytvoření DKIM podpisu.
Zařízení, která legitimně zprávu modifikují, jsou i e-mailové konference. U nich je žádoucí, aby zpráva přeposlaná od konference převzala identitu toho, kdo ji do konference odeslal. Zároveň ale konference zprávu často modifikuje způsobem, který není slučitelný s DKIM podpisem:
- odstraňuje nevhodné přílohy
- přidává patičku s informacemi o konferenci
- přidává název konference do předmětu zprávy
- přidává hlavičku
Reply-Tona adresu konference
Problém je poměrně obsáhlý a nemá jediné vždy správné řešení. Věnuje se mu celé RFC 6377, publikované též jako BCP 167. Jedním z navržených postupů, jak se má konference chovat k podepsaným zprávám, které modifikuje, je následující:
- validovat všechny DKIM podpisy
- výsledek validace uložit do hlavičky
Authentication-Resultspři současném odstranení všech předchozích hlaviček tohoto typu - odstranit ze zprávy všechny hlavičky s DKIM podpisy
- podepsat zprávu vlastním klíčem, do podepsaných hlaviček přitom zahrnout i hlavičku
Authentication-Results
Konference, která zprávy modifikuje, by také měla odmítat příspěvky a pokusy o přihlášení od adres v doménách, jejichž ADSP politika je stanovena na discardable. Takové zprávy by totiž po modifikaci konferencí byly nejspíše odmítnuty, což by konference mohla nesprávně vyhodnotit jako nefunkční schránku a respondenta odhlásit.
Pozitivní vylepšení s minimem negativních efektů
Standard DKIM byl primárně vyvinut jako vylepšení stávajícího systému s důrazem na možnost postupného nasazení bez rizika poškození funkčnosti stávající e-mailové infrastruktury. Postupně zprávy podepsané DKIMem začaly být zvýhodňovány velkými hráči na poli elektronické pošty, což zvýšilo zájem o technologii, zejména mezi rozesílateli hromadné obchodní korespondence.
Politika ADSP, jejímž cílem je použít DKIM k vynucení jistého standardu v doručování zpráv již tak úspěšná není, zejména s ohledem na e-mailové konference, jejíchž velká část doposud není DKIM-friendly. Následky tohoto problému jsou ale mnohem mírnější než v případě problému s přeposíláním pošty u SPF.
Ačkoli je politika ADSP stále používána, začíná být postupně vytlačována standardem DMARC, který z ADSP vychází a přestavuje obecný rámec konzistentního nakládání s výsledky validace jak DKIMu, tak i SPF. Budeme se mu věnovat v příští části seriálu.
