Hvad er SMTP TLS-rapportering?

TLS Reporting er en omvendt feedback-mekanisme, der hjælper domæneejere med at finde problemer med e-maillevering med stor nøjagtighed. Den fungerer sammen med MTA-STS protokollen og giver sporingsdata om bouncede e-mails, der ikke blev leveret på grund af et mislykket TLS-håndtryk.

Hvad betyder TLS-rapportering?

TLS Reporting (TLS-RPT) er en standard til rapportering af problemer med e-maillevering, der opstår, når en e-mail ikke er krypteret med TLS. Den understøtter MTA-STS-protokollen, som bruges til at garantere, at alle e-mails, der sendes til dit domæne, bliver TLS-krypteret.

• TLS-kryptering sikrer, at alle e-mails, der sendes til dig, bliver leveret sikkert. Men en angriber kan forsøge en SMTP-downgrade, en type angreb, hvor e-mailen sendes til dig uden at være krypteret, så de kan læse eller manipulere med indholdet. MTA-STS bekæmper dette ved at gøre det nødvendigt for alle e-mails at blive krypteret, før de sendes til dig. Hvis en angriber forsøger at udføre en SMTP-nedgradering, vil e-mailen slet ikke blive sendt.
• TLS-RPT gør det muligt for dig, domæneejeren, at modtage rapporter om hver e-mail, der ikke bliver krypteret og ikke sendes til dig. Du kan derefter identificere kilden til problemet og løse dine leveringsproblemer.

Hvordan fungerer TLS-rapportering?

TLS-rapportering (TLS-RPT) bruges til at understøtte MTA-STS-protokollen, som sikrer, at e-mails krypteres, før de leveres. Normalt forhandler din mailserver eller MTA (Mail Transfer Agent) med den modtagende server for at se, om den understøtter kommandoen STARTTLS. Hvis det gør det, bliver e-mailen krypteret med TLS og leveres til den modtagende MTA.

En hacker kan forsøge et SMTP-nedgraderingsangreb på dette tidspunkt, hvilket indebærer, at forhandlingen mellem afsendelses- og modtagelses-MTA'erne blokeres. Afsenderserveren mener, at modtageren ikke understøtter KOMMANDOEN STARTTLS og sender e-mailen uden TLS-kryptering, så hackeren kan se eller manipulere med mailens indhold.

Når du implementerer MTA-STS i dit domæne, gør det det obligatorisk for din afsenderserver at kryptere beskeder, før du sender dem. Hvis en angriber forsøger et SMTP-downgrade-angreb, vil e-mailen simpelthen ikke blive sendt. Dette sikrer TLS-kryptering på alle dine e-mails uden fejl.

TLS-rapportering (TLS-RPT) er en protokol, der giver dig som domæneejer besked, når e-mails, der sendes via dit domæne, har problemer med leveringen. Hvis en e-mail ikke kan sendes på grund af en SMTP-nedgradering eller et andet problem, vil du modtage en rapport i JSON-filformat, der indeholder detaljerne om den e-mail, der mislykkedes. Denne rapport indeholder ikke indholdet af e-mailen.

Hvorfor har du brug for SMTP TLS-rapportering?

Det er vigtigt for domæneejere at holde sig informeret om problemer med e-maillevering på grund af fejl i TLS-kryptering for e-mails sendt fra et MTA-STS-aktiveret domæne. TLS-rapportering gør det muligt ved at give disse oplysninger. 

At modtage feedback-rapporter

Hvis en besked ikke bliver sendt, hjælper TLS-rapportering dig med at få besked om det.

For at opnå total synlighed af e-mailkanaler

Få detaljeret indsigt i dit e-mailflow gennem TLS-rapportering

For at eliminere leveringsproblemer

TLS-rapportering hjælper dig med at identificere kilden til problemet og løse det uden forsinkelse.

Trin til aktivering af TLS-rapportering 

Du kan aktivere TLS-rapportering for dit domæne ved at oprette en TXT-post for TLS-RPT og offentliggøre den på din DNS. Denne record skal udgives på subdomænet _smtp._tls.ditdomæne.com

Eksempel på TLS-RPT-post

v=TLSRPTv1; rua=mailto:[email protected];

Lad os se nærmere på komponenterne i den medfølgende TLS-rapporteringspost:

v=TLSRPTv1:

Dette tag angiver den version af TLS-RPT-protokollen, der bruges. I dette tilfælde, "TLSRPTv1" den første version af TLS-RPT-protokollen.

rua=mailto:[email protected]:

Dette tag angiver rapporterings-URI'en for de aggregerede rapporter (RUA'er). Det specificerer, hvor modtagerens mailserver skal sende aggregerede rapporter om TLS-fejl. rua står for "Reporting URI for Aggregated Reports".

Værdien "mailto:[email protected]" er en URI, der angiver en e-mailadresse ([email protected]) som de aggregerede rapporter skal sendes til via e-mail.

I praksis vil du erstatte "ditdomæne.com" med det faktiske domænenavn, hvor du ønsker at modtage disse rapporter.

Betydningen af hver komponent:

v=TLSRPTv1:

Dette angiver den version af TLS-RPT-protokollen, der bruges. Det er med til at sikre kompatibilitet mellem afsender og modtager af rapporterne.

rua=mailto:[email protected]:

Dette angiver destinationen for aggregerede rapporter om TLS-leveringsproblemer. Ved at angive en rapporterende e-mailadresse kan domæneejere modtage oplysninger om mislykkede eller problematiske TLS-forbindelser. Rapporterne er værdifulde til diagnosticering af potentielle sikkerheds- eller konfigurationsproblemer i forbindelse med e-mailkommunikation.

TLS-rapporteringsformat og eksempel på rapport

En JSON TLS-rapport følger et specifikt format, der er defineret af TLS-RPT-specifikationen (Transport Layer Security Reporting Policy). Dette format bruges til at formidle information om problemer med e-maillevering relateret til TLS-kryptering. Nedenfor er et eksempel på, hvordan en JSON TLS-rapport kan se ud:

Her er en oversigt over de vigtigste felter i denne JSON TLS-rapport:

organisation: Den domæneorganisation, der ejer TLS-RPT-recorden.

e-mail: Den e-mailadresse, hvor aggregerede rapporter sendes til.

begin_date: Startdatoen for rapporteringsperioden.

slut_dato: Slutdatoen for rapporteringsperioden.

Politikker: Et array af politikobjekter, der beskriver de politikker, der er anvendt i rapporteringsperioden.

politik: Indeholder oplysninger om den anvendte politik.

policy_type: Angiver typen af politik (f.eks. "politik" for en TLS-politik).

policy_streng: Angiver den politikstreng, der er knyttet til politikken (f.eks. "reject" for en streng TLS-politik).

resumé: Indeholder sammenfattende oplysninger om de sessioner, der blev forsøgt.

total_successful_session_count: Det samlede antal succesfuldt etablerede TLS-sessioner.

total_failure_session_count: Det samlede antal TLS-sessionsfejl.

fejl_detaljer: Et array af objekter, der giver detaljer om specifikke fejl.

grund: En streng, der angiver årsagen til fejlen (f.eks. "certificate_expired").

tæller: Antallet af sessioner, der mislykkedes af en bestemt årsag.

Årsager til og typer af TLS-krypteringsfejl 

Problemer med certifikater:

1. certifikat_udløbet: Certifikatet fra fjernserveren har overskredet sin udløbsdato, hvilket gør det upålideligt til kryptering.
2. certifikat_ikke_gyldigt_endnu: Certifikatet fra fjernserveren er endnu ikke gyldigt, muligvis på grund af forkert servertid eller for tidlig brug af certifikatet.
3. certifikat_tilbagekaldt: Certifikatet fra fjernserveren er blevet tilbagekaldt af certifikatmyndigheden på grund af sikkerhedsproblemer.
4. untrusted_certificate: Den certifikatkæde, som fjernserveren præsenterer, har afsenderens mailserver eller klient ikke tillid til, hvilket indikerer en potentiel sikkerhedsrisiko.
5. no_valid_signature: Certifikatet, der præsenteres af fjernserveren, er ikke korrekt signeret af en pålidelig certifikatmyndighed, hvilket giver anledning til bekymring om dets ægthed.
6. ikke-understøttet_certifikat: Certifikatet fra fjernserveren bruger krypteringsalgoritmer eller nøglelængder, der ikke understøttes af afsenderens mailserver, hvilket forhindrer en sikker forbindelse.

Uoverensstemmelse mellem værtsnavn og identitet

1. hostname_mismatch: Værtsnavnet, der er angivet i serverens certifikat, stemmer ikke overens med værtsnavnet på den server, som afsenderens mailserver forsøger at oprette forbindelse til, hvilket indikerer et muligt man-in-the-middle-angreb eller konfigurationsproblem.

Cipher Suite og krypteringskonfiguration

1. usikker_ciffer_suite: Den cipher suite, der er forhandlet mellem afsenderens og modtagerens mailservere, anses for at være svag eller usikker, hvilket potentielt kan kompromittere kommunikationens fortrolighed og integritet.
2. protocol_version_mismatch: Der er en uoverensstemmelse i de understøttede TLS-protokolversioner mellem afsenderens og modtagerens mailservere, hvilket forhindrer dem i at etablere en kompatibel krypteret forbindelse.
3. no_shared_cipher_suite: Der er ingen fælles cipher suite tilgængelig, som både afsenderens og modtagerens mailservere kan bruge til kryptering, hvilket resulterer i en mislykket forbindelse.

Problemer med håndtryk og protokol

1. handshake_failure: Der opstod et problem under den indledende TLS handshake-proces mellem afsenderens mailserver og modtagerens mailserver, hvilket forhindrede den sikre kanal i at blive etableret.
2. uventet_besked: Afsenderens mailserver modtog en uventet eller ikke-understøttet besked under TLS-handshake-processen, hvilket indikerer et potentielt protokol- eller implementeringsmisforhold.

MTA-STS-politiske spørgsmål

1. mta_sts_policy_not_found: Denne fejl opstår, når afsenderens mailserver ikke kan finde en MTA-STS-politik for modtagerens domæne.
2. mta_sts_policy_invalid: Denne fejl opstår, når den MTA-STS-politik, der findes i DNS for modtagerens domæne, er ugyldig, indeholder fejl eller ikke overholder MTA-STS-specifikationen.
3. mta_sts_policy_fetch_error: Denne fejl opstår, når afsenderens mailserver støder på en fejl, mens den forsøger at hente MTA-STS-politikken fra modtagerens domænes DNS-poster.
4. mta_sts_connection_failure: Denne fejl opstår, når afsenderens mailserver forsøger at etablere en sikker forbindelse ved hjælp af MTA-STS, men fejler på grund af årsager som upålidelige certifikater, ikke-understøttede cipher suites eller andre TLS-problemer.
5. mta_sts_invalid_hostname: Denne fejl opstår, når værtsnavnet på modtagerens mailserver, som angivet i MTA-STS-politikken, ikke stemmer overens med serverens faktiske værtsnavn.
6. mta_sts_policy_upgrade: Denne fejl opstår, når afsenderens mailserver forsøger at opgradere forbindelsen til en sikker forbindelse ved hjælp af MTA-STS, men modtagerens server ikke understøtter opgraderingen.

Forenklet SMTP TLS-rapportering med PowerDMARC

PowerDMARCs SMTP TLS-rapporteringsoplevelse handler om at forbedre din sikkerhed og samtidig gøre dit liv lettere med en hosted service.

Oversatte TLS-rapporter

Komplekse JSON-rapporter til TLS-rapportering konverteres til forenklede oplysninger, som du kan skimme igennem på få sekunder eller læse i detaljer.

Automatisk registrering af problemer

PowerDMARC-platformen udpeger automatisk det problem, du står over for, så du kan løse det uden at spilde tid

• Om
• Seneste indlæg

Ahona Rudra

Manager for digital markedsføring og indholdsskribent hos PowerDMARC

Ahona arbejder som Digital Marketing and Content Writer Manager hos PowerDMARC. Hun er en passioneret forfatter, blogger og marketingspecialist inden for cybersikkerhed og informationsteknologi.

Nyeste indlæg af Ahona Rudra (se alle)

• Metoder til at beskytte dig selv mod identitetstyveri - 29. september 2023
• DNS's rolle i e-mail-sikkerhed - 29. september 2023
• Den nye tids phishing-trusler og hvordan man planlægger forud - 29. september 2023