Ověřování emailů pomocí DKIM - DomainKeys Identified Mail -> SAMURAJ-cz.com

Tento článek navazuje na předchozí

DKIM vs. SPF

Pokud nastavíme SPF pro doménu, tak příjemce může detekovat, jestli někdo cizí zkusí odeslat email za danou doménu. Tedy kontrolujeme všechny zprávy, kde je adresa odesílatele z dané domény, a buď byla zpráva přijata z autorizovaného serveru nebo ne a je patrně podvržena.

Když používáme DKIM, tak příjemce kontroluje podpis pouze u podepsaných zpráv. Chyba podpisu nastane (v praxi nejčastěji), když se odesílatel rozhodne tuto technologii používat, ale špatně ji nastaví (například mu chybí veřejný klíč v DNS nebo po podepsání zprávy ještě provede modifikaci). Nebo pokud by ji někdo po cestě upravil. DKIM nám tedy nepomůže poznat, že se někdo cizí snaží podvrhnout email za doménu. Museli bychom pro danou doménu povolit pouze podepsané emaily. V praxi je pro nás zajímavá informace, že byl email korektně podepsaný. Ta se ale ke koncovému uživateli jednoduše nedostane. Navíc DKIM může korektně podepsat email úplně jinou doménou, než z jaké je zpráva odeslána.

DKIM a politiky?

Původní DomainKeys RFC 4870 (zastaralé) obsahovalo definici politiky, zda musí být emaily pro doménu podepsány. Mnoho návodů pro DKIM popisuje tuto politiku, i když DKIM norma nic takového neobsahuje. Politika se zapisuje jako _domainkey TXT záznam v DNS odesílající domény (příklad _domainkey.firma.cz). Obsah TXT záznamu může být (podporovány jsou i další značky) o=- všechny zprávy musí být podepsány nebo o=~ mohou být podepsány (výchozí hodnota).

Další možnost je rozšíření DKIM Author Domain Signing Practices (ADSP) popsané v RFC 5617, ale dnes se doporučuje využít DMARC, na který se podíváme příště. ADSP také definuje chování pomocí _adsp._domainkey TXT záznamu v DNS odesílající domény (příklad _adsp._domainkey.firma.cz). Obsah TXT záznamu je značka dkim= a hodnoty unknown (podepisuje některé nebo všechny zprávy), all (všechny zprávy jsou podepsané) a discardable (všechny zprávy jsou podepsané, pokud ne, tak má příjemce zprávu zahodit).

Prinicp DKIM - DomainKeys Identified Mail

Metoda DomainKeys Identified Mail (DKIM) je popsaná jako internetový standard v RFC 6376. V navržených standardech RFC 8301 a RFC 8463 je uvedena aktualizace používaných algoritmů, pro dosažení lepší bezpečnosti (známé zranitelnosti či slabiny). DKIM vzniklo spojením technik Yahoo DomainKeys a Cisco Identified Internet Mail.

DKIM je značně odlišné od SPF, ale také využívá záznam v DNS, kde se spoléhá na to, že záznamy vytváří majitel domény. Podpis standardně vytváří odesílající poštovní server (či brána). Nijak se ovšem neověřuje adresa serveru, který zprávu posílá či přeposílá. Vychází se z toho, že ten, kdo zprávu podepsal (vytvořil), vlastní soukromý klíč, a je tedy oprávněný odeslat email za danou doménu. Pokud je zpráva předávána dále dalšími servery, a nedojde k její modifikaci, tak je vše v pořádku.

Využívá se digitální podpis. Každý email je v hlavičce doplněna o položku, kde se nachází podpis zprávy pomocí privátního klíče. Odpovídající veřejný klíč pro doménu je uložen v DNS záznamu a každý pomocí něj může ověřit podpis zprávy. Podpisy nejsou přímo viditelné pro koncové uživatele a standardně je ověřuje server. Kontrola potvrzuje, že zpráva pochází od autorizovaného zdroje (dané domény), a že nebyla po cestě modifikována.

Podpis se přidává do položky hlavičky DKIM-Signature. Nijak tedy neovlivňuje zprávu a u příjemce (po cestě) není nutná podpora této technologie. Neklade žádné nároky na koncové uživatele, kteří nemusí řešit elektronické podpisy, certifikáty apod. Nepoužívají se certifikáty, takže se neřeší důvěryhodnost pomocí certifikačních autorit. Pro důvěryhodnost klíče se využívá DNS (že záznam může vložit pouze majitel). Pro digitální podpis se používá asymetrická kryptografie, ale princip se značně odlišuje od S/MIME či OpenPGP.

Jak funguje digitální podpis

Asymetrická kryptografie využívá dva klíče (veřejný, který se otevřeně distribuuje, a soukromý, který zná pouze majitel). Klíče se generují podle určitého kryptografického algoritmu (jako RSA či ECC), z privátního klíče můžeme spočítat veřejný. Nejznámější využití je pro

šifrování s veřejným klíčem - kdokoliv může data zašifrovat veřejným klíčem, rozšifrovat se dají pouze soukromým klíčem
digitální podpis (autentizace) - k podepsání dat se využívá soukromý klíč, pomocí veřejného může kdokoliv ověřit platnost

Digitální podpis funguje tak, že se pro podepisovaná data spočítá hash (pomocí určité hashovací funkce, jako je SHA256) a ten se zašifruje soukromým klíčem. Výsledná šifrovaná data jsou digitální podpis (podpis obsahuje také časové razítko, kdy k podpisu došlo). Pokud dojde ke změně dat, tak je podpis neplatný.

Při ověření podpisu se pomocí veřejného klíče rozšifruje podpis (hash). Pak se k datům spočítá hash (danou funkcí) a oba hashe se porovnají. Pokud jsou obě hodnoty stejné, tak je podpis platný.

Pozn.: Pokud se data zašifrují privátním klíčem, tak je možno je rozšifrovat pouze veřejným klíčem. A naopak zašifrovaná data veřejným klíčem se rozšifrují pouze soukromým.

DKIM podepisování poštovních zpráv

Pro použití DKIM musíme nejprve vygenerovat pár klíčů (soukromý a veřejný) dle daného algoritmu. DKIM podporuje více algoritmů digitálního podpisu. Podporovaný musí být RSA-SHA256 a je doporučený normou RFC 6376. Pro výpočet hashe se tedy použije SHA-256 a pro zašifrování RSA, kde je třeba volit dostatečnou délku klíče (klíče se také doporučuje pravidelně obměňovat).

RFC 8301 zakazuje použití SHA-1, určuje minimální délku RSA klíče 1024 bitů (dříve 512) a doporučenou 2048 bitů a musí být podporováno 4096 bitů. Praktický problém je, že dlouhý klíč se nevejde do DNS TXT záznamu, který má maximální délku 255 znaků (mělo by jít rozdělit klíč do více částí / řádků). RFC 8463 přidává algoritmus eliptických křivek Edwards-Curve Digital Signature Algorithm (Ed25519) k dříve jedinému RSA. To umožňuje bezpečné využití kratších klíčů. Pro digitální podpis je k dispozici algoritmus Ed25519-SHA256. Kvůli zpětné kompatibilitě je možno přidávat více podpisů k emailům (a v DNS mít více záznamů s různým selektorem).

Pozn.: V praxi se stále majoritně využívá RSA a délka klíče 1024 bitů. Například v poslední verzi dokumentace Cisco Email Security se uvádí, že bezpečná a doporučovaná délka klíče je 768 - 1024 bitů a nepodporuje delší než 2048.

Podepisování provádí zpravidla odesílající poštovní server (nebo brána), který vlastní soukromý klíč pro doménu. Do hlavičky emailu přidává položku (Header Field) DKIM-Signature. Tato položka má být brána jako trasovací (Trace Header Field) a tedy při přenosu zprávy musí být zachována a zůstávat ve stejném pořadí. Hodnota DKIM-Signature je seznam značek (Tag List) oddělených středníkem, tedy jednotlivé položky značka=hodnota (tag=value).

Používané značky (tagy) v DKIM-Signature

(P) znamená, že daná značka se musí v záznamu nacházet (je povinná).

v - version (P) - verze specifikace DKIM, zatím 1
a - algorithm (P) - algoritmus pro generování podpisu, standardně rsa-sha256 nebo nové ed25519-sha256
b - signature data (P) - podpis (hlavičky a dat) v Base64
bh - hash of body (P) - hash kanonikalizované (canonicalized) části těla zprávy (může být omezeno značkou l)
c - canonicalization - algoritmus kanonikalizace pro hlavičku/tělo, default je simple/simple
d - domain (P) - doména zprávy, v této doméně se hledá DKIM záznam
h - header fields (P) - seznam položek z hlavičky, oddělených dvojtečkou, které jsou podepsané
i - agent or user identifier - identifikátor agenta nebo uživatele, standardně zavináč a doména z d
l - length - délka těla zprávy po kanonikalizaci, z kterého se počítá hash, default je celé tělo
q - query methods - seznam dotazovacích metod pro získání veřejného klíče, default (a jediná možnost) dns/txt
s - selector (P) - selektor pro rozdělení prostoru jmen domény v DNS
t - timestamp - časové razítko, kdy byl podpis vytvořen
x - expiration - datum, kdy končí platnost podpisu
z - copied header fields - může zde být kopie hodnot položek hlavičky, oddělení pomocí |

Příklad položky DKIM-Signature v hlavičce

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seznam.cz; s=beta;
  t=1578641730; bh=/TD0lk+sB1gnEN1dbkIDJAt59PhptcTvRhtuO1OrpNs=;
  h=Received:From:To:Subject:Date:Message-Id:Mime-Version:X-Mailer:Content-Type;
  b=LfWqIXU+MPBXIgfdHqh5y6TGGK/avFzMX6Lu7mFKNE8sPSCIGV8Vy5iFIyUMqFvyj
  UnWwctBxpDJ8TuaCOHB3dMp0PD9CdmZGa/0vOJhFE/SxVHFVs/iUDR7HLvTvfG2PA9
  hwLQxdZAuX4PIDOGTgERxJ/FB9fxb0H3ga7FPuno=

Kanonikalizace - Canonicalization

Při přenosu poštovní zprávy by nemělo docházet k její modifikaci, přesto může dojít k sémanticky nevýznamných změnám (například změna velikosti písmen v hlavičce, přidání či odebrání bílých znaků). V takovém případě by byl podpis neplatný. DKIM nabízí možnost provést určitou definovanou úpravu dat (kanonikalizaci) před výpočtem hashe. Můžeme určit, že se používají originální data, parametr simple. Nebo se úprava provede, hodnota relaxed. Hodnota se zadává pro hlavičku/tělo. Výchozí je simple/simple, tedy bez úprav.

Výpočet hashů pro zprávu

Podpis i ověřování podpisu zprávy má jako základ výpočet dvou hashů. Podepisující (Signer) volí algoritmus a parametry, ověřovatel (Verifier) použije parametry z DKIM-Signature. První hash se počítá pro tělo zprávy (použije se uvedený kanonikalizační algoritmus (c) a délka se případně zkrátí podle (l)). Poté se převede na base64 a buď se vloží nebo porovná se značkou bh. Druhý hash se počítá pro zvolené položky hlavičky (vždy se započítává položka DKIM-Signature se značkou (b) prázdnou, na data se použije uvedený kanonikalizační algoritmus). Hash se následně podepíše daným algoritmem (a) a vloží jako značka b.

Podepisovat můžeme i položky hlavičky, které se ve zprávě nenachází. Tím zabezpečíme situaci, kdy by někdo cestou hlavičku doplnil (musíme počítat s tím, že určité hlavičky se po cestě doplňovat mají). RFC obsahuje seznam položek, které mají vztah k tělu zprávy, a tedy je dobré je podepisovat:

From (povinné)
Reply-To
Subject
Date
To, Cc
Resent-Date, Resent-From, Resent-To, Resent-Cc
In-Reply-To, References
List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

Některé položky hlavičky se mohou vyskytovat vícekrát, pak se podepisuje vždy poslední instance (prochází se odspodu nahoru). Pokud chceme podepsat více výskytů, tak musíme uvést položku vícekrát ve značce (h). Vícekrát můžeme uvést položku i v případě, kdy se aktuálně nachází pouze jednou. Tím zabráníme jejímu možnému dalšímu přidání.

Ověření DKIM podpisu poštovní zprávy

Ověření podpisu se doporučuje provést v době příjmu zprávy hraničním MTA (nečekat, až ke zprávě přistoupí koncový uživatel). Veřejný klíč může být kdykoliv zrušen, takže by se podpis nepovedlo ověřit, i když byl v době doručení platný. MTA může vložit výsledek ověření do položky v hlavičce. Koncový uživatel (poštovní klient) může využít tuto položku k filtrování zpráv.

Pozn.: SPF může odmítnout příjem zprávy již při přijetí SMTP příkazu MAIL FROM, kdežto DKIM musí přijmout celou zprávu.

Jak probíhá ověření podpisu poštovní zprávy

při příjmu zprávy se server (ověřovatel) podívá, zda se v hlavičce nachází položka DKIM-Signature
načte se DKIM-Signature ve zprávě a získají se parametry
pomocí selektoru (s) a domény (d) se sestaví DNS dotaz a hledá TXT záznam pro s._domainkey.d

Pozn.: Zaráží mne, že se ověřuje doména, která je uvedena v podpisu. Ta vůbec nemusí mít vazbu na domému v adrese odesílatele.

z DNS záznamu se získá veřejný klíč (a případně další parametry)
podle parametrů (c, l, h, a) se spočítají oba hashe zprávy
nejprve se porovná spočítaný hash pro tělo zprávy s načtenou hodnotou z podpisu (bh), pokud nesouhlasí vrací PERMFAIL
ověří se podpis (b) proti spočítanému hash hlaviček (podpis (b) se rozšifruje (a) veřejným klíčem, tím se získá hash hlaviček, který se porovná), pokud nesouhlasí vrací PERMFAIL
pokud nenastala chyba, tak byl podpis úspěšně ověřený, vrací SUCCESS (bylo ověřeno, že je email podepsán uvedenou doménou a zpráva nebyla upravena)

Pozn.: Pokud ověření selže, tak by neměla být zpráva odmítnuta, ale poskytnuta informace, proč nemůže být ověřena autentičnost zprávy.

Vyhodnocení ověření DKIM podpisu

Vyhodnocení (Evaluation) každého podpisu končí jedním ze tří stavů

SUCCESS - úspěšně ověřeno
PERMFAIL - ověření selhalo či jiná trvalá chyba
TEMPFAIL - dočasná chyba, například vypršení časového limitu DNS dotazu

Výsledek ověření podpisu by se měl předávat dále. Jedna z možností je přidat novou položku hlavičky (před existující DKIM-Signature). Jako vhodná se nabízí Authentication-Results.

Záznam veřejného klíče v DNS

DKIM podporuje více současných veřejných klíčů pro jednu doménu. K rozlišení se využívá Selector následovaný povinou částí _domainkey. Selektor může být třeba název lokality nebo datum (je v něm podporována tečka). Tak vzniká FQDN (subdoména), na kterém vytváříme záznam pro DKIM. Například leden.2020._domainkey.firma.cz. Vlastní záznam se publikuje jako DNS TXT (type 16) Resource Record (RR). Jeho formát je, podobně jako DKIM-Signature, složen ze značek oddělených středníkem.

Používané značky (tagy) v DKIM záznamu

(P) znamená, že daná značka se musí v záznamu nacházet.

v - version - verze záznamu DKIM klíče, pokud se použije, tak musí být první a obsahovat DKIM1
h - hash algorithms - dvojtečkou oddělený seznam přijímaných algoritmů hashe, default jsou všechny (sha256)
k - key type - šifrovací algoritmus, standardně RSA (nebo nový ed25519), znamená, že veřejný klíč je uložen jako ASN.1 DER-encoded RSAPublicKey (kódovaný pomocí base64)
n - notes - možné poznámky pro lidi
p - public-key data (P) - vlastní veřejný klíč, pokud je hodnota prázdná, tak to znamená, že byl odvolán
s - service type - pro jaké služby platí tento záznam, zatím možno pouze všechny *
t - flags - příznaky, y - tato doména testuje DKIM, s - pokud je v DKIM-Signature značka i, tak musí být doména stejná jako v d (nesmí jít o subdoménu)

Příklad DNS záznamu

"v=DKIM1;k=rsa;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8tt
kI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

Pro kontrolu DNS DKIM záznamu můžeme využít online služby, třeba DKIM Record Lookup, DKIM Record Check, DKIM Core Tools.

Praktické nasazení DKIM

Ověřování DKIM

To je jednoduché. Potřebujeme poštovní bránu (server), která podporuje DKIM (což Exchange Server není). Zapnutí ověřování je pak většinou jednoduché. Otázka je, jak reagovat na různé výsledky testu. U špatného podpisu můžeme doplnit informaci do předmětu zprávy. Pro uživatele je lepší vědět, že zpráva byla korektně podepsána, ale to není dobré umístit do předmětu. Další řešení je DMARC.

Příkladem brány s podporou DKIM je Cisco Email Security. Velmi stručně jsem zapnutí DKIM kontroly i podepisování zpráv popsal v článku Cisco Email Security - konfigurace AntiSpam řešení.

Podepisování DKIM

Potřebujeme poštovní server nebo bránu, která podporuje DKIM a bude provádět podepisování. Záleží, jakou podporu tento server má. Může nám vygenerovat klíče i připravit DNS záznam.

Obecné kroky, které musíme provést pro podepisování

určení algoritmů a vlastností a vygenerování klíčů
určení selektoru a vytvoření DNS záznamu na naší subdoméně
zapnutí podepisování zpráv při odesílání

Generování klíčů

Nejprve potřebujeme vygenerovat pár klíčů a k tomu rozmyslet, jaký chceme použít algoritmus (zatím asi jednoznačně RSA) a jakou délku klíče (pro praxi asi 1024 bitů nebo 2048 bitů).

Pro vygenerování klíčů můžeme použít řadu způsobů

webovou službu - z pohledu bezpečnosti není dobré řešení, protože klíče má 3tí strana
podepisující aplikaci - řešení, které nám bude vytvářet DKIM podpis, může podporovat i generování klíčů, například Cisco Email Security
OpenDKIM - sada nástrojů pro Linux
OpenSSL - známá sada nástrojů pro Linux, kompilovaná i pro Windows
PuTTYgen - nástroj pro generování klíčů, na Windows má GUI (součást balíku PuTTY)

Na Linuxu je nejlepší použít OpenDKIM, na Windows se dá velmi jednoduše využít OpenSSL for Windows.

Generování soukromého klíče

cd c:\Program Files\OpenSSL-Win64\bin

openssl genrsa -out DKIM-private.key 1024

Výsledný soubor vypadá následně:

Výpočet veřejného klíče

openssl rsa -in DKIM-private.key -pubout -out DKIM-public.key

Výsledný soubor vypadá následně:

DNS záznam pro DKIM veřejný klíč

Pro zvolený selektor (dkim2020) a doménu (firma.cz), například dkim2020._domainkey.firma.cz, vytvoříme TXT DNS záznam (Resource Record). Jeho hodnotu definujeme pomocí značek, povinná je pouze p, kam vložíme veřejný klíč bez hlavičky, patičky a konců řádků. Můžeme dočasně použít značku t=y, že jde o testování.

v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPtGH8e0rsuw7+Une1zYfuQ4taFz0dmQZqUVRaUN3ty+YLKMYS2ntfRJsIjVGoEOVxunJM
nTZwHNK2EhteyAMLSQ/sHFlE3couty1ExmsJHjeBdgBuvOubrxAID10lvUUTTTwCqryGwIac59NRaVNsqLfQJnghus1g7BUV9ASSNQIDAQAB

Prohlédnout záznam můžeme jednoduše, třeba řádkovým příkazem na Windows.

nslookup

> set type=txt
> dkim2020._domainkey.firma.cz
Server:  ns.firma.cz
Address:  192.168.0.10

Non-authoritative answer:
dkim2020._domainkey.firma.cz    text =

"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPtGH8e0rsuw7+Une1zYfuQ4taFz0dmQZqUVRaUN3ty+YLKMYS2ntfRJsIjVGoEOVxunJM
nTZwHNK2EhteyAMLSQ/sHFlE3couty1ExmsJHjeBdgBuvOubrxAID10lvUUTTTwCqryGwIac59NRaVNsqLfQJnghus1g7BUV9ASSNQIDAQAB"

Pro kontrolu DNS DKIM záznamu můžeme využít online služby, třeba DKIM Record Lookup, DKIM Record Check, DKIM Core Tools.

Podepisování zpráv pomocí DKIM

Pokud náš poštovní server (brána) podporuje DKIM, tak je zapnutí podepisování relativně jednoduché. Například na Cisco Email Security Configuring DomainKeys and DKIM Signing.

Pokud pro odesílání používáme Microsoft Exchange Server, tak máme relativně smůlu, protože on-premises Exchange DKIM nepodporuje (na rozdíl od cloudového Exchange Online). Ale můžeme využít nějaký AddOn (Transport Agent) od třetí strany:

Exchange DKIM Signer - často zmiňovaný na internetu, LGPL licence
DkimX - komerční SW s trial verzí
DKIM for Exchange Server and IIS SMTP Service - komerční SW s trial verzí

Vyzkoušel jsem Exchange DKIM Signer, který se na Exchange instaluje jako Transport Agent. Má tedy plný přístup ke všem poštovním zprávám, které zpracovává (ono by to jinak nešlo). Takže musíme zvážit důvěryhodnost instalovaného pluginu.

Stručná dokumentace DKIM Signing Agent for Microsoft Exchange Server. Běžná instalace znamená

stáhnout poslední verzi DKIM-Exchange Releases.
z balíku spustit Configuration.DkimSigner.exe
tlačítko Install stáhne větší balík z webu a nainstaluje knihovny podle verze Exchange Server
instalace je do C:\Program Files\Exchange DkimSigner, správu provádíme pomocí Configuration.DkimSigner.exe
instaluje se jako Transport Agent, můžeme si vypsat pomocí Get-TransportAgent, po instalaci by měl být poslední Exchange DkimSigner
při správě pomocí tlačítka Configure můžeme zkontrolovat, že je poslední
na záložce DKIM Settings můžeme přidat položky hlavičky, které se podepisují, a nastavit algoritmus a kanonikalizaci, pro aplikaci volíme úroveň logování
na záložce Domain Settings nastavujeme jednotlivé domény, pro které se mají podepisovat zprávy, můžeme vygenerovat klíče nebo načíst vlastní soubor, je zde i navržený DNS záznam veřejného klíče

Agent Exchange DkimSigner nepodepisuje zprávy ve formátu TNEF (Transport Neutral Encapsulation Format, označuje se také jako Outlook Rich Text Format). Tento formát podporuje Microsoft Outlook (pokud zprávu otevírá nepodporovaný klient, tak většinou vidí email s přílohou winmail.dat). Exchange server běžně používá tento formát v rámci Exchange organizace, ale při odesílání na vzdálené příjemce (Remote Domain) je převádí na HTML či jiný formát.

Online kontrola DKIM

Ve chvíli, kdy nakonfigurujeme podepisování zpráv pomocí DKIM, tak můžeme využít některou ze služeb, která nám provede kontrolu, že jsou zprávy korektně podepsané. Buď pošleme mail na zadanou adresu a dostaneme v odpovědi report. Nebo se nám na webové stránce zobrazí adresa, na kterou opět odešleme mail, a na webu uvidíme výsledek testu. Testuje se více vlastností než pouze DKIM.

www.SAMURAJ-cz.com

Kategorie článků

Nástroje

Hledání

Články