Jak obměnit DKIM klíče, aniž byste ohrozili doručování pošty

Obměna neboli rotace DKIM klíčů je plánovaná výměna páru klíčů, kterým se podepisuje vaše pošta: zveřejníte nový veřejný klíč v DNS pod novým selektorem, přepnete podepisování na nový soukromý klíč a starý pár vyřadíte.

Oborové sdružení Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), které vydává osvědčené postupy pro provozovatele e-mailových služeb, doporučuje obměňovat DKIM klíče nejméně jednou za šest měsíců pro případ, že by klíč někdo odcizil.

Tento průvodce je určený týmům, které už mají funkční DKIM a spravují vlastní domény nebo domény klientů. Dozvíte se z něj vše, co potřebujete vědět o tom, jak DKIM klíče obměňovat, i o tom, co hrozí, když je obměňovat nebudete.

Pokud teprve zjišťujete, kterými klíči se pošta vaší domény podepisuje, začněte naším průvodcem, jak najít DKIM selektor; tento článek na něj navazuje.

Co najdete v tomto průvodci

• Jaké riziko představuje starý DKIM klíč?
• Kdo má obměnu DKIM klíčů na starosti?
• Jak často obměňovat DKIM klíče?
• Jak obměnit klíč, aniž byste narušili podepisování?
• Jak ověřit, že obměna proběhla úspěšně?
• Časté dotazy
• Praktické shrnutí

Jaké riziko představuje starý DKIM klíč?

S kompromitovaným klíčem může útočník posílat zprávy, které projdou ověřením, jako by pocházely z vaší domény. Soukromý klíč se v DNS nikdy nezveřejňuje: je uložený na poštovních serverech a odesílacích platformách, které vaše zprávy podepisují, a útočník, který do některého z těchto systémů pronikne, si ho může zkopírovat.

Útočník pak vaším soukromým klíčem podepíše vlastní zprávu. Přijímající poštovní server získá z DNS váš veřejný klíč a podpis ověří jako platný.

Protože se podepisující doména shoduje s doménou ve vaší adrese From, projde zpráva i kontrolou DMARC, která porovnává ověřenou doménu s adresou From. Přijímající servery uplatňují vaši DMARC politiku jen na poštu, která kontrolou DMARC neprojde, takže i při p=reject zprávu podepsanou vaším vlastním klíčem doručí.

Toto riziko uvádí M3AAWG jako důvod k pravidelné obměně: čím kratší dobu se pár klíčů používá, tím kratší dobu zůstává kompromitovaný klíč zneužitelný.

Kdo má obměnu DKIM klíčů na starosti?

Kdo má obměnu na starosti, poznáte ze dvou věcí: z typu DNS záznamu zveřejněného pro každý selektor a z toho, zda platforma, která daným selektorem podepisuje, obměňuje klíče podle vlastního harmonogramu. Typ záznamu zjistíte tak, že otevřete nastavení DNS své domény (u Cloudflaru, GoDaddy, svého registrátora domény nebo kdekoli jinde, kde DNS spravujete) a najdete záznamy, jejichž název začíná vaším selektorem, za kterým následuje ._domainkey. Ve sloupci s typem záznamu je u každého z nich uvedeno TXT nebo CNAME.

Pokud DNS vaší domény spravuje někdo jiný, podívejte se místo toho na stránku s nastavením DKIM v každé odesílací platformě: tato stránka uvádí záznamy, o jejichž přidání vás platforma požádala, tedy buď CNAME záznamy, nebo jeden TXT záznam s dlouhou hodnotou klíče.

TXT záznam obsahuje samotný veřejný klíč, takže pro každý nový klíč musíte ve svém DNS zveřejnit nový TXT záznam. Obměnu proto provádíte vy, i když pár klíčů vygenerovala platforma, jako to dělá Google Workspace.

CNAME záznam s názvem selektoru je alias, který odkazuje na záznam spravovaný platformou. Soukromý klíč má platforma a každý nový veřejný klíč může v tomto záznamu zveřejnit, aniž byste museli cokoli měnit ve svém DNS.

Z typu záznamu poznáte, kdo může klíč vyměnit. Nepoznáte z něj ale, kdy k výměně dojde: některé platformy obměňují klíče podle vlastního harmonogramu, jiné čekají, až obměnu spustíte vy. Takto obměnu řeší čtyři odesílací platformy:

Každý klíč zveřejněný jako TXT záznam a každý klíč, u kterého platforma čeká, až obměnu spustíte vy (tak to funguje u Microsoft 365), obměňujete sami. U odesílací platformy, která v této tabulce chybí, zkontrolujte tytéž dvě věci: typ záznamu u jejího selektoru a dokumentaci poskytovatele k tomu, kdo obměnu spouští. Případ Salesforce, včetně nastavení pro jednotlivé produkty Salesforce, popisuje náš průvodce, jak DMARC funguje s e-maily odesílanými přes Salesforce.

Pokud spravujete DKIM pro domény klientů, podle doporučení M3AAWG má o obměnu žádat vlastník domény. Každé datum obměny se svým klientem dohodněte a změny v DNS i v podepisování proveďte v dohodnutý den.

Jak často obměňovat DKIM klíče?

Klíče, které obměňujete sami, doporučuje M3AAWG obměňovat nejméně jednou za šest měsíců. Členové M3AAWG ve svém dokumentu DKIM Key Rotation Best Common Practices porovnali různé frekvence obměny a šestiměsíční interval zvolili jako rovnováhu mezi rizikem kompromitace klíče a prací spojenou s jeho výměnou. Dokument navrhuje pevně stanovené termíny mimo období, kdy nejvíc prodáváte, například duben a říjen u e-shopu.

Před plánovaným termínem obměňte klíče ve dvou situacích:

• Při podezření na kompromitaci obměňte klíč okamžitě a starý klíč zneplatněte, jakmile je nový klíč v provozu, místo abyste ho nechali zveřejněný 7 až 30 dní jako v postupu se souběhem popsaném níže. Opožděná legitimní pošta podepsaná starým klíčem pak kontrolou DKIM neprojde, ale neprojdou jí ani podvržené zprávy podepsané odcizeným klíčem.
• Když ukončujete spolupráci s dodavatelem nebo se zaměstnancem, kteří měli přístup k infrastruktuře pro podepisování, obměňte klíče, které si mohli zkopírovat.

Při každé obměně zkontrolujte délku klíče. RFC 8301 vyžaduje, aby podepisující strana používala klíče RSA o délce nejméně 1024 bitů, a doporučuje 2048 bitů, takže pokud DNS záznam některého selektoru stále obsahuje 1024bitový klíč, vygenerujte jeho náhradu s délkou 2048 bitů.

Jak obměnit klíč, aniž byste narušili podepisování?

Při souběhu dvou selektorů vyměníte klíč, aniž by selhal jediný podpis, protože selektor v každé zprávě odkazuje na veřejný klíč, který je v DNS stále zveřejněný. Během souběhu zůstávají zveřejněné oba veřejné klíče, každý pod vlastním selektorem, zatímco vy přepínáte podepisování ze starého soukromého klíče na nový.

Kroky níže platí pro případ, kdy vaši poštu podepisuje váš vlastní poštovní server. Na platformě, která pár klíčů generuje za vás, jako je Google Workspace, vytvoříte nový klíč a přepnete podepisování v administraci platformy, ale DNS záznamy i tak zveřejňujete a později zneplatňujete sami.

1. Vygenerujte nový pár klíčů a veřejný klíč zveřejněte v DNS pod novým selektorem. M3AAWG důrazně nedoporučuje používat názvy selektorů opakovaně. Pokud název obsahuje datum, například mail-202604, můžete selektory seřadit podle toho, kdy se který klíč začal používat.
2. Počkejte, až bude nový záznam viditelný ve veřejném DNS, tedy až dotaz do DNS na název nového selektoru, například mail-202604._domainkey.yourdomain.com, vrátí nový veřejný klíč. Váš poštovní server novým klíčem zatím nepodepisuje, takže během čekání nemůže selhat žádný podpis.
3. Na svém poštovním serveru přepněte podepisování na nový soukromý klíč. Nové zprávy pak v parametru s= obsahují nový selektor a přijímající servery je ověřují pomocí nového veřejného klíče.
4. Záznam starého klíče nechte zveřejněný 7 až 30 dní. Přijímající servery mohou dál ověřovat poštu podepsanou před přepnutím, včetně opožděných zpráv a zpráv čekajících ve frontě, protože starý veřejný klíč je stále zveřejněný.
5. Starý klíč zneplatněte tak, že jeho záznam změníte na v=DKIM1; p= (tedy s prázdnou hodnotou p=). RFC 6376 definuje prázdnou hodnotu jako zneplatněný klíč. M3AAWG doporučuje záznam v DNS ponechat a nemazat ho, aby přijímající server, který starý selektor vyhledá, našel záměrně vyřazený klíč místo chybějícího záznamu.

U Microsoft 365 probíhá stejný souběh na straně Microsoftu: oba selektory zůstávají zveřejněné a Microsoft přepne podepisování na nový klíč čtyři dny (96 hodin) poté, co obměnu spustíte.

Jak ověřit, že obměna proběhla úspěšně?

Pokud DMARC záznam vaší domény obsahuje parametr rua= (adresu, na kterou přicházejí reporty), přijímající servery na tuto adresu posílají souhrnné DMARC reporty. V těchto reportech obměnu uvidíte: zprávy podepsané novým selektorem začnou procházet ověřením a zprávy podepsané starým selektorem se přestanou objevovat. M3AAWG doporučuje zhruba týden po každé obměně provést kontrolu: porovnejte selektor, který zaznamenaly přijímající servery, se selektorem, který měl být podle harmonogramu aktivní.

Pokud se vyřazený selektor ve vašich reportech dál objevuje, je něco špatně. Nejdřív prověřte dvě možné příčiny: službu, u které klíč nikdo neobměnil a která stále podepisuje starým klíčem, a klíč obměněný jen na jedné straně. Ve druhém případě poštovní server podepisuje jedním klíčem, zatímco DNS záznam obsahuje jiný, a přijímající servery u těchto zpráv vyhodnotí kontrolu DKIM jako neúspěšnou.

DMARCeye reporty čte za vás a pro každou doménu zobrazuje selektory, kterými se vaše pošta podepisuje, takže uvidíte i selektor, který se už neměl objevovat. Bezplatný plán zahrnuje jednu doménu.

U platforem, které používají běžné názvy selektorů, například selector1 a selector2 u Microsoft 365, vám bezplatná kontrola DKIM níže ukáže klíč zveřejněný pod každým selektorem a sílu tohoto klíče. Pomocí této kontroly najdete 1024bitový klíč, který je čas nahradit 2048bitovým klíčem. Vlastní názvy selektorů, jako je mail-202604, kontrola nevyhledává.

Časté dotazy

Potřebujete při každé obměně nový název selektoru?

Ano. M3AAWG důrazně nedoporučuje používat názvy selektorů opakovaně: jakmile záznam pod znovu použitým názvem obsahuje nový klíč, přijímající servery vyhodnotí kontrolu DKIM jako neúspěšnou u každé zprávy podepsané starým klíčem, včetně zpráv, které ještě nebyly doručeny. Z názvu, který obsahuje datum obměny, například billing-202604, navíc poznáte, kdy se který klíč začal používat.

Ohrozí obměna klíčů e-maily, které jste už odeslali?

Ne, pokud starý klíč během souběhu necháte zveřejněný. Přijímající servery ověřují podpis ve chvíli, kdy zpráva dorazí, a starý klíč necháváte zveřejněný 7 až 30 dní proto, aby opožděná pošta podepsaná tímto klíčem dorazila a prošla ověřením dřív, než klíč zneplatníte. Po zneplatnění zůstane už doručená pošta doručená a selže jen pozdější opakované ověření staré zprávy.

Mění se v DKIM2 postup obměny klíčů?

Podle současných návrhů DKIM2 obměňujete klíče stejně. IETF pracuje na DKIM2, plánovaném přepracování DKIM, a jeho návrh pro DNS stanovuje stejný model klíčů: odesílatelé zveřejňují veřejné klíče v DNS pod selektory a klíč zneplatňují prázdnou hodnotou p=.

Praktické shrnutí

Obměna DKIM klíčů je plánovaný úkol a do harmonogramu musíte zařadit jen klíče, které obměňujete sami. Kompromitovaný klíč pak zůstane zneužitelný jen do příští plánované obměny, a ne až do chvíle, kdy si někdo všimne incidentu.

Roztřiďte své odesílací platformy podle typu záznamu u každého selektoru a podle toho, zda platforma obměňuje klíče v rámci vlastního harmonogramu. Pro každý klíč, který obměňujete sami, naplánujte obměnu dvakrát ročně a obměňte ho dřív, pokud máte podezření na kompromitaci nebo když odejde někdo, kdo měl přístup k vašim podpisovým klíčům. Každou změnu provádějte jako souběh dvou selektorů, aby žádná zpráva nikdy neodkazovala na chybějící klíč.

Pokud dostáváte souhrnné DMARC reporty, ověříte si v nich každou obměnu: obměna je dokončená, když v naplánovaný den zprávy podepsané novým selektorem procházejí ověřením a starý selektor se přestane objevovat. DMARCeye zobrazuje, kterými selektory se podepisuje pošta každé z vašich domén, takže každou obměnu můžete kontrolovat průběžně s tím, jak přicházejí denní reporty.