DKIM

From NMS
Jump to: navigation, search
Jednoduché nasadenie DKIM, zdroj: Microsoft Corp.

Úvod

Jednoducho povedané, DomainKeys Identified Mail (DKIM) definuje autentizačný mechanizmus s cieľom overiť pôvod a integritu emailových správ. Vo svojej podstate je DKIM založený na báze kryptografickej metódy s verejným kľúčom, pomocou ktorého je odosielateľ správy emailovej pošty autentizovaný na úrovni celej internetovej domény.

DKIM vzniklo ako kombinácia dvoch sprvu samostatných techník - DomainKeys od spoločnosti Yahoo! a Internet Identified Mail, ktorú vyvinula firma Cisco. Jedná se o dve rôzne originálne riešenia, ktoré boli vyvinuté separátne a o ich spojení bolo rozhodnuté v 07/2005.

Popis DomainKeys od Yahoo! by sa dal zjednoušene zhrnúť takto: odosielajúci systém vygeneruje svoj podpis a ten vloží do hlavičky správy. Príjmajúcia čast tento jedinečný reťazec skotroluje prostredníctvom verejného kľúča, ktorý si obstará zo záznamu v DNS (Domain Name System). Na druhú stranu autentizačná technika od firmy Cisco síce tiež využíva šifrovanie, ale na rozdiel od predchádzajúceho prípadu spojuje vytvorenú signatúru so samotnou emailovou správou. V tomto prípade mailový server správu podpíše a vytvorený podpis vrátane verejného kľúča vloží do novo vygenerovanej hlavičky. Príjemca potom overí platnosť správy tým, že si overí, či verejný kľúč využitý k podpisu správy je ten správny.

Technológia DKIM má vlastnosti obidvoch pôvodných riešení a využíva zároveň DNS na autentizáciu odosielateľa a zároveň metódu podpisovania jednolitvých správ. Takto navrhnutý systém preto podáva jednoznačný dôkaz a poskytuje ochranu identite a integrite emailových správ a ich odosielateľom. Úspešne teda asistuje pri celosvetovom boji proti spamu a phisingu a naviac zaručuje zachovanie funkcie elektronickej pošty, tak ako ju poznáme dnes. Bojovníci proti spamu a phisingu vytiahli do boja so systémom, ktorý pozitívne zvýhodňuje slušných komunikujúcich, namiesto nekonečnej penalizácie spammerov a odosielateľov nevyžiadanej pošty.

Medzi základné ciele DKIM systému patrí automatizované, pre koncového uživateľa transparentné overovanie obsahu správy, ktoré môže byť delegované na tretiu stranu. To všetko za minimálnych nákladov spojených s nasadením, vývojom a použitím.


Čo DomainKeys Identified Mail nie je

  • DKIM neposkytuje žiadne záruky o faktickej identite podpisujúceho.
  • DKIM nepredpisuje žiadne špecifické reakcie pri úspešnom resp. neúspešnom overení podpisu. Tieto reakcie (napr. odmietnutie správy, zmena predmetu správy, umiestnenie do špeciálnej zložky v schránke, whitelist, atp.) musí zabezpečiť antispamová engina mailservru.
  • DKIM neposkytuje ochranu správy po jej prijatí.
  • DKIM nechráni pred preposlaním, znovuodoslaním či odpovedi na správu, ktorá už má validný podpis. Preto, je teoreticky možné zmeniť príjemcu bez vedomia odosielateľa


Štandardizácia

Systém DKIM sa momentálne nachádza v štádiu štandardizácie IETF. Boli vypracované podrobné štúdie a analýzy nasadenia, použitia v praxi, analýza bezpečnosti, identifikované potenciálne nebezpečia a sú pripravené podklady pre vývojárov, integrátorov a správcov mailových serverov.

Pracovná skupina, ktorá sa touto problematikou zaoberá zhrnula svoj význam, ciele a plán práce vo svojej charte.

Pre výskumníkov a širsiu odbornú verejnosť bol zriadený diskusný list, ietf-dkim, ktorý centralizuje pripomienky, návrhy a koordinuje úsilie.

Na oficiálnych stránkach projetku zverejnila pracovná skupina všetky dôležité štandardizačné dokumenty a koncepy:

Na téma DKIM a širsie poňaie bezpečnosti emailovej komunikácie sa usporiadali veľké odborné konferencie v Paríži 08-2005 a Vancouveri 11-2005.

Ďalšie, menšie odborné konferencie, semináre a workshopy priebiehajú kontinuálne a o ich konaní sa je možné dočítať na oficiálnych stránkach projektu a pracovnej skupiny.


Technické podrobnosti

Základné elementy, selektor, tagy a použité algoritmy

Pojem selektoru, zoznam použitých tagov, využitie kryptografických algoritmov sú súčasťou konceptuálneho návrhu DKIM a preto je dôležité s nimi pracovať v kontexte podpisovania a overovania podpisu v rámci konštrukcie DKIM. Nie sú to pojmy, ktoré sa priamo viažu na účastníkov DKIM, ale k samotnému systému DKIM ako takému.


Selektory

Aby bolo možné paralelne používať niekoľko verejných kľúčov pre podpisovanie jednej domény, priestor mien kľúčov je rozdelený použitím "selektorov". Napríklad selektory môžu indikovať polohu kancelárie ("trojanova", "brehova"), pobočku ("decin", "praha", "rez"), čas podpisu ("cerven2006", "srpen2006"), či dokonca jednotlivého uživateľa.

Selektory môžu obsahovať bodku (".") a znamená oddelovač komponetov. Ak sú kľúče a seletory uložené v DNS záznamoch, "bodka" znamená oddelenie subdomény. Sub-selektory môžu byť použité napríklad na kombinovanie dátumu a miesta polohy ("cerven2006.praha"). Vlastnosť selektoru umožňujúca jednoduché delenie na subselektory môže byť využitá pri delegovaní časti podpisových práv.

Počet verejných kľúčov a korešpondujúcich selektorov pre doménu nie je ničím obmedzený a záleží výhradne na správcoch domény a prípadne veľkosti prevádzky. Okrem administratívneho pohodlia, využitie sub-selektorov umožnuje pravidelnú zmenu verejného kľúča (napr. podľa dátumu) a teda k celkovému zvýšeniu bezpečnosti.


Zoznam tag=hodnota

DKIM používa jednoduchú syntax "tag=hodnota" hneď v niekoľkých situáciách (v poštových správach, v záznamoch DNS, atp.). Hodnoty sú reťazce obsahujúce buď text v base64, obyčajný text (plaintext) alebo text tlačiteľných znakov podľa definície v MIME RFC2045. Meno tagu pritom udáva spôsob kódovania hodnoty. Žiadne kódovanie však nesmie obsahovať znak ";", ten je vyhradený na oddelenie tagov.

Pre prácu s tagami platia nasledújúce doporučenia: Všetky tagy a ich hodnoty musia byť interpretované ako case-sensitive. V zozname tagov sa nemie vyskytovať duplicitne pomenovaný tag a ak sa v hodnote tagu vyskytne prázdny znak, musí byť zachovaný. Neznáme tagy sa ignorujú. Tag ktorý má prázdnu hodnotu, nie je to isté ako vynechaný tag. Vynechaným tagom sa priradzuje defaultná hodnota.


Podpisovacie algoritmy

Koncept DKIM umožňuje použiť viacero podpisovacích/verifikačných algoritmov. Dva algoritmy sú primo definované v špecifikácii, a to rsa-sha1 a rsa-sha256. Algoritmus rsa-sha256 je default, tj. je použitý vo všetkých prípadoch, keď nie je uvedené inak. Verifikačná strana musí vždy podporovať oba algoritmy. Podpisová strana musí podporovať vždy aspoň rsa-sha256. Na oba algoritmy rsa-sha1 i rsa-sha256 sú kladené štandardné bezpečnostné nároky podľa definícií v RFC3447. Do budúcnosti sa samozrejme počita s nasadením iných, nových kryptografických algoritmov.

Voľba dĺžky kľúča je individuálna pre každého správcu DKIM systému. Koncept DKIM obsahuje niekoľko doporučení ako optimálne zvoliť dĺžku kľúča pre zachovanie rýchlosti šifrovania a vhodného rizika. Pre daľsie informácie použite RFC3766, ktoré obsahuje na toto téma podrobnú analýzu.


Kanonická forma správy

Empirické pozorovania dokazujú, že niektoré nekorektné mailservery môžu pri prenose emailovej správy zmeniť jej obsah a tak zneplatniť podpis. Na túto problematiku sa líšia názory. Zatiaľčo veľká väčšina bežných uživateľov sa zhodne na tom, že jemné modifikácie obsahu správy sú nepodstatné, nájdu sa aj takí, ktorý omietajú akékoľvek zásahy do správy pri prenose a požadujú okamžité zneplatnenie podpisu a zlyhanie verifikácie. Iní zase povolia zmeny v hlavičkách (definované napr. v RFC2822), ale zmeny v tele správy sú pre nich neprípustné. Kanonizácia správy teda jednoducho znamená prípravu na podpis či verifikáciu a určuje hranice povolených zmien pri prenose správy. Systém DKIM preto ponúka dve kanonické formy elektronickej správy a jej hlavičky:

  • simple: defaultná jednoduchá kanonická forma, ktorá netoleruje skoro žiadne modifikácie,
  • relaxed: uvoľnená kanonická forma, ktorá toleruje bežné modifikácie ako napr. nahradenie prázdnych znakov, či zmenu formátovania

Verifikačná strana musí podporovať obe kanonické formy elektronickej správy, podpisová strana aspoň defaultnú jednoduchú kanonizáciu.


Hlavička "DKIM-Signature:"

Podpis emailu je uložený v hlavičke "DKIM-Signature:". Táto hlavička obsahuje celý podpis a data, ktoré sú potrebné pre vyzdvinutie verejného kľúča. Hlavička "DKIM-Signature:" by mala byť umiestnená ako prvá, tj. pred všetkými ostatnými hlavičkami emailovej správy.

Následuje prehľadná tabuľka povolených tagov v hlavičke "DKIM-Signature:"

Tag Názov Hodnota Popis Poznámka
v= verzia numerická Tag popisuje verziu špecifikácie DKIM. povinný, aktuálna hodnota 0.2
a= algormitmus plaintext Algoritmus použitý na generovanie podpisu rsa-sha1 alebo rsa-sha256 povinný
b= podpis base64 Data obsahujúce podpis povinný
bh= body hash base64 Data obsahujúce hash tela správy povinný
c= kanonizácia plaintext Definuje kanonickú formu správy voliteľný, default=simple
d= doména plaintext Názov domény podpisujúcej entity povinný
h= hlavičky plaintext Zoznam hlavičiek oddelených ":, ktoré boli podpísané voliteľný
l= dĺžka správy numerická Dĺžka podpísanej správy voliteľný, default=celá správa
q= dotazy plaintext Obsahuje zoznam metód dotazov na vyzdvihnutie verejného kľúča voliteľný, default=dns-txt
i= identita plaintext Indentita odosielateľa voliteľný
s= selektor plaintext Selektor deliaci priestor doménového mena ktoré sa definuje v d= povinný
t= timestamp plaintext Časová značka podpisu doporučený, default=neznáme
x= expirácia plaintext Časová expirácia podpisu doporučený, default=nikdy
z= kopírované hlavičky plaintext Zoznam kopírovaných hlavičiek oddelený zvislítkom doporučený, default=null


Príklad hlavičky

Nasleduje krátky ilustračný príklad použitia tagov v poli hlavičky DKIM-Signature: 

DKIM-Signature:v=0.2; a=rsa-sha1; d=cvut.cz; s=cerven2006
     c=simple; q=dns; t=1117574938; x=1118006938;
     h=from:to:subject:date;
     z=From:nekdo@cvut.cz|To:novak@cuni.cz|
       Subject:Jsme=20mistri|Date:June=205,=202006=203:44:08=20PM=20-0700
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR


Reprezentácia kľúča v DNS TXT zázname

Pre vyzdvihutie verejného kľúča z DNS, sú dôležité najmä tagy q=, d=, s= (prípadne aj i=). Tie definujú spôsob ako, miesto kde a selektor verejného kľúča pre doménu d=. DKIM špecifikácia obsahuje doporučenie, ako najlepšie skladovať, reprezentovať a uvádzať DKIM záznamy do TXT DNS záznamu. Navrhuje sa používať opäť metódu tag=hodnota. Nasledujúca tabuľka vysvetľuje použite jednotlivých tagov v TXT DNS:

Tag Názov Hodnota Popis Poznámka
v= verzia plaintext Verzia DKIM záznamu doporučený, default=DKIM1
g= granularita plaintext Granularita kľúča voliteľný, default=*
h= hašovacie algoritmy plaintext Povolené hašovacie algoritmu nepovinný, default=všetky
k= typ kľúča plaintext Definuje typ uskladneného kľúča nepovinný, default=rsa
n= poznámky quot.-print. Poznámky pre ľudskú obsluhu DNS nepovinný
p= verejný kľúč base64 Data obsahujúce verejný kľúč povinný
s= typ služby plaintext Definuje služby na ktoré sa DKIM použije (definované sú dve= email,* ) nepovinný, default=všetky
t= značky plaintext Značky, y=testovací provoz DKIM, neznáme značky sa ignorujú nepovinný


DomainKeys, zdroj: antispam.yahoo.com/domainkeys

Postup podpisovej strany

  1. Určiť či má správa byť podpísaná a ak áno tak kým
  2. Vybrať súkromný kľúč a korešpondujúci selektor (A)
  3. Normalizovať správu kvôli prenosovým konverziám, vybrať vhodnú kanonickú formu správy
  4. Vybrať hlavičky ktoré budú podpísané
  5. Vypočítať hash tela správy a vygenerovať podpis (B)
  6. Vložiť hlavičku "DKIM-Signature:"


Postup verifikačnej strany

  1. Extrahovať podpis z prijatej emailovej správy
  2. Zaobstarať verejný kľúč z DNS TXT záznamu pre doménu (C)
  3. Vypočítať verfikačný hash podľa zistených informácií o type použitého algoritmu
  4. Vygenerovať a predať výsledky overenia dalším programom
  5. Interpretovať výsledky v svetle konkrétych pravidiel a podniknúť kroky, ako napríklad označiť správu ako spam, odmietnuť doručenie, umiestniť správu do špeciálneho adresára, použiť greylisting, ... (D)


DKIM a DomainKeys

DomainKeys ako jeden z podkladových projektov pre systém DKIM má niekoľko zásadných rozdielov, ako filozofických tak aj technických.


Filozofické rozdiely

  • DKIM rozšírilo DNS DK záznam, ktorým povoľuje pridanie niekoľkých parametrov.
  • DKIM umožňuje scenár v ktorom sa podpisovateľ a autor správy líšia. Toto rozšírenie, umožnuje preniesť podpisovaciu procedúru na autorizovanú dôveryhodnú tretiu stranu a zároveň umožnuje popisovať správy uživateľom, ktorý sú inak nezávislí na doménovom mene autora správy. Na druhú stranu koncept však počíta s možnosťou reštrikcie podpisového kľúča len na určité typy služieb (ako napr. email) a následnú kontrolu delegovaných tretích strán
  • DKIM si samo podpíše hlavičku "DKIM-Signature" a tak ju chráni pred modifikáciami
  • Kvôli rôznych prenosovým systémom elektronickej pošty musí DKIM spracovávať data správy v kanonickej forme (napr. zaobchádzanie s tabulátormi, medzerami, atp.). DKIM proti DomainKeys predstavilo "relaxed canonicalization" namiesto "nofws"
  • Originálny koncept DomainKeys dovoľoval zúženie použitia podpisového kľúča na jednolivú poštovú schránku (uzivatel@domena.cz), DKIM navyše počíta s podporou zástupných znakov (wildcards) v názvoch schránok (napr. "uzvatel+*"). Takáto podpora zjednoduší dnes bežné, i keď neoficiálne praktiky subadresácie a kategorizácie uživateľov elektronickej pošty vo firmách
  • DKIM musí explicitne vymenovať všetky použité hlavičky, ktoré boli podpísané. Takéto konzervatívne vylepšenie je navyšekorektné a je robustnejšie pri prenose cez neštandardné mailservery
  • DKIM podporuje časové odozvu podpisu (signature timeout). Je teda možné, aby súčastou podpisu bola aj explicitná doba odozvy DNS servera na uspokojenie dotazov na podpisový kľúč.
  • Návrh DKIM obsahuje spôsob, ako spracovávať duplicitné hlavičky a povoľuje nastavenie limitov na dĺžku správy


Technické rozdiely

  • Kvôli odlíšeniu od DomainKeys, DKIM používa na uskladnenie podpisu inú hlavičku podľa RFC2822
  • DKIM má rozdelenú kanonalizáciu hlavičky a tela správy
  • DKIM umožňuje použiť viac-písmenné názvy tagov
  • DKIM nepodporuje hlavičku "DomainKey-X509:"
  • Na miestach kde DomainKeys vyžadoval skalár, DKIM používa polia oddelené stredníkom (napr. zoznam metód hľadania kľúča a atribút t=)
  • DKIM povoľuje kopírovanie orginálnych hlavičiek a ich hodnôt
  • Uzivateľ DKIM má možnosť obmedziť dĺžku kľúčov na hashovanie algoritmov a to ako v zozname, tak v záznamoch DNS


DKIM a Sender Policy Framework

Jednoducho povedané, tieto techniky sa vzájomne výborne dopĺňajú. Z nadsázkou sa dá povedať, že kde výborne funguje DKIM tam má problémy SPF (Sender Policy Framework) a naopak. Naštastie DKIM a SPF môžu pracovať paralelne a vzájomne sa vhodne dopĺňať.

SPF podobne ako DKIM si kladie za cieľ odstrániť možné podvhry pri odosielaní mailu. Dosahuje toho tak, že doména vo svojom TXT zázname definuje, ktoré servery sú povolené odosielať elektronické správy s adresou odosielateľa v tejto doméne. Maily z ostatních domén sú považované za falzifikáty. SPF podobe ako DKIM definuje celý systém ako servery špecifikovať - pomocou rozsahov IP, MX záznaov, atp. U jednolivých pravidiel je možné naviac špecifikovať prefix, podľa ktorého sa pozná, čo sa bude v negatívnom prípade s mailom diať (odmietnutie, označenie ako spam, ...)

Narozdiel od DKIM, ktoré ako počíajú s určením odosielateľa len z hlavičky emailovej správy (hlavičky Sender: a From:), SPF berie ako primárne údaje z SMTP serveru (z príkazov HELO a MAIL FROM:)


Klady a zápory SPF proti DKIM

Klady a zápory SPF s prihliadnutím ku DKIM sa väčšinou zhŕňajú nasledovne:

  • - všetci odosielatela musia používať výhradne niektorý z oficiálnych odosielacích SMTP serverov domény
  • - SPF využíva TXT záznam domény ako takej, a to nie je moc čisté
  • + jednoduchšie zavedenie autorizácie ako DKIM, stačí vytvoriť záznam v DNS
  • + dovoľuje zahodiť správu po špecifikovaní Mail From a nemusí sa prenášať celá
  • + SPF je menej náročné na CPU
  • - celkovo je však kvôli väčšiemu počtu DNS lookupov pomalejšie.

Dá sa však zhrnúť, že SPF a DKIM poskytujú rôzne informácie a preto sa spoľahlivo dopĺňajú. Zatiaľčo SPF overuje faktický pôvod (miesto odoslania) správy, DKIM sa spolieha na podpis a integritu.


Výhody DKIM oproti S-MIME a OpenPGP

DKIM je založené na doménových menách a nie na kompletnej emailovej adrese. Preto je podpisovanie kontrolované administrátorom domény a nie jednotlivým uživateľom.

DKIM používa samopodpísané certifikáty pre DNS. Pretože je rozsah DKIM limitovaný na použitie v elektronickej forme, nevyžaduje silné dlhodobé certifikáty vydané certifikačnými autoritami.

S/MIME a OpenPGP sú techniky zamerané na dlhodobejšiu osobnú ochranu, preto obsahujú jemnejšie mechanizmy identifikácie jednolivého uživateľa.

Obe S/MIME a OpenPGP so svojej podstaty vyžadujú modifikáciu tela správy. DKIM nemodifikuje telo správy. DKIM umiestni do hlavičky parametrické údaje, ktoré sú pred bežným príjemcom elektronickej správy ukryté a sú využité len mailservrami. DKIM sa pre túto vlastnosť často nazýva "neviditeľná" technika.


Vzťah k ostatným internetovým štandardom

Pretože DKIM je implementované v súlade s RFC 2822 a rešpektuje pravidlá vytvárania DNS záznamov je DKIM spätne kompatibilné s existujúcom emailovou infraštruktúrou. Je navyše transparetné aj pre existujúce emailové systémy ktoré nepodporujú DKIM.

DKIM bolo navrhnuté tak, aby bolo kompatibilné zo všetkými ďalším vylepšeniami systému elektronickej pošty. DKIM je plne kompatibilnés SPF, S/MIME, OpenPGP a novým návrhom bezpečného DNS DNSSEC.


Potenciálne hrozby a útoky na DKIM

Zhrnutie predpovedaných útokov na podpisy DKIM:

Popis Riziko Pravdepodobnosť
Krádež súkromého kľúča domény vysoké malá
Krádež delegovaného súkromného kľúča stredné stredná
Extrakcia súkromného kľúča pomocou postranných kanálov vysoké malá
Útok typu "chosen message" malé stredná
Odpoveď pomocou podpísanej správy malé vysoká
Útok odmietnutím verifikačnej služby vysoké stredná
Útok odmietnutím služby obstaravajúcej kľúče vysoké stredná
Zneužitie kanonalizácie malé stredná
Zneužite dĺžky tela správy stredné stredná
Použitie zneplatnených kľúčov stredné malá
Zkompromitovanie servera správy kľúčov vysoké malá
Falizifikácia odpovedí verifikačnej služby stredné stredná
Publikovanie nepravých kľúčov a/alebo podpisov vysoké malá
Kryptografické slabiny generovania podpisu vysoké malá
Útok z vnútra firmy - insider attack vysoké stredná
Útok skúškou verifikácie stredné stredná
Publikovanie kľúča domény vyššieho rádu vysoké malá

Útoky proti pravidlám podpisovania:

Popis Riziko Pravdepodobnosť
Podobne znejúce meno domény vysoké vysoká
Zneužitie IDN domény vysoké vysoká
Použite viacero From adries malé stredná
Zneužitie podpisov tretích strán stredné vysoká
Falizifikácia odpovedí podpisovacieho algoritmu stredné stredná

Implementácia v rôznych programovacích jazykoch


Moduly pre mailservery a rozšírenosť vo svete

Komerčné i nekomerčné firmy, implementujúce DKIM do svojich produktov sú uvedené v nasledujúcej prehľadnej tabuľke. Je isté, že po úplnej štandardizácii, sa počet mailserverov podporujúcich DKIM určite zvýši.

Názov Modul web
Alt-N Mdeamon mdaemon, libdkim http://www.mdaemon.com
Apache spamassassin http://spamassassin.apache.org
Port25 powerMTA http://www.port25.com
Sendmail dkim-milter https://sourceforge.net/projects/dkim-milter/
Strongmail strongmail https://www.strongmail.com/
dkimproxy for Postfix dkimproxy http://home.messiah.edu/~jlong/dkimproxy/
mail-dkim for Postfix mail-dkim http://home.messiah.edu/~jlong/dkimproxy/
OmniTI ecelerity http://www.omniti.com/
Exhalus DKeyEvent for MailEnable http://www.mailenable.com/
DKeyEvent for SmarterMail http://www.smartertools.com/Products/SmarterMail/Overview.aspx
MerakMail MerakMail Server http://www.merakmail.com/merak_instant_antispam/


Príklad inštalácie a konfigurácie dkimproxy pre postfix

Tieto inštrukcie popisujú nasadenie dkimproxy pre mailový systém postfix. Verifikačný systém je inštalovaný ako filter typu "before-queue" a podpisovací systém ako filter typu "after-queue". Príchodzia pošta bude obslúžená cez port 25 a odchodzia pošta bude smerovaná na port 587.


Inštalácia

Postup:

  1. Stiahnite si poslednú stabilnú verziu dkimproxy na http://home.messiah.edu/~jlong/dkimproxy/
  2. Vyberte kam si prajete inštalovať dkimproxy, napr. /usr/local/dkfilter
  3. Z adresára ktorý obsahuje zdrojový kód dkimproxy spusťte konfiguračný skript ./configure a ako parameter udajte vybrané miesto inštalácie filtra, napr.

 ./configure --prefix=/usr/local/dkfilter

  1. Spusťte make install. Dkimproxy filter sa nainštaluje do požadovaného adresára. Perlovské skripty budú umiestnené do podadresára /bin/ a súbory modulu do /lib/
  2. Vytvorte uživateľa alebo skupinu uživateľov pre spúštanie dkfilter, napr. dkfilter
  3. Vytvorne spúštací skript pre filter. Môžete použiť pripravený init-script.sh


Nastavenie a konfigurácia príchodzej (verifikačnej) proxy

Verifikačná proxy používa tieto parametre:

  • --reject-fail

ak je použitý, príchodzia správa, ktorá zlyhá pri verifikácii bude odmietnutá

  • --reject-error

ak je použitý, a počas príjmania správy, dôjde k chybe systému, bude vygenerovaná dočasná chyba (4xx), a bude umožnené znovu doručiť spávu neskôr

  • --hostname=HOSTNAME

určuje hostname použité v hlavičke výsledkov autentifikácie, ktorá bude pridaná k verifikovanej správe

Ručný štart verifikačnej proxy: dkimproxy.in 127.0.0.1:10025 127.0.0.1:10026 Proxy bude odpočúvať port 10025 a prenášať cez port 10026.

Konfigurácia verifikačnej proxy ako postfix filter typu "before-queue" pre dkimproxy.in prebieha tak, že príchodzí SMTP trafic (na port 25) je presmerovaný proxy na port 10025 a forwardované spojenia sú príjmané na porte 10026. 


/etc/postfix/master.cf:
#
# Before-filter pre SMTP server. Prijmi spravy z interneru a 
# preposli ich na content filter na localhost:100025
#
smtp      inet  n       -       n       -       -       smtpd
 -o smtpd_proxy_filter=127.0.0.1:10025
 -o smtpd_client_connection_count_limit=10
#
# After-filter pre SMTP server. Prijmi spravy od DKIM verifikacnej proxy 
# na localhost:10026.
#
127.0.0.1:10026 inet n  -       n       -        -      smtpd
 -o smtpd_authorized_xforward_hosts=127.0.0.0/8
 -o smtpd_client_restrictions=
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_recipient_restrictions=permit_mynetworks,reject
 -o smtpd_data_restrictions=
 -o mynetworks=127.0.0.0/8
 -o receive_override_options=no_unknown_recipient_checks

Po úpravách v súbore reloadujte postfix príkazom "postfix reload"


Nastavenie a konfigurácia podpisovacej proxy

Podpisovacia proxy potrebuje prístup ku privátnym kľúčom, potrebuje vedieť aký selektor a aká doména sa má použiť pri podpisovaní. Tieto nevyhnutne dôležité informácie sú špecifikované ako parametre príkazovej riadky pre dkimproxy.out


Postup vygenerovania páru kľúčov a publikovanie verejného na DNS

  1. Generuj súkromný a verjný kľúč pomocou OpenSSL:

     openssl genrsa -out private.key 1024
     openssl rsa -in private.key -pubout -out public.key

Tieto príkazy vygenerujú v aktuálnom adresári súbory private.key and public.key, ktoré obsahujú súkromný a verejný kľúč.

  1. Vyberte názov selektoru napr. praha01
  2. Vložte verejný kľúč do DNS, do záznamu vašej domény použitím vybraného selektoru. Vezmite obsah súboru pubkey.pem, odstráňte PEM hlavičku, patičku a z riadkov v súbore vytvorte jeden dlhý riadok. Potom vytvorte záznam TXT, ktorý by mal vyzerať nasledovne:
praha01._domainkey IN TXT "k=rsa; p=eRDQwwERJK ... OprwIDBQAA; t=y"

parameter p= obsahuje verejný kľúč ako dlhý reťazec písmen.

Konfigurácia parametrov príkazovej riadky pre dkimproxy.out:

  • --reject-error

ak je použitý, a počas príjmania správy, dôjde k chybe systému, bude vygenerovaná dočasná chyba (4xx), a bude umožnené znovu poslať spávu neskôr, alebo odoslať nepodpísanú

  • --keyfile=KEYFILE

povinný parameter, cesta k súboru s privátnym kľúčom

  • --selector=SELECTOR

povinný parameter, meno použitého selektoru

  • --domain=DOMAIN

povinný paramter, špecifikuje ktoré domény sú podpisované, viac domén sa oddeľuje pomocou čiarky (,)

  • --method=METHOD

metóda kanonizácie a výberu kanonickej formy správy, ak nie je uvedené použije sa simple.

Ako príklad použitia: 

dkimproxy.out --keyfile=/usr/local/dkfilter/private.key --selector=praha01 \
 --domain=cisco.cz,yahoo.cz --method=relaxed \
 127.0.0.1:10027 127.0.0.1:10028

Nakoniec je potrebné nakofigurovať postifx tak, aby filtroval odchodziu autorizovanú poštu cez dkimproxy.out na port 10027. Následujúci príklad ukazuje ako nastaviť poštu odosielanú cez port 587 tak, aby šla cez filter typu "after-queue", ktorý správu podpíše DKIM podpisom. 

/etc/postfix/master.cf:
#
# zmenit defaultne nastavenie na specificky obsahovy filter
# a obmezit na lokalnych a autorizovanych klientov
#
submission  inet  n     -       n       -       -       smtpd
 -o smtpd_etrn_restrictions=reject
 -o smtpd_sasl_auth_enable=yes
 -o content_filter=dksign:[127.0.0.1]:10027
 -o receive_override_options=no_address_mappings
 -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
#
# nastavit umiestnenie DKIM podpisovej proxy 
#
dksign    unix  -       -       n       -       10      smtp
 -o smtp_send_xforward_command=yes
 -o smtp_discard_ehlo_keywords=8bitmime
#
# sluzba pre akceptovanie sprav od DKIM podpisovej proxy
#
127.0.0.1:10028 inet  n  -      n       -       10      smtpd
 -o content_filter=
 -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
 -o smtpd_helo_restrictions=
 -o smtpd_client_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_recipient_restrictions=permit_mynetworks,reject
 -o mynetworks=127.0.0.0/8
 -o smtpd_authorized_xforward_hosts=127.0.0.0/8


Po úpravách v súbore /etc/postfix/master.cf reloadujte postfix príkazom "postfix reload"


Ďalšie informácie

Odkazy

Retrieved from "https://nms.fjfi.cvut.cz/wiki/index.php?title=DKIM&oldid=1769"