DomainKeys Identificerede Mail

DomainKeys Identificerede Mail er en e-validering system designet til at detektere email spoofing ved at give en mekanisme til at tillade modtage mail vekslere at kontrollere, at indgående post fra et domæne får tilladelse af denne domæne administratorer. En digital signatur er inkluderet med budskabet kan valideres af modtageren hjælp underskriverens offentlige nøgle offentliggjort i DNS.

DKIM er resultatet af fusionerende DomainKeys og identificeret Internet Mail. Denne fusionerede specifikation har været grundlaget for en serie af IETF standarder-track specifikationer og support dokumenter, som i sidste ende resulterede i STD 76.

Fremtrædende mail-udbydere til gennemførelse af DKIM omfatter Yahoo, Gmail, AOL og Fastmail. Enhver e-mail fra disse organisationer bør bære en DKIM signatur.

Oversigt

Begge moduler, underskrive og kontrollere, er normalt en del af en mail transfer agent. Underskrivelsen organisation kan være en direkte handling af meddelelsen, såsom forfatteren, har oprindelse sende websted eller en mellemmand langs transit vej, eller en indirekte handling såsom en uafhængig tjeneste, der yder bistand til en direkte handling. I de fleste tilfælde underskrivelsen modulet handler på vegne af forfatterens organisation eller den oprindelse udbyderen ved at indsætte en DKIM-Underskrift: header felt. Den verificere modulet typisk handler på vegne af modtagerens organisation.

Behovet for denne type af validerede identifikation opstod, fordi spam ofte har smedet adresser og indhold. For eksempel kan en spam-besked hævder i sin "Fra:" header felt at være fra afsender, selv om det ikke er faktisk fra denne adresse, og spammer mål er at overbevise modtageren til at acceptere og læse e-mail. Fordi e-mailen er ikke fra example.com domæne, klager der ikke er nyttigt. Det bliver også svært for modtagerne at fastslå, om at have tillid til eller mistillid nogen bestemt domæne og systemadministratorer kan have til at behandle klager over spam, der synes at stamme fra deres systemer, men gjorde det ikke.

DKIM er uafhængig af Simple Mail Transfer Protocol routing aspekter i, at det fungerer på RFC 5322 budskab - den transporterede mail header og krop - ikke SMTP kuvert defineret i RFC 5321. Derfor DKIM signatur overlever grundlæggende genudlægning på tværs af flere MTA'er.

DKIM tillader underskriveren til at skelne sin legitime mail stream. Det betyder ikke direkte forhindre eller afsløre misbrug. Denne evne til at skelne lovlige mail fra potentielt smedet mail har fordele for modtagere af e-mail samt afsendere, og "DKIM bevidsthed" er programmeret ind i nogle e-mail-software.

Hvordan det virker

Den "DKIM-Signatur" header felt består af en liste over "tag = værdi" dele. Tags er korte, normalt kun en eller to bogstaver. De mest relevante af dem der er b for den faktiske digitale signatur af indholdet i mailen, bh for kroppen hash, d for underskrivelsen domæne og s for vælgeren. Standardindstillingerne parametre for autencitetsmekanisme skal bruge SHA-256 som den kryptografiske hash og RSA som nøglen kryptering ordningen offentlige, og indkode den krypterede hash hjælp Base64.

Den modtagende SMTP-serveren bruger domænenavnet og vælgeren til at udføre en DNS-opslag. For eksempel i betragtning af signaturen

En verifikator forespørger TXT ressource rekord type. Der er ingen CA'er heller spærrelister involveret i DKIM key management, og vælgeren er en enkel metode til at gøre det muligt for underskrivere til at tilføje og fjerne nøgler, når de ønsker - langtidsholdbare signaturer til arkiveringsformål er uden DKIM anvendelsesområde. Nogle flere tags er synlige i eksemplet: v er den version, a er signering algoritme, c er navnevedtagelse algoritme til header og krop, q er standardforespørgselsgrænsen metode, L er længden af ​​den kanoniske del af kroppen, der har blevet underskrevet, t er signaturen tidsstempel, x er det udløber tid, og h er listen over underskrevne header felter, gentagne for felter, der opstår flere gange. Bemærk, at DKIM-Signatur felt selve header altid indgår implicit i h.

De returnerede fra forespørgslen data er også en liste over tag-værdipar. Det omfatter domænets offentlige nøgle, sammen med andre centrale brug tokens og flag. Modtageren kan bruge dette til derefter dekryptere hash værdi i overskriften og samtidig genberegne hash værdi for mail, der blev modtaget. Hvis de to værdier matcher denne kryptografisk beviser, at posten blev underskrevet af den angivne domæne og er ikke blevet manipuleret med i transit.

Svigt signatur verifikation tvinger ikke afvisning af den meddelelse. I stedet bør de nøjagtige grunde til, at ægtheden af ​​meddelelsen kunne ikke bevist stilles til rådighed for downstream og upstream processer. Metoder herfor kan omfatte at tilbagesende en FBL besked eller tilføje en Authentication-Resultater overskriftsfelt til meddelelsen som beskrevet i RFC 7001.

Udvikling

Den originale DomainKeys designet af Mark Delany af Yahoo! og styrkes gennem kommentarer fra mange andre siden 2004. Det er angivet i Historic RFC 4870, afløst af standarder Track RFC 4871, DomainKeys Identificerede mail-signaturer; begge offentliggjort i maj 2007. En række præciseringer og konceptualiseringer blev indsamlet derefter, og specificeret i RFC 5672, August 2009, i form af korrektioner til den eksisterende specifikation. I september 2011 RFC 6376 fusionerede og opdateret de to sidstnævnte dokumenter, mens indholdet af DKIM-protokollen bevare. Offentlig nøgle kompatibilitet med det ældre DomainKeys er også muligt.

DKIM blev oprindeligt produceret af en uformel industri konsortium, og blev derefter sendt til forbedring og standardisering af IETF DKIM arbejdsgruppe under ledelse af Barry Leiba og Stephen Farrell, med Eric Allman af sendmail, Jon Callas af PGP Corporation, Mark Delany og Miles Libbey af Yahoo !, og Jim Fenton og Michael Thomas fra Cisco Systems tilskrives som primære forfattere.

Kildekode udvikling af én fælles bibliotek ledes af OpenDKIM Project, efter de seneste protokol tilføjelser, og licens under New BSD-licens.

Patent behæftelse

DomainKeys er dækket af US Patent 6.986.049 overdraget til Yahoo! Inc. Med henblik på den DKIM IETF arbejdsgruppen, Yahoo! udgivet den nu forældede DK bibliotek under en dobbelt licens ordningen: DomainKeys Patent Licensaftale v1.2, en usigneret version af som stadig kan findes, og GNU General Public License v2.0.

Fordele

Den primære fordel ved dette system til e-mail-modtagere er det tillader underskrivelsen domæne til pålideligt identificere en strøm af legitim e-mail, hvorved domæne-baserede sortlister og hvidlister til at være mere effektive. Det er også sandsynligt, at lave nogle former for phishing-angreb lettere at opdage.

Der er nogle incitamenter til postafsendere at underskrive udgående e-mail:

  • Det giver en stor reduktion i misbrug skrivebordsarbejde for DKIM-aktiverede domæner, hvis e-mail-modtagere bruger DKIM-systemet til at identificere falske e-mails hævder at være fra dette domæne.
  • Domænet ejer kan derefter fokusere sine misbrug hold energier på egne brugere, der rent faktisk gør uhensigtsmæssig brug af dette domæne.

Brug med spamfiltrering

DKIM er en metode til mærkning en meddelelse, og det ikke selv filtrere eller identificere spam. Udbredt brug af DKIM, kan dog forhindre spammere i smedning kilden adressen på deres budskaber, en teknik, de ofte beskæftiger i dag. Hvis spammere er tvunget til at vise en korrekt kilde domæne, kan andre filtreringsteknikker arbejde mere effektivt. Især kan kilden domænet indgå i et ry for at bedre at kunne identificere spam. Omvendt kan DKIM gøre det lettere at identificere mail, der vides ikke at være spam, og behøver ikke at blive filtreret. Hvis en modtagende system har en whitelist af kendte gode sende domæner, enten lokalt vedligeholdes eller fra tredjepart certificeringsorganer, kan det springe filtrering på underskrevne mail fra disse domæner, og måske filtrere den resterende post mere aggressivt.

Anti-phishing

DKIM kan være nyttigt som et Antiphishingteknologien. Afsendere i stærkt phished domæner kan tilmelde deres post for at vise, at det er ægte. Modtagere kan tage fraværet af en gyldig signatur på mail fra disse domæner at være en indikation af, at mailen sandsynligvis forfalsket. Den bedste måde at afgøre det sæt af domæner, der fortjener denne grad af kontrol er fortsat et åbent spørgsmål; DKIM har en valgfri funktion, der hedder ADSP der lader forfattere, som tilmelder alle deres mails selv identificere, men effektiviteten af ​​denne tilgang er fortsat tvivlsom:

Arbejde med eBay og PayPal, har Google udnyttes effektivt DKIM i GMail på en sådan måde, at en e-mail, der hævder at komme fra ebay.com eller PayPal.com vil ikke blive accepteret på alle, hvis de ikke kan verificeres held med DKIM. Sådanne meddelelser vil ikke engang vises i spam-mappen. Stærkt phished domæner, der fortjener en sådan behandling er få i antal, langt mindre end dem, der udgiver strenge politikker.

Kompatibilitet

Fordi det er implementeret ved hjælp af DNS-poster og en ekstra RFC 5322 header felt, DKIM er kompatibel med eksisterende e-mail-infrastruktur. Især er det er transparent for eksisterende e-mail-systemer, der mangler DKIM support.

Dette design tilgang også er kompatibel med andre, relaterede tjenester, såsom S / MIME og OpenPGP standarder indhold-beskyttelse. DKIM er kompatibel med DNSSEC standard og med SPF.

Protokol over hovedet

DKIM kræver kryptografiske kontrolsummer skal genereres for hver meddelelse sendt via en mail-server, hvilket resulterer i beregningsmæssige hovedhøjde ellers ikke påkrævet til e-mail-levering. Denne ekstra beregningsmæssige hovedhøjde er kendetegnende for digitale stempler, hvilket gør at sende bulk-spam dyrere. Denne facet af DKIM kan ligne Hashcash, bortset fra, at kontrollen modtagersiden er ikke en ubetydelig mængde arbejde.

Svagheder

DKIM signatur omfatter ikke det budskab konvolut, som holder retur-sti og besked modtagere. Da DKIM ikke forsøger at beskytte mod mis-adressering, betyder det ikke påvirker dets anvendelighed. En bekymring for enhver kryptografisk løsning ville være besked replay misbrug, der omgår teknikker, der i øjeblikket begrænser omfanget af misbrug fra større domæner. Replay kan udledes ved hjælp af pr-besked offentlige nøgler, spore DNS-forespørgsler til disse nøgler og frafiltrere det store antal henvendelser på grund af e-mail bliver sendt til store postlister eller ondsindede forespørgsler af dårlige skuespillere. For en sammenligning af forskellige metoder også løse dette problem se e-mail-godkendelse.

Vilkårlig viderestilling

Som nævnt ovenfor, autentificering er ikke det samme som forebyggelse misbrug: DKIM forhindrer ikke en spammer fra komponere en annonce på en velrenommeret domæne for at opnå en underskrevet kopi af meddelelsen. Ved hjælp af en l-tag i en signatur gør doctoring sådanne meddelelser endnu nemmere. Den underskrevne eksemplar kan derefter sendes til millioner af modtagere, f.eks gennem et botnet, uden styring. Den e-mail-udbyder, der underskrev beskeden kan blokere de ulovlige brugeren, men kan ikke stoppe udbredelsen af ​​allerede indgåede meddelelser. Gyldigheden af ​​underskrifter i sådanne beskeder kan være begrænset af altid herunder en udløbstid tag i signaturer, eller ved at tilbagekalde en offentlig nøgle jævne mellemrum eller efter en meddelelse om en hændelse. Effektiviteten af ​​scenariet kan begrænses ved at filtrere udgående e-mail, der sikrer, at meddelelser potentielt nyttige til spammere ikke bliver underskrevet, eller bare ikke sendt.

Indhold modifikation

DKIM øjeblikket har to kanonisering algoritmer, enkle og afslappet, hvoraf ingen er MIME-bevidste. Mail-servere kan lovligt konvertere til et andet tegnsæt, og ofte dokumentere dette med X-MIME-Autoconverted header felter. Desuden servere under visse omstændigheder nødt til at omskrive MIME struktur og derved ændre præamblen, epilogen, og enheds grænser, som alle bryder DKIM signatur. Kun almindelig SMS-beskeder skrevet i US-ASCII, forudsat at MIME header felter ikke er logget, nyde robusthed, at end-to-end integritet kræver.

Den OpenDKIM Project organiserede en indsamling af data, der involverer 21 mailservere og millioner af beskeder. Kun 92,3% af observerede underskrifter lykkedes verificeret, en succesrate, der falder lidt, når kun mailing liste trafik overvejes.

Anmærkninger ved postlister

Disse problemer forværres, når filtrering eller genudlægning software tilføjer faktiske ændringer i en meddelelse. Selv legitim, sidefoden tilføjelse drives af de fleste postlister og mange centrale antivirus løsninger, formelt, er præcis den form for meddelelse, manipulation, at DKIM er designet til at beskytte sig mod. Løsningen er at hvidliste kendte speditører, fx af SPF. Alternativt kan en speditør verificere signaturen, ændre e-mailen, og re-underskrive meddelelsen med en Afsender: header. Dog skal det bemærkes, at denne løsning har sin risiko med fremsendt 3. parts underskrevet beskeder modtaget på SMTP-modtagere, der understøtter RFC 5617 ADSP protokol. Således i praksis, den modtagende server stadig at whiteliste kendte besked vandløb, dvs. med DKIM.

Nogle foreslår, at disse begrænsninger kunne løses ved at kombinere DKIM med SPF, fordi SPF er immune over for ændringer af e-mail-data, og postlister bruger typisk deres egen SMTP fejl-adresse, også kendt som Return-Path. Kort sagt, SPF fungerer uden problemer, hvor DKIM kan løbe ind i vanskeligheder, og omvendt.

2012 forbrug sårbarhed

I oktober 2012, Wired rapporterede, at matematikeren Zach Harris opdages og demonstrerede en e-mail kilde spoofing sårbarhed med korte DKIM nøgler til corporate domæne, samt flere andre højt profilerede domæner. Han erklærede, at godkendelse med 384-bit nøgler kan indregnes i så lidt som 24 timer "på min laptop", og 512-bit nøgler, i ca. 72 timer med cloud computing ressourcer. Harris fandt, at mange organisationer underskriver email med sådanne korte nøgler; Han indregnet dem alle og meddelt de organisationer sårbarheden. Han anfører, at 768-bit nøgler kunne indregnes med adgang til meget store mængder computerkraft, så han foreslår, at DKIM underskrivelsen skal bruge nøglelængder større end 1.024. Wired erklærede, at Harris rapporteret, og Google har bekræftet, at de begyndte at bruge nye længere nøgler snart efter sin offentliggørelse.

  0   0

Kommentarer - 0

Ingen kommentar

Tilføj en kommentar

smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile
Tegn tilbage: 3000
captcha