DKIM: selectoare, rotația cheilor și chei de 2048 de biți

Cum funcționează DKIM

DomainKeys Identified Mail (RFC 6376) permite unui sistem expeditor să semneze anteturile selectate și corpul unui mesaj cu o cheie privată. Semnătura este adăugată ca antet DKIM-Signature, iar cheia publică pereche este publicată în DNS, în zona domeniului care semnează. Destinatarul preia cheia, verifică semnătura și află astfel că părțile semnate nu au fost modificate din momentul semnării. În felul acesta autentificarea este legată de mesajul în sine, nu de adresa IP de la care a fost livrat.

Două etichete din semnătură decid unde se află cheia: d= este domeniul care semnează, iar s= este selectorul. Destinatarul le combină într-un nume DNS și caută exact acolo o înregistrare TXT. Pentru DMARC este nevoie în plus ca domeniul din d= să fie aliniat cu domeniul From al mesajului; o semnătură validă, dar nealiniată, nu ajută cu nimic rezultatul DMARC.

Alegerea selectoarelor

Un selector este doar o etichetă, așa că alegeți nume care vă ușurează munca de zi cu zi. Selectoarele permit fiecărui sistem expeditor să aibă propria cheie și, în timpul rotației, permit unei chei vechi și uneia noi să existe în paralel. Numele apare în fiecare semnătură pe care o trimiteți, deci evitați numele interne de proiect sau de furnizor pe care nu ați vrea să le vadă toată lumea.

Furnizorii găzduiți aleg de multe ori selectorul în locul dumneavoastră. Microsoft 365 folosește selector1 și selector2, publicate ca înregistrări CNAME care trimit spre cheile administrate de el, iar Google Workspace folosește implicit google. Celelalte servicii de trimitere își documentează propriile nume în setările de autentificare a domeniului, deci înregistrarea pe care v-o cere pagina de configurare arată chiar selectorul folosit.

Nu puteți lista selectoarele unui domeniu din DNS, pentru că DNS nu are un director al numelor de sub _domainkey. Ca să aflați ce selector folosește un sistem, citiți eticheta s= din antetul DKIM-Signature al unui mesaj primit de la el, de exemplu lipind anteturile în Analizorul de anteturi de e-mail, care vă arată valoarea în câteva secunde.

Înregistrarea cheii

Cheia publică este o înregistrare TXT a cărei valoare este o listă de etichete. Dintre acestea, numai p= este obligatorie; v=DKIM1 ar trebui să fie prima atunci când este prezentă. Un p= gol înseamnă că acea cheie a fost revocată, iar semnăturile făcute cu ea nu mai sunt validate de nimeni.

s2026a._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxyz...IDAQAB"

Trecerea la chei de 2048 de biți

RFC 8301 a actualizat în 2018 cerințele criptografice ale DKIM. Cine semnează trebuie să folosească chei RSA de cel puțin 1024 de biți și ar trebui să folosească cel puțin 2048, iar cine verifică trebuie să poată valida chei de la 1024 până la 4096 de biți. Același RFC spune că rsa-sha1 nu trebuie folosit la semnare, deci fiecare semnătură pe care o produceți ar trebui să folosească a=rsa-sha256.

O cheie de 1024 de biți se validează în continuare, dar oferă o marjă de securitate mult mai mică, iar norma pentru cheile noi este acum 2048 de biți. Cheile mai mari de 4096 de biți nu sunt garantat validate de toți destinatarii, deci nu există niciun câștig dacă treceți de acest prag. Cheile Ed25519 (RFC 8463) sunt scurte și puternice, însă suportul din partea destinatarilor este încă incomplet, așa că se folosesc alături de o semnătură RSA, nu în locul ei.

Cum încape o cheie de 2048 de biți în DNS

Cheia publică RSA de 2048 de biți are, în base64, în jur de 400 de caractere. Un singur șir TXT ține cel mult 255, deci valoarea trebuie împărțită în mai multe șiruri între ghilimele, pe care destinatarii le lipesc fără spații între ele. Multe panouri DNS fac împărțirea automat; altele cer șirurile introduse separat, iar unele resping pur și simplu valorile lungi.

s2026a._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1SU1LfVLPHCozMxH2Mo4lgOEePzNm0tRgeLezV6ffAt0gunVTLw7onLRnrq0/IzW7yWR7QkrmBL7jTKEn5u+qKhbwKfBstIs+bMY2Zkp18gnTxKLxoS2tFczGkPLPgizskuemMghRniWaoLcyehkd3qqGElvW/VDL5AaWTg0nLVkjRo9z+40RQzuVaE8AkAFmxZzow3x+VJYKdr0"
  "CDy4jW3O/DmMvPiLqxgPVdl2i1tq+cn8hNQfvCyYe7Tnz4hWDYO0H1vPD1xJyV04BGcoJp1stVpvYy23wu8bN7DI+CWVuW5emFS2bIyCj3Q1YeW4+sPvgOvzP99l1OjMrBb4FBHGKQIDAQAB" )

Verificați rezultatul publicat cu Interogare DNS, folosind tipul de înregistrare TXT pentru numele selectorului. Valoarea lipită trebuie să fie exact cheia pe care o folosește sistemul dumneavoastră de semnare; un singur caracter lipsă sau în plus face ca toate semnăturile să eșueze cu dkim=fail.

Rotația cheilor fără a strica e-mailul

Rotația limitează paguba produsă de o cheie privată scursă și scoate din uz cheile vechi și slabe. Șmecheria este că semnăturile se verifică atunci când mesajul ajunge la destinație, ceea ce poate însemna minute sau chiar zile după semnare, dacă un mesaj este întârziat sau este verificat din nou mai târziu. Prin urmare, cheia publică veche trebuie să rămână publicată o vreme și după ce ați încetat să mai semnați cu ea.

1. Generați o pereche nouă de chei și alegeți un selector nou, de exemplu s2026b.
2. Publicați noua cheie publică la s2026b._domainkey.example.com și așteptați cel puțin TTL-ul înregistrării, ca toate resolverele să o poată vedea.
3. Verificați înregistrarea interogând-o și, dacă sistemul dumneavoastră permite, trimițând un mesaj de test semnat cu noul selector.
4. Mutați semnarea pe noul selector în fiecare sistem care îl folosea pe cel vechi.
5. Păstrați cheia publică veche publicată o perioadă de grație, de obicei de la o săptămână la câteva, ca mesajele întârziate să se valideze în continuare.
6. Revocați cheia veche publicând v=DKIM1; p= pentru vechiul selector, iar mai târziu ștergeți complet înregistrarea.

s2026a._domainkey.example.com. IN TXT "v=DKIM1; p="

Cât de des faceți rotația este o decizie de politică internă. Multe organizații rotesc cheile o dată la șase până la douăsprezece luni și imediat atunci când o cheie privată ar fi putut fi expusă, de exemplu după compromiterea unui server sau la încheierea relației cu un furnizor. Furnizorii găzduiți care folosesc delegare prin CNAME rotesc după propriul calendar și nu vă cer nicio intervenție.

Testarea unei chei noi înainte de comutare

O cheie publicată greșit face să eșueze fiecare semnătură care o folosește, deci verificați înainte de a muta traficul de producție pe ea. Mai întâi interogați înregistrarea TXT a noului selector și comparați valoarea p= cu cheia publică derivată din cheia dumneavoastră privată. Un singur caracter greșit, un șir lipsă dintr-o înregistrare împărțită sau un spațiu strecurat din greșeală sunt de ajuns ca verificarea să nu mai reușească.

# public key derived from the private key, as one base64 line
openssl rsa -in s2026b.private.pem -pubout -outform DER 2>/dev/null | openssl base64 -A; echo

# published value (strings joined)
dig +short TXT s2026b._domainkey.example.com | tr -d '" \n'; echo

Apoi semnați un mesaj de test cu noul selector, dacă sistemul vă lasă să îl alegeți, și trimiteți-l către o căsuță de la un furnizor mare. Antetul Authentication-Results ar trebui să arate dkim=pass, iar lângă el header.s=s2026b. Abia după ce vedeți acest rezultat mutați tot traficul pe noul selector.

Opțiuni de semnare care contează

Canonicalizarea

Eticheta c= decide cât de strict sunt comparate spațiile și scrierea cu majuscule a numelor de anteturi. c=relaxed/relaxed tolerează micile modificări de formatare făcute de serverele de e-mail de pe traseu și este alegerea obișnuită; simple se strică mult mai ușor.

Ce anteturi semnați

Antetul From trebuie semnat întotdeauna (RFC 6376 §5.4). Semnați și anteturile care dau mesajului înțelesul lui, precum Subject, Date, To, Message-ID și Reply-To. Dacă listați un nume de antet o dată mai mult decât apare în mesaj, nimeni nu mai poate adăuga o a doua copie a acelui antet fără să strice semnătura.

Evitați eticheta l=

Eticheta l= semnează doar prima parte a corpului. RFC 6376 §8.2 avertizează că ea permite cuiva să adauge conținut la sfârșitul unui mesaj semnat, iar semnătura se validează în continuare, deci lăsați-o complet deoparte.

DKIM și alinierea DMARC în practică

Un mesaj poate purta mai multe semnături DKIM, iar lucrul acesta este obișnuit. Un serviciu de newsletter poate adăuga propria semnătură cu d=esp.example.net lângă a dumneavoastră, cu d=example.com. DMARC trece atunci când oricare dintre semnăturile validate este aliniată cu domeniul From, deci o semnătură în plus de la furnizor nu strică nimic.

Alinierea relaxată, cea implicită în DMARC, acceptă domenii de semnare care au același domeniu organizațional. O semnătură cu d=mail.example.com se aliniază cu o adresă From de la example.com, ceea ce vă lasă să dați fiecărui sistem expeditor propriul subdomeniu de semnare. Alinierea strictă (adkim=s) cere o potrivire exactă și rareori merită problemele suplimentare pe care le aduce.

Când un serviciu oferă „DKIM automat” fără să vă ceară înregistrări DNS, de obicei semnează cu propriul lui domeniu. Asta trece de DKIM, dar nu și de alinierea DMARC, adică exact situația pe care planul de trecere DMARC vă spune să o reparați înainte de a trece la aplicare.

Protejarea cheilor private

Oricine are cheia dumneavoastră privată DKIM poate semna e-mail care trece de DKIM și de DMARC în numele domeniului dumneavoastră. Tratați-o ca pe o cheie privată TLS: păstrați-o cu permisiuni restrânse, țineți-o în afara depozitelor de cod și a copiilor de siguranță pe care le pot citi mulți oameni și preferați un serviciu de administrare a cheilor sau magazia de chei a platformei de semnare. Furnizorii găzduiți care folosesc delegare prin CNAME nu vă dau niciodată cheia privată, ceea ce elimină complet acest risc.

Folosiți câte o cheie separată pentru fiecare sistem expeditor, în loc de o singură cheie comună. Când relația cu un furnizor se încheie sau un server este compromis, revocați un singur selector, iar restul e-mailului dumneavoastră trece mai departe. Cheile separate arată limpede, în rapoarte și în anteturi, care sistem a semnat un anumit mesaj.

• Generați cheile pe sistemul care semnează sau într-un serviciu de administrare a cheilor, nu pe un laptop.
• Notați în scris ce selector aparține cărui sistem și cine răspunde de el.
• Revocați cheile sistemelor pe care le scoateți din uz, în loc să le lăsați publicate.
• Faceți rotația imediat atunci când o cheie privată ar fi putut fi expusă.

Atacul DKIM replay și cum îl limitați

O semnătură DKIM dovedește că mesajul a fost semnat de domeniul dumneavoastră, nu cui i-a fost trimis. Într-un atac de tip replay, cineva obține un mesaj semnat legitim, de exemplu înscriindu-se la un serviciu care lasă utilizatorii să trimită e-mail, și îl retrimite apoi către foarte mulți destinatari. Semnătura se validează în continuare, așa că spamul moștenește reputația domeniului dumneavoastră.

Apărarea principală este să nu semnați mesaje al căror conținut este controlat de un utilizator în care nu aveți încredere, fără limite de rată și fără monitorizarea abuzurilor. Semnarea mai multor anteturi ajută, pentru că atacatorul nu poate schimba subiectul și nu poate adăuga anteturi fără să strice semnătura. Eticheta opțională x= stabilește un termen de expirare al semnăturii și scurtează fereastra în care un mesaj copiat se mai validează, cu prețul eșecului mesajelor întârziate în mod legitim.

Depanarea rezultatului dkim=fail

Trimiteți un mesaj de test către o căsuță pe care o controlați, deschideți mesajul original și lipiți anteturile în Analizorul de anteturi de e-mail. Instrumentul arată dintr-o privire rezultatele SPF, DKIM și DMARC, iar exportul lui JSON conține fiecare antet analizat, inclusiv linia Authentication-Results cu header.d și header.s.

Întrebări frecvente

Surse

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 8463: A New Cryptographic Signature Method for DKIM (Ed25519)
• Microsoft Learn: Configurarea DKIM pentru semnarea e-mailului de pe domeniul propriu
• Google Workspace: Configurarea DKIM