Hvad er SMTP TLS-rapportering?
I takt med at organisationer i stigende grad bruger e-mail som et primært kommunikationsmiddel, kan vigtigheden af at sikre disse kanaler mod potentielle trusler ikke overvurderes. Transport Layer Security (TLS) er en hjørnesten i at sikre fortroligheden og integriteten af data, der transmitteres på tværs af netværk.
Flere protokoller hjælper med at kryptere SMTP-meddelelseskanaler for at forhindre cyberangribere i at opsnappe e-mailkommunikation. Dette inkluderer STARTTLS, DANE og MTA-STS. Men når krypteringsforsøg mislykkes, mens du bruger disse protokoller, kan din e-mail muligvis ikke blive leveret. TLS-RPT (som beskrevet under RFC 8460) giver en feedback-mekanisme til at rapportere om disse leveringsfejl.
Vi anbefaler på det kraftigste at bruge TLS-RPT sammen med MTA-STS protokollen. Lad os forstå, hvordan disse protokoller arbejder sammen for at styrke e-mailsikkerheden.
Hvad er TLS-RPT?
TLS-RPT står for Transport Layer Security Reporting. Det er en standard for rapportering af problemer med e-maillevering, der opstår, når en e-mail ikke er krypteret med TLS. Dens betydning for e-mail-godkendelse går hånd i hånd med grunden til at aktivere TLS-kryptering til e-mails.
TLS-kryptering sikrer, at alle e-mails, der sendes til dig, bliver leveret sikkert. Hvis forbindelsen ikke er sikker, kan det ofte ske, at e-mails ikke bliver leveret. TLS-RPT gør det muligt for domæneejere at overvåge e-maillevering og forbindelsesfejl. Rapporterne kan indeholde oplysninger om:
- Problemer med håndtering af MTA-STS-politik
- Årsag til leveringssvigt og type
- IP-adresse på afsendere og modtagere af e-mails
- Samlet antal vellykkede og mislykkede TLS-forbindelsessessioner
Det giver synlighed på dine e-mailkanaler og mulighed for hurtigere at imødegå udfordringer med leveringsevnen.
Hvordan fungerer TLS-rapportering?
I SMTP-e-mailkommunikation er TLS-kryptering "opportunistisk". Det betyder, at hvis der ikke kan forhandles en krypteret kanal, sendes e-mailen stadig i et ukrypteret format (almindelig tekst). For næsten fire årtier siden understøttede SMTP-e-mailprotokoller faktisk ikke TLS-kryptering. Det måtte eftermonteres senere i form af kommandoen STARTTLS.
STARTTLS-kommandoen udstedes kun i SMTP-kommunikation, hvis begge sider understøtter TLS-kryptering. Ellers vil e-mailen stadig blive sendt i almindelig tekst.
For at slippe af med opportunistisk kryptering i SMTP blev MTA-STS introduceret (RFC 8461). MTA-STS-protokollen sikrer, at e-mails bliver krypteret, før de bliver leveret. Din e-mailserver eller Mail Transfer Agent (MTA) forhandler med den modtagende server for at se, om den understøtter STARTTLS-kommandoen. Hvis den gør, bliver e-mailen krypteret med TLS og leveret. Ellers mislykkes leveringen.
Der kan være flere årsager til TLS-krypteringsfejl. Ud over manglende understøttelse af kryptering på begge sider, kan mere uhyggelige årsager som et SMTP-nedgraderingsangreb føre til TLS-forbindelsesfejl. Når MTA-STS er aktiveret, kan angribere ikke levere beskeder i almindelig tekst, når en forbindelse fejler.
Men domæneejere vil gerne vide noget om den mislykkede levering. TLS-rapportering (TLS-RPT) er en protokol, der giver dig besked. Ved leveringsfejl vil du modtage din TLS-rapport i et JSON-filformat til den e-mailadresse, der er defineret i din TLS-RPT-post.
Hvorfor har du brug for SMTP TLS-rapportering?
Domæneejere skal holde sig informeret om e-mail
elveringsproblemer 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. TLS-RPT
- For at modtage feedbackrapporter, der fremhæver din forsikringstype og
- Sådan identificerer du årsagen til TLS-krypteringsfejl
- At opnå synlighed på e-mailkanaler
- At løse leveringsproblemer
Trin til opsætning af TLS-RPT
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
Trin 1: Vælg et TLS-RPT Record Generator-værktøj
Du kan tilmelde dig gratis på PowerDMARC og bruge vores TLS-RPT record generator til at oprette din record.
Trin 2: Indtast din e-mailadresse til rapportering
Indtast en e-mailadresse, som du ønsker at modtage dine SMTP TLS-rapporter på.
Trin 3: Udgiv TLS-optegnelsen på din DNS
Du kan kontakte din domæneregistrator for at oprette en ny TXT-post for TLS-RPT. Hvis du administrerer din egen DNS, skal du redigere dine DNS-indstillinger for at inkludere posten.
Eksempel på TLS-RPT-post
Syntaks: v=TLSRPTv1; rua=mailto:[email protected];
Lad os se nærmere på de to komponenter 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 protokollen.
- rua=mailto:[email protected]: rua står for "Reporting URI(s) for Aggregate Data". Dette tag specificerer, hvor modtagerens mailserver skal sende de aggregerede TLS-rapporter.
Du kan konfigurere mere end én destination til modtagelse af dine rapporter. For flere destinationer skal du adskille hver indtastning med et komma (,). Du kan enten bruge "maito:" til at angive en e-mailadresse for dette trin, eller instruere MTA'en i at sende rapporter via POST til endpoint-URL'er ved at bruge "https:" i rua=-feltet. Hvis du bruger "https:" skal du sørge for, at feltet definerer URL'en til en HTTPS-aktiveret webserver med et gyldigt certifikat. Både "mailto:" og "https:" kan også bruges i en enkelt post, adskilt af et komma.
Eksempel: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;
Bemærk: I praksis vil du erstatte "ditdomæne.com" med det faktiske domænenavn, hvor du ønsker at modtage disse rapporter.
TLS-rapporteringsformat
TLS-rapporter sendes i JSON-format. Nedenfor er et eksempel på, hvordan en JSON TLS-rapport kan se ud:
{
"organization-name": "Organization Inc.",
“date-range”: {
"start-datetime": “2020-10-22T00:00:00Z”,
"end-datetime": “2020-10-22T23:59:59Z”
},
"kontakt-info": "[email protected]",
"rapport-id": “2020-10-22T00:00:00Z_domain.com”,
"politikker": [
{
“policy”: {
"politik-type": "sts",
"politik-streng": [
"version: STSv1",
"tilstand: test",
"mx: mx.domain.com",
"mx: mx2.domain.com",
"mx: mx3.domain.com",
"max_age: 604800"
],
"politik-domæne": "domain.com"
},
“summary”: {
"total-successful-session-count": 15,
"total-failure-session-count": 0
}
Her er en oversigt over de vigtigste felter i denne JSON TLS-rapport:
Felter | Beskrivelse |
organisation | Den domæneorganisation, der ejer TLS-RPT-recorden. |
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 |
policy_string | Angiver den politikstreng, der er knyttet til politikken. |
tilstand | Angiver MTA-STS-politiktilstand (håndhævelse/test) |
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 mislykkede TLS-sessioner. |
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ælle | Antallet af sessioner, der mislykkedes af en bestemt årsag. |
Årsager til og typer af TLS-krypteringsfejl
Problemer med certifikater
Fejltyper | Årsager | Mulige forslag til fejlfinding |
certifikat_udløbet | Certifikatet fra fjernserveren har overskredet sin udløbsdato. Det gør det upålideligt til kryptering. | Forny dit certifikat. |
certifikat_ikke_gyldigt_endnu | Certifikatet fra fjernserveren er endnu ikke gyldigt. Det kan skyldes forkert servertid eller for tidlig brug af certifikatet. | Kontakt din certifikatudbyder. |
certifikat_tilbagekaldt | Certifikatet fra fjernserveren er blevet tilbagekaldt af certifikatmyndigheden på grund af sikkerhedsproblemer. | Kontakt din certifikatudbyder. |
no_valid_signature | Fjernserverens certifikatkæde er ikke pålidelig for afsenderens mailserver eller klient, hvilket indikerer en potentiel sikkerhedsrisiko. | Kontakt din certifikatudbyder. |
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. | Kontakt din certifikatudbyder. |
Uoverensstemmelse mellem værtsnavn og identitet
Fejltype | Årsag | Mulige forslag til fejlfinding |
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. Det indikerer et muligt man-in-the-middle-angreb eller et konfigurationsproblem. | Tjek MX-posterne i din MTA-STS-politikfil for at sikre, at de matcher MX-posten for domænet. |
Problemer med håndtryk og protokol
Fejltyper | Årsager | Mulige forslag til fejlfinding |
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. | Dobbelttjek, om SMTP STARTTLS-forbindelsen er blevet etableret. Der kan være flere årsager til krypteringsfejl, f.eks. manglende understøttelse af STARTTLS eller et TLS-nedgraderingsangreb. |
MTA-STS-politiske spørgsmål
Fejltyper | Årsager | Mulige forslag til fejlfinding |
mta_sts_policy_not_found | Denne fejl opstår, når afsenderens mailserver ikke kan finde en MTA-STS-politik for modtagerens domæne. | Gennemgå din MTA-STS-politikfil.
Tjek din MTA-STS-post for at sikre, at den blev offentliggjort korrekt. |
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. | Gennemgå din MTA-STS-politikfil.
Angiv en passende MTA-STS-politik. Det kan enten være Enforce eller Testing. |
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. | Valider MTA-STS-posterne i din DNS for at sikre, at postsyntaksen er korrekt. |
mta_sts_forbindelsesfejl | 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 f.eks. upålidelige certifikater, ikke-understøttede cipher suites eller andre TLS-problemer. | Tjek dit certifikats gyldighed, og sørg for, at det er opdateret med den seneste TLS-standard. |
mta_sts_invalid_hostname (ugyldigt værtsnavn) | 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. | Tjek MX-posterne i din MTA-STS-politikfil for at sikre, at de matcher MX-posten for domænet. |
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
Dine komplekse TLS-RPT JSON-rapporter bliver konverteret til forenklede oplysninger, som du kan skimme igennem på få sekunder eller læse i detaljer.
Automatisk registrering af problemer
PowerDMARC-platformen lokaliserer og fremhæver det problem, du står over for, så du kan løse det uden at spilde tid.
Der er ikke én ting, jeg ikke kan lide ved PowerDMARC-platformen, de har et brugervenligt og forståeligt layout med det, jeg vil kalde fulde funktioner, der giver mulighed for hosted DMARC-kontrol, SPF-udfladning, let at kunne udvide SPF-inkluderingen for at inspicere postens detaljer og endda fuld understøttelse af MTA-STS og TLS-RPT!
Dylan B (virksomhedsejer)
Ofte stillede spørgsmål om Transport Layer Security
1. Hvad står TLS for?
TLS står for Transport Layer Security.
2. Hvem udsteder TLS-certifikater?
Certificate Authorities (CA'er) kan udstede TLS-certifikater. Processen for udstedelse af certifikatet omfatter verifikation af certifikatindehaverens identitet. Ved vellykket identifikation udstedes certifikatet.
3. Hvorfor har jeg brug for et TLS-certifikat?
TLS-certifikater spiller en central rolle i sikringen af kommunikation over internettet. De hjælper med at kryptere følsomme oplysninger, der udveksles mellem kommunikerende webservere. Nogle af de mest almindelige anvendelser omfatter sikring af e-mailkommunikation og HTTPS.
4. Hvad er den nuværende TLS-standard?
TLS 1.3 er den seneste version af Transport Layer Security. TLS-RPT kan implementeres ved hjælp af enhver version af TLS. Dette kan omfatte ældre versioner af protokollen eller fremtidige versioner. Versionen bestemmes normalt af kriterier som de kommunikerende serveres kapacitet.
Yderligere ressourcer
- SubdoMailing og fremkomsten af subdomæne-phishing - 18. marts 2024
- Mailchimp DMARC, SPF og DKIM opsætningsguide - 26. februar 2024
- Hvad er SMTP TLS-rapportering? - 20. februar 2024