Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: mikesznovu 09. 12. 2022, 15:13:25
-
Narazil jsem na službu https://dmarc.nu/en, kde mě zaujala jedna věc. po zadání pěti domén (tedy třeba alza.cz) jsem nabyl dojmu, že nevrací správné výsledky. False negatives
vrátí tyto výsledky (zajímá mě jen 3. boxík DKIM):
alza.cz vrací v pořádku ; selector found: 1 záznam : Office365
kostel.cz vrací v pořádku ; selector found 2 záznamy : Mailjet : mailjet._domainkey Google : google._domainkey
... jiná ... ; ... 2: mandrill
palermo.it ; fujfuj ; found zero . –– Přesto tato doména selektor má
nebo jakákoli jiná doména o které víte že má DKIM ale kontrola pro něj hlásí not found
... v kontrastu: google.com nebo jiné spol. používá dynamické selektory typu dkim-2022-10
Mě zajímá jak dochází k těmto selektorům? To jsou nějaká dobře známá jména? Pokud ano, je to nějaký důsledek "nařízení", že si oni diktují hodnotu DKIM selektoru?
Případně si to nějak domýšlí* z TXT záznamu SPF obsahujících include; nebo různýcch TXT typu site-verification? Toto domýšlení ale nemůže být dokonalé a taky očividně nenajde správný DKIM který zde není uveden
A nebo mě uplně převezli a mají to nějak fikaně? nechají si (jak ???) poslat mail z této domény, z nějž na to přijdou?
-
nelze, provozovatel si může určit sám prefix, který použije pro dkim key, nejsou v tom žádná pevná pravidla, můžeš se pokusit použít výchozí (tak to dělá i dmarc.nu), ale výsledky pro tebe mohou být nespolehlivé. Jediná spolehlivá cesta je mít email s hlavičkou a najít použitý selector.
-
Napadají mne dva způsoby, kterými je možné zjistit obsah DNS zóny. A v zóně pak najdete i DKIM selektory. Oba způsoby jsou založeny na komunikaci se slabě, či chcete-li nevhodně, konfigurovanými autoritativními name servery:
- správce dns serveru omylem či úmyslně povolí libovolnému klientovi tzv. zónový přenos,
- DNSSEC lze provozovat ve variantách NSEC nebo NSEC3. Starší NSEC v sobě skrývá problém v odpovědích informujících o neexistenci nějakého záznamu. Vizte google, klíčová slova dnssec zone walking.
-
Je nějaký důvod, proč "MRA" (MAIL RECEIVING AGENT) stahuje DKIM záznam z hodnoty "d" ( Signing Domain Identifier (SDID) ? Ta totiž nemusí být žádnou vazbu na adresu odesilatele.
Tam si přece útočník může napsat co chce (pořídit si nějakou doménu k tomu a na ni vyvěsit x._dkim.dom) a DKIM kontrola krásně projde , s podvrženou From hlavičkou jakou součástí hlaviček k podpisu hashe (to že DMARC alignment už ne je druhá věc)
Rozumněl bych tomu, kdyby běžné, strana příjemce by uváděla, tuto hodnotu a z toho by hned bylo vidět, pro jakou jinou doménu podpis sedí (pokud se neshodují) nebo kdyby výsledkem kontrol
https://www.samuraj-cz.com/clanek/overovani-emailu-pomoci-dkim-domainkeys-identified-mail/
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.
Je nějaký rozmuný důvod, proč tenhle tam vůbec je a nebere se hodnota pevně odněkud?
Jako jediná mi přichází v úvahu From v těle
( HELO ani MAIL FROM ne, znám maily, kdy se včechny čtyři liší)
From: zadané
HELO sparkpostmail.com
MAIL FROM bounce.ecomailapp.cz
DKIM xxx._domainkey.ecomailapp.cz
Mimochodem, v čem se liší služby ecomail a sparkpost z hlediska detailu "oboru"? Obě jsou z emailingu, dělá každéněco v jiné pod-oblasti?
-
Je nějaký rozmuný důvod, proč tenhle tam vůbec je a nebere se hodnota pevně odněkud?
Protože pro jednu doménu může být víc odesílajících klientů a každý může mít svůj klíč.
-
...kontrola (stahování ) veřejného dkim klíče z domény určené d=....
Je nějaký rozumný důvod, proč tenhle tam vůbec je a nebere se hodnota pevně odněkud?
Protože pro jednu doménu může být víc odesílajících klientů a každý může mít svůj klíč.
Ale víc klíčů řeší právě "s"elector.
txt : "s"._domainkey."d"
Nerozporuju možnost volby první část " s", ale druhé "d", že není pevná ve tvaru selector._domainkey.domenavzatazFrom:.com,
-
txt : "s"._domainkey."d"
Nerozporuju možnost volby první část " s", ale druhé "d", že není pevná ve tvaru selector._domainkey.domenavzatazFrom:.com,
d je doména toho, kdo e-mail podepisuje. To nemusí být ten, kdo je ve From. Třeba když poštovní konference přeposílá e-mail, ve From je ten, kdo zprávu poslal, ale e-mail musí podepsat provozovatel poštovní konference.