Finn modifikasjonen før du legger skylden på gatewayen
En sikkerhetsgateway kan legitimt inspisere eller transformere e-post mens den kompliserer nedstrøms DKIM bekreftelse. Omskriving av URL, utskifting av vedlegg og kroppsadvarsler er mulige eksempler, men gatewayens tilstedeværelse alene beviser ingenting om en mislykket signatur. Fastslå hvilken representasjon som kom inn i gatewayen, som forlot den og hvor autentisering ble evaluert.
Ingen gateway-konto eller meldingsstrøm ble åpnet for denne artikkelen. Original bevisport: Originale og modifiserte råmeldinger, underskriverplassering og en før-og-etter-verifiseringstest. Disse gjenstandene forblir uavhentede. Den bearbeidede saken er fiktiv. Enhver driftsendring må bevare de tiltenkte sikkerhetskontrollene og følge eiers godkjente prosess.
Inventar den nøyaktige behandlingssekvensen
Tegn en sekvens fra meldingsgodkjenning til autentisering, trusselinspeksjon, innholdsendring, signering og videre levering. En tjeneste kan kombinere disse funksjonene, og flere gatewayer kan vises på én rute. Registrer versjonen og aktivert virkemåte bare når det støttes av den faktiske konfigurasjonen. Ikke anta at et produkt alltid verifiserer før det omskrives, eller at dets utgående kobling alltid signerer.
RFC 7960 beskriver grensefiltre som fjerner skadelig innhold, merker mistenkt spam eller endrer nettadresser. Det forklarer også hvorfor evaluering av autentisering etter modifikasjoner av et filter kan gi forskjellige resultater. Dette er arkitektoniske muligheter, ikke en dom om en bestemt leietaker. Et meldingsspor og bevarte kopier er nødvendig for å koble den dokumenterte mekanismen til en hendelse. RFC 7960 avsnitt 3.2.5
Finn ut hva den mislykkede signaturen dekket
For hver DKIM-Signature, behold signeringsdomenet d=, velger s=, kanonisering c=, header list h= and any l= body-length value. The kroppshasj beregnes over den valgte kanoniserte hovedinngangen; signaturen dekker også spesifiserte header-forekomster. "Gatewayen endret en overskrift" er ufullstendig uten å vite om den forekomsten ble valgt og om kanonisering bevarte forskjellen. RFC 6376 avsnitt 3.4–3.5 og 5.4
Avslappet kanonisering tolererer spesielle endringer i mellomrom og topptekstformatering. Den behandler ikke vilkårlige HTML-redigeringer, URL-erstatninger eller vedleggsendringer som tilsvarende innhold. Omvendt trenger ikke et lagt felt utenfor den valgte dekningen ugyldiggjøre en eksisterende signatur. Overskriftduplisering og oversignering kan komplisere denne vurderingen, så sammenlign de valgte forekomstene i stedet for bare en liste med unike feltnavn. RFC 6376 avsnitt 3.4 og 5.4
Sammenlign rå meldinger uten å endre bevisene
Bruk uendrede råmeldingsfiler fra godkjente fangstpunkter. Gjengitte skjermbilder kan skjule MIME grenser, kodeendringer og brettede overskrifter. Å lagre en melding på nytt gjennom et redigeringsprogram kan i seg selv endre linjeavslutninger eller serialisering, så behold originalene og utfør analyser på kopier. Registrer fangsttid, ruteposisjon og filhasher for å koble hver prøve til trinnet som kreves.
En senere mislykket signatur fastslår ikke at signaturen var gyldig før gatewayen. RFC 6376 advarer om at en verifikator generelt ikke kan utlede tidligere gyldighet fra en ugyldig signatur. Den foreslåtte testen inkluderer derfor verifikasjon av den bevarte inngangen så vel som utgangen, med den relevante nøkkel- og verifikatorkonteksten beholdt. Ellers kan en eksisterende signeringsfeil feiltilskrives gatewayen. RFC 6376 avsnitt 4.2
Arbeid gjennom en fiktiv URL-erstatning
Anta at en fiktiv forfatter-domenesignatur bekrefter en rå inndatamelding og dekker hele kroppen. En gateway erstatter deretter en URL i en HTML MIME del med en URL for trusselbeskyttelse. Den korresponderende utgangen inneholder forskjellige kanoniserte body-bytes, og et verifiseringsforsøk rapporterer body-hash-mismatch. Disse forutsetningene danner et illustrerende testresultat; ingen slik test kjørte her.
Denne sammenligningen støtter den snevre konklusjonen om at den observerte erstatningen påvirket denne signaturens dekkede kropp. Det betyr ikke at hver gateway-handling bryter hver signatur eller at beskyttelsen bør slås av. En ekstra signatur fra gateway.example kan autentisere det domenets håndtering av den endrede meldingen, men den rekonstruerer ikke den opprinnelige forfattersignaturen eller justeres automatisk med et ikke-relatert forfatterdomene. RFC 6376 avsnitt 3.4 og 5.1 RFC 9989 avsnitt 5.3
Hold inngående resultater og nedstrømsverifisering distinkte
En organisasjon kan stole på autentisering utført ved pålitelig inntreden før interne sikkerhetstransformasjoner. Bevar evaluatoridentiteten og tillitsgrensen bak det resultatet. En nedstrømsmottaker som evaluerer modifiserte bytes kan på riktig måte oppnå et annet DKIM resultat. Kopierer en Authentication-Results felt inn i en melding gjør ikke i seg selv det feltet pålitelig utenfor grensen som produserte det. RFC 8601 seksjoner 5 og 7
ARC kan gjennomføre tidligere vurderinger gjennom deltakende behandlere, men kjedevalidering og tillit til disse behandlerne forblir forskjellige spørsmål. RFC 8617 gjør ikke ARC til en mekanisme for å gjenopprette en gammel DKIM signatur. Den publiserte kategorien er eksperimentell; det reviderte forslaget om å flytte ARC til Historic er fortsatt et aktivt utkast. Ikke lov at aktivering av ARC får alle nedstrømsmottakere til å akseptere gateway-modifisert e-post. RFC 8617 avsnitt 5.2 og 9.3 IETF -forslagsstatus
Plasser legitim signering etter de tiltenkte endringene
For utgående e-post skrevet under et domene organisasjonen kontrollerer, kan et støttet design plassere den autoriserte justerte signeren etter endelige lovlige innholdsendringer. Bekreft at senere trinn ikke endrer dekket innhold igjen. En gateway kan ikke legitimt signere som en ekstern forfatters domene bare fordi den videresender forfatterens budskap; den relevante domeneautorisasjonen og nøkkeldepotet må eksistere. RFC 6376 avsnitt 5.1
Gjennomgangspakken skal angi hvilken kontroll som forblir aktiv, hvilken behandlingsrekkefølge som foreslås, og hvordan før- og etterverifisering vil bli gjentatt. Ikke bruk redusert kroppsdekning eller teppe-autentiseringsomkjøringer bare for å produsere en grønn indikator. En vellykket autorisert test vil kun støtte de samplede rutene og meldingsskjemaene. Originale råpar, faktisk underskriverplassering og et kontrollert verifikasjonsresultat mangler fortsatt i dette utkastet.