Hva er SMTP TLS -rapportering?

TLS Reporting er en omvendt tilbakemeldingsmekanisme som hjelper domeneeiere med å finne problemer med e-postleveringen med stor nøyaktighet. Den fungerer sammen med MTA-STS protokollen og gir sporingsdata om e-poster som ikke ble levert på grunn av et mislykket TLS-håndtrykk.

Hva betyr TLS-rapportering?

TLS-rapportering (TLS-RPT) er en standard for rapportering av e-postleveringsproblemer som oppstår når en e-post ikke er kryptert med TLS. Den støtter MTA-STS-protokollen, som brukes til å garantere at all e-post som sendes til domenet ditt, blir TLS-kryptert.

• TLS-kryptering sørger for at alle e-poster som sendes til deg, blir levert på en sikker måte. Angripere kan imidlertid forsøke å nedgradere SMTP, en type angrep der e-posten sendes til deg uten å være kryptert, slik at de kan lese eller manipulere innholdet. MTA-STS motvirker dette ved å kreve at alle e-poster krypteres før de sendes til deg. Hvis en angriper forsøker å utføre en SMTP-nedgradering, vil e-posten ikke bli sendt i det hele tatt.
• TLS-RPT gjør det mulig for deg, domeneeieren, å motta rapporter om hver e-post som ikke blir kryptert og ikke blir sendt til deg. Du kan deretter identifisere kilden til problemet og fikse leveringsproblemene.

Hvordan fungerer TLS-rapportering?

TLS-rapportering (TLS-RPT) brukes til å støtte MTA-STS-protokollen, som sikrer at e-post blir kryptert før den blir levert. Normalt forhandler e -postserveren eller Mail Transfer Agent (MTA) med den mottakende serveren for å se om den støtter STARTTLS -kommandoen. Hvis den gjør det, blir e -posten kryptert med TLS og blir levert til den mottakende MTA.

En angriper kan prøve et SMTP -nedgraderingsangrep på dette tidspunktet, som innebærer å blokkere forhandlingen mellom sendende og mottakende MTA. Sendingsserveren tror mottakeren ikke støtter STARTTLS -kommandoen og sender e -posten uten TLS -kryptering, slik at angriperen kan se eller tukle med e -postens innhold.

Når du implementerer MTA-STS i domenet ditt, blir det obligatorisk for avsenderserveren å kryptere meldinger før de sendes. Hvis en angriper forsøker et SMTP-nedgraderingsangrep, vil e-posten rett og slett ikke bli sendt. Dette sikrer TLS-kryptering på alle e-postmeldinger uten feil.

TLS-rapportering (TLS-RPT) er en protokoll som varsler deg som domeneeier når det oppstår leveringsproblemer med e-poster som sendes via domenet ditt. Hvis en e-post ikke kan sendes på grunn av en SMTP-nedgradering eller andre problemer, vil du motta en rapport i JSON-format som inneholder informasjon om e-posten som ikke ble levert. Denne rapporten inneholder ikke innholdet i e-posten.

Hvorfor trenger du SMTP TLS -rapportering?

Det er viktig for domeneeiere å holde seg informert om problemer med e-postlevering på grunn av feil i TLS-krypteringen for e-poster som sendes fra et MTA-STS-aktivert domene. TLS-rapportering gjør dette mulig ved å gi denne informasjonen. 

Motta tilbakemeldingsrapporter

Hvis en melding ikke blir sendt, hjelper TLS-rapportering deg med å få beskjed om det.

For å få full oversikt over e-postkanaler

Få detaljert innsikt i e-postflyten gjennom TLS-rapportering.

Eliminere leveringsproblemer

TLS-rapportering hjelper deg med å identifisere kilden til problemet og løse det uten forsinkelse.

Fremgangsmåte for å aktivere TLS-rapportering 

Du kan aktivere TLS-rapportering for domenet ditt ved å opprette en TXT-post for TLS-RPT og publisere den i DNS. Denne posten må publiseres på underdomenet _smtp._tls.dittdomene.com

Eksempel på TLS-RPT-oppføring

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

La oss bryte ned komponentene i den medfølgende TLS-rapporteringsposten:

v=TLSRPTv1:

Denne taggen angir hvilken versjon av TLS-RPT-protokollen som brukes. I dette tilfellet, "TLSRPTv1" den første versjonen av TLS-RPT-protokollen.

rua=mailto:[email protected]:

Denne taggen angir rapporterings-URI-en for de aggregerte rapportene (RUA). Den angir hvor mottakerens e-postserver skal sende aggregerte rapporter om TLS-feil. rua står for "Reporting URI for Aggregated Reports".

Verdien "mailto:[email protected]" er en URI som spesifiserer en e-postadresse ([email protected]) som de aggregerte rapportene skal sendes til via e-post.

I praksis vil du erstatte "dittdomene.com" med det faktiske domenenavnet der du ønsker å motta disse rapportene.

Betydningen av hver enkelt komponent:

v=TLSRPTv1:

Dette angir hvilken versjon av TLS-RPT-protokollen som brukes. Det bidrar til å sikre kompatibilitet mellom avsender og mottaker av rapportene.

rua=mailto:[email protected]:

Dette angir destinasjonen for aggregerte rapporter om TLS-leveringsproblemer. Ved å oppgi en rapporterende e-postadresse kan domeneeiere motta informasjon om mislykkede eller problematiske TLS-tilkoblinger. Rapportene er verdifulle for å diagnostisere potensielle sikkerhets- eller konfigurasjonsproblemer knyttet til e-postkommunikasjon.

TLS-rapporteringsformat og eksempel på rapport

En JSON TLS-rapport følger et bestemt format som er definert i TLS-RPT-spesifikasjonen (Transport Layer Security Reporting Policy). Dette formatet brukes til å formidle informasjon om e-postleveringsproblemer knyttet til TLS-kryptering. Nedenfor er et eksempel på hvordan en JSON TLS-rapport kan se ut:

Her er en oversikt over hovedfeltene i denne JSON TLS-rapporten:

organisasjon: Domeneorganisasjonen som eier TLS-RPT-oppføringen.

e-post: E-postadressen der aggregerte rapporter sendes.

begin_date: Startdatoen for rapporteringsperioden.

end_date: Sluttdatoen for rapporteringsperioden.

Politikk: En rekke policyobjekter som beskriver policyene som ble brukt i rapporteringsperioden.

policy: Inneholder informasjon om den anvendte policyen.

policy_type: Angir typen policy (f.eks. "policy" for en TLS-policy).

policy_string: Angir policystrengen som er knyttet til policyen (f.eks. "reject" for en streng TLS-policy).

sammendrag: Inneholder oppsummeringsinformasjon om øktene som ble forsøkt.

total_successful_session_count: Det totale antallet vellykkede TLS-økter.

total_failure_session_count: Det totale antallet mislykkede TLS-økter.

feil_detaljer: En rekke objekter som inneholder detaljer om spesifikke feil.

grunn: En streng som angir årsaken til feilen (f.eks. "certificate_expired").

Count: Antall økter som mislyktes av en bestemt grunn.

Årsaker til og typer feil i TLS-kryptering 

Sertifikatproblemer:

1. certificate_expired: Sertifikatet fra den eksterne serveren har passert utløpsdatoen, noe som gjør det upålitelig for kryptering.
2. certificate_not_valid_yet: Sertifikatet som presenteres av den eksterne serveren, er ennå ikke gyldig, muligens på grunn av feil servertid eller for tidlig bruk av sertifikatet.
3. certificate_revoked: Sertifikatet som presenteres av den eksterne serveren, har blitt tilbakekalt av sertifikatutstederen på grunn av sikkerhetsproblemer.
4. untrusted_certificate: Sertifikatkjeden som presenteres av den eksterne serveren, er ikke klarert av avsenderens e-postserver eller klient, noe som indikerer en potensiell sikkerhetsrisiko.
5. no_valid_signature: Sertifikatet som presenteres av den eksterne serveren, er ikke korrekt signert av en klarert sertifikatmyndighet, noe som gir grunn til bekymring for sertifikatets autentisitet.
6. ikke-støttet_sertifikat: Sertifikatet som presenteres av den eksterne serveren, bruker krypteringsalgoritmer eller nøkkellengder som ikke støttes av avsenderens e-postserver, noe som forhindrer en sikker tilkobling.

Uoverensstemmelse mellom vertsnavn og identitet

1. hostname_mismatch: Vertsnavnet som er angitt i serverens sertifikat, samsvarer ikke med vertsnavnet til serveren som avsenderens e-postserver prøver å koble til, noe som indikerer et mulig man-in-the-middle-angrep eller konfigurasjonsproblem.

Cipher Suite og krypteringskonfigurasjon

1. insecure_cipher_suite: Krypteringspakken som er forhandlet frem mellom avsenderens og mottakerens e-postservere, anses som svak eller usikker, noe som kan kompromittere kommunikasjonens konfidensialitet og integritet.
2. protocol_version_mismatch: Det er en uoverensstemmelse i de støttede TLS-protokollversjonene mellom avsenderens og mottakerens e-postservere, noe som hindrer dem i å opprette en kompatibel kryptert forbindelse.
3. no_shared_cipher_suite: Det finnes ingen felles krypteringssuite som både avsenderens og mottakerens e-postservere kan bruke til kryptering, noe som resulterer i en mislykket tilkobling.

Håndtrykk og protokollproblemer

1. handshake_failure: Det oppstod et problem under den innledende TLS-håndtrykksprosessen mellom avsenderens e-postserver og mottakerens e-postserver, noe som forhindret at den sikre kanalen ble opprettet.
2. uventet_melding: Avsenderens e-postserver mottok en uventet eller ikke-støttet melding under TLS-håndtrykksprosessen, noe som indikerer en potensiell protokoll- eller implementeringsfeil.

MTA-STS-politiske spørsmål

1. mta_sts_policy_not_found (ikke funnet): Denne feilen oppstår når avsenderens e-postserver ikke finner en MTA-STS-policy for mottakerens domene.
2. mta_sts_policy_invalid: Denne feilen oppstår når MTA-STS-policyen som finnes i DNS for mottakerens domene, er ugyldig, inneholder feil eller ikke overholder MTA-STS-spesifikasjonen.
3. mta_sts_policy_fetch_error: Denne feilen oppstår når avsenderens e-postserver støter på en feil når den prøver å hente MTA-STS-policyen fra mottakerens domenes DNS-poster.
4. mta_sts_connection_failure (mta_sts_tilkoblingsfeil): Denne feilen oppstår når avsenderens e-postserver forsøker å opprette en sikker tilkobling ved hjelp av MTA-STS, men mislykkes på grunn av årsaker som for eksempel sertifikater som ikke er klarerte, chiffersuiter som ikke støttes eller andre TLS-problemer.
5. mta_sts_invalid_hostname: Denne feilen oppstår når vertsnavnet på mottakerens e-postserver, som angitt i MTA-STS-policyen, ikke samsvarer med det faktiske vertsnavnet på serveren.
6. mta_sts_policy_upgrade: Denne feilen oppstår når avsenderens e-postserver forsøker å oppgradere forbindelsen til en sikker forbindelse ved hjelp av MTA-STS, men mottakerens server ikke støtter oppgraderingen.

Forenklet SMTP TLS-rapportering med PowerDMARC

PowerDMARCs SMTP TLS-rapporteringsopplevelse handler om å forbedre sikkerheten din og samtidig gjøre livet ditt enklere med en hostet tjeneste.

Oversatte TLS-rapporter

Komplekse JSON-rapporter for TLS-rapportering konverteres til forenklet informasjon som du kan skumme gjennom på sekunder eller lese i detalj.

Oppdag problemer automatisk

PowerDMARC -plattformen identifiserer automatisk problemet du står overfor, slik at du kan løse det uten å kaste bort tid

• Om
• siste innlegg

Ahona Rudra

Digital Marketing & Content Writer Manager hos PowerDMARC

Ahona jobber som Digital Marketing and Content Writer Manager hos PowerDMARC. Hun er en lidenskapelig forfatter, blogger og markedsføringsspesialist innen cybersikkerhet og informasjonsteknologi.

Siste innlegg av Ahona Rudra ( se alle )

• Metoder for å beskytte deg mot identitetstyveri - 29. september 2023
• Betydningen av DNS for e-postsikkerheten - 29. september 2023
• Den nye tidsalderens phishing-trusler og hvordan du planlegger i forkant - 29. september 2023