CUSTOMIZE Wanneer we spreken over "Email Authentication", hebben we het over een techniek die de ontvanger van een bericht enige zekerheid biedt dat het bericht daadwerkelijk afkomstig is van de vermeende bron van het bericht.
Wanneer we spreken van “Email Authentication”, verwijzen we naar een techniek die aan de ontvanger van een bericht enige mate van zekerheid biedt dat het bericht daadwerkelijk afkomstig is van de beweerde bron van het bericht. Het idee achter dergelijke technieken is om een bepaald niveau van verdediging te bereiken tegen frauduleuze e-mail, zoals phishing en spoofing, e-mails die het vertrouwen van een ontvanger in het ontvangen van e-mail kunnen ondermijnen. Dat gezegd hebbende, het verzenden van geauthenticeerde e-mail beweert niet dat de e-mail goed of gewenst is; het betekent alleen dat de e-mail zodanig is dat een reputatie voor de geauthenticeerde partij op betrouwbare wijze kan worden vastgesteld en gebruikt in e-mailacceptatie- en plaatsingsbeslissingen.
Er zijn tegenwoordig twee vormen van e-mailauthenticatie in gebruik:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
In de post van vandaag bespreek ik wat DKIM is en hoe het werkt.
DKIM Overzicht
In tegenstelling tot zijn authenticatietegenhanger SPF, dat een manier biedt voor een domein om een host te autoriseren om namens hem e-mail te verzenden, biedt DKIM een manier voor een entiteit (domein, organisatie, persoon, enz.) om verantwoordelijkheid te nemen voor een bericht, onafhankelijk van de entiteit die het bericht daadwerkelijk heeft verzonden. Hoewel in veel gevallen de verantwoordelijke entiteit en de verzendende entiteit hetzelfde zullen zijn, of ten minste nauw verwant, is er met DKIM geen vereiste dat dit het geval is.
Mijn doelen voor jou met dit bericht zijn dat je de volgende concepten over DKIM leert en begrijpt:
DKIM is een "content-gebaseerde" authenticatie, in tegenstelling tot de "pad-gebaseerde" SPF.
De verantwoordelijke entiteit bevestigt zijn verantwoordelijkheid door het bericht te "ondertekenen" met een paar cryptografische hashes die in een berichtheader worden ingevoegd.
DKIM-validatie wordt uitgevoerd door het ontvangende domein dat probeert dezelfde twee hashes te genereren.
DKIM-validatie kan in veel gevallen niet worden voltooid totdat het volledige bericht door de verzendende server is overgedragen.
Validatiefouten kunnen moeilijk te troubleshooten zijn.
“Content-Based” Authenticatie
DKIM Ondertekening en Validatie
Organisaties die mail willen ondertekenen met DKIM, zullen eerst twee cryptografische sleutels genereren. Eén van de sleutels wordt privé gehouden en is beschikbaar voor de verzendende server voor het ondertekenen van mail, en de andere moet openbaar worden gemaakt in DNS voor gebruik door ontvangende domeinen bij pogingen om de handtekening te valideren. De methoden voor het genereren en installeren van deze sleutels zijn platformafhankelijk en vallen buiten de scope van dit bericht, hoewel ik later het publiceren van de openbare DKIM-sleutel in DNS zal beschrijven.
De DKIM-Signature Header
Om ons begrip van DKIM te beginnen, laten we eerst kijken naar een DKIM-Signatuur-header:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
De DKIM-Signatuur-header is een reeks sleutel-waardeparen, waarvan sommige meer interesse hebben voor de lezer dan andere, maar ik zal ze hier allemaal beschrijven.
Eerst kijken we naar degenen die voornamelijk van voorbijgaande interesse zijn voor de lezer:
v=1; – Specificeert de DKIM-versie (1 is de enige geldige waarde)
a=rsa-sha256; – Het algoritme dat wordt gebruikt om de cryptografische hashes te maken
c=relaxed/relaxed; – Er zijn twee sets regels met betrekking tot het verwijderen van spaties in de headers en body die kunnen worden toegepast bij het maken van de hashes in een DKIM-signatuur; deze regels worden “kanonieke regels” genoemd (vandaar de sleutel "c") en de regelsets zijn ofwel “relaxed” of “strict”.
t=1454417737; – De tijdstempel van wanneer de signatuur is gemaakt.
Deze drie headerdelen bevatten de feitelijke handtekeninggegevens:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dit is de hash van de body van het bericht.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dit is een lijst van de headers die zijn gebruikt om de signatuurgegevens die hieronder worden weergegeven te maken.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dit zijn de eigenlijke DKIM-signatuurgegevens
Deze drie delen zijn van het meeste belang voor de ontvangende server die de handtekening zal validieren:
d=welcome.foo.com; – Dit identificeert het domein dat het bericht heeft ondertekend
s=notices; – De selector; domeinen kunnen meerdere selectors hebben die ze gebruiken bij het ondertekenen van berichten.
i=@welcome.foo.com; – Dit is de identiteit namens wie het bericht is ondertekend. Syntactisch zal dit eruitzien als een e-mailadres, en kan zelfs een e-mailadres zijn; het lokale deel van het e-mailadres kan leeg zijn, zoals in dit voorbeeld, en het domeingedeelte moet hetzelfde zijn als, of een subdomein van, het domein in het d= deel van de signatuur.
De reden dat deze onderdelen van belang zijn voor de ontvangende server is dat ze de nodige informatie verschaffen om de ontvanger te helpen de handtekeningen te valideren.
DKIM Validatie
Naast de vereiste dat het i= domein hetzelfde moet zijn als of een subdomein van het d= domein, worden de d= en s= bits door de validator gebruikt om de publieke DKIM-sleutel van de ondertekenaar in DNS op te zoeken. De sleutel is een TXT-record in DNS en wordt altijd gevonden op de locatie selector._domainkey.domein. Dus, in ons voorbeeld hier, met s=notices en d=welcome.foo.com, zou de publieke DKIM-sleutel gevonden worden in DNS op notices._domainkey.welcome.foo.com, en het zou er ongeveer als volgt uitzien:
notices._domainkey.welcome.foo.com. beschrijvende tekst "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
De validator gebruikt die sleutel (de p= bits) om zijn eigen set hashes van het bericht te produceren; als die hashes overeenkomen, dan is het bericht niet gewijzigd tijdens transport, en kan het bericht bijdragen aan en wellicht profiteren van welke reputatie ook in plaats is voor de ondertekenaar van het bericht.
Validatie Fout en Problemen oplossen
Ik heb hierboven vermeld dat DKIM-fouten moeilijk kunnen zijn om op te lossen, en ik zal hier uitleggen waarom dat zo is.
Sommige DKIM-validatiefouten hebben voor de hand liggende oorzaken, zoals dat het bericht niet is ondertekend, of dat de publieke sleutel van het ondertekeningsdomein niet is gevonden in DNS of niet syntactisch correct is, of misschien is het bericht duidelijk gewijzigd tijdens het transport. Wanneer die soorten fouten optreden, is het gemakkelijk om het probleem te achterhalen en een oplossing aan te bevelen. De moeilijke gevallen, echter, en degenen die leiden tot de meest frustrerende ondersteuningservaring, zijn de gevallen waarin het bericht is ondertekend, de publieke sleutel bestaat in DNS, en het bericht niet duidelijk is gewijzigd, maar de validator rapporteert dat de handtekening niet gevalideerd kon worden.
De reden dat deze moeilijk op te lossen zijn, is omdat er geen echte manier is voor beide partijen om de omstandigheden te reproduceren waaronder het bericht werd ondertekend en gevalideerd. Het bericht heeft in de DKIM-Signature-header de hashes die door de ondertekenaar zijn gegenereerd op het moment van ondertekening, maar de validator heeft waarschijnlijk geen toegang tot de infrastructuur van de ondertekenaar en kan dus de handtekening niet onder dezelfde omstandigheden proberen te reproduceren. Evenzo heeft de ondertekenaar waarschijnlijk geen toegang tot de infrastructuur van de validator en dus geen manier om het bericht op dezelfde manier te valideren zoals de validator dat deed.
Dergelijke fouten zoals ik hier beschrijf zijn zeldzame voorvallen, en DKIM-validatiefouten hebben op zichzelf meestal geen invloed op de plaatsing van levering. Terwijl DKIM berichtauthenticatie afhandelt, het implementeren van uitgebreide e-mailvalidatietechnieken zorgt ervoor dat je naar legitieme adressen stuurt die je berichten daadwerkelijk kunnen ontvangen en authenticeren. Het is mijn ervaring dat dergelijke fouten meer supporttickets veroorzaken dan enig ander soort DKIM-probleem.
