Vad är SMTP TLS-rapportering?
TLS Reporting är en mekanism för omvänd feedback som hjälper domänägare att hitta problem med e-postleveransen med exakt precision. Den fungerar tillsammans med MTA-STS protokollet och tillhandahåller spårningsdata om avvisade e-postmeddelanden som inte kunde levereras på grund av en misslyckad TLS-handskakning.
Vad innebär TLS-rapportering?
TLS-rapportering (TLS-RPT) är en standard för att rapportera problem med e-postleverans som uppstår när ett e-postmeddelande inte är krypterat med TLS. Den stöder MTA-STS-protokollet som används för att garantera att e-post som skickas till din domän blir TLS-krypterad.
- TLS-kryptering säkerställer att alla e-postmeddelanden som skickas till dig levereras på ett säkert sätt. En angripare kan dock försöka göra en SMTP-nedgradering, en typ av attack där e-postmeddelandet skickas till dig utan att vara krypterat, vilket gör att de kan läsa eller manipulera innehållet. MTA-STS motverkar detta genom att göra det nödvändigt att kryptera alla e-postmeddelanden innan de skickas till dig. Om en angripare försöker utföra en SMTP-nedgradering kommer e-postmeddelandet inte att skickas alls.
- TLS-RPT gör det möjligt för dig som domänägare att ta emot rapporter om varje e-postmeddelande som inte krypteras och inte skickas till dig. Du kan sedan identifiera källan till problemet och åtgärda dina leveransproblem.
Hur fungerar TLS-rapportering?
TLS-rapportering (TLS-RPT) används för att stödja MTA-STS-protokollet, vilket säkerställer att e-postmeddelanden krypteras innan de levereras. Normalt förhandlar din e-postserver eller MTA (Mail Transfer Agent) med den mottagande servern för att se om den stöder STARTTLS-kommandot. Om det gör det krypteras e-postmeddelandet med TLS och levereras till den mottagande MTA.
En angripare kan försöka en SMTP-nedgraderingsattack vid denna tidpunkt, vilket innebär att blockera förhandlingen mellan de sändande och mottagande MTA: erna. Den sändande servern tror att mottagaren inte stöder STARTTLS-kommandot och skickar e-postmeddelandet utan TLS-kryptering, så att angriparen kan visa eller manipulera e-postmeddelandets innehåll.
När du implementerar MTA-STS i din domän blir det obligatoriskt för din sändande server att kryptera meddelanden innan de skickas. Om en angripare försöker sig på en SMTP-nedgraderingsattack kommer e-postmeddelandet helt enkelt inte att skickas. Detta säkerställer TLS-kryptering på alla dina e-postmeddelanden utan att misslyckas.
TLS-rapportering (TLS-RPT) är ett protokoll som meddelar dig som domänägare när e-postmeddelanden som skickas via din domän har problem med leveransen. Om ett e-postmeddelande inte kan skickas på grund av en SMTP-nedgradering eller något annat problem får du en rapport i JSON-filformat som innehåller information om det e-postmeddelande som misslyckades. Denna rapport innehåller inte innehållet i e-postmeddelandet.
Varför behöver du SMTP TLS-rapportering?
Det är viktigt för domänägare att hålla sig informerade om problem med e-postleveranser på grund av fel i TLS-kryptering för e-postmeddelanden som skickas från en MTA-STS-aktiverad domän. TLS-rapportering gör det möjligt genom att tillhandahålla denna information.
Att ta emot feedbackrapporter
Om ett meddelande inte skickas hjälper TLS-rapportering dig att få ett meddelande om detta
Få total överblick över e-postkanalerna
Få detaljerade insikter om ditt e-postflöde genom TLS-rapportering
För att eliminera leveransproblem
TLS-rapportering hjälper dig att identifiera källan till problemet och åtgärda det utan fördröjning
Steg för att aktivera TLS-rapportering
Du kan aktivera TLS-rapportering för din domän genom att skapa en TXT-post för TLS-RPT och publicera den i din DNS. Den här posten måste publiceras på underdomänen _smtp._tls.dindomän.com
Exempel på TLS-RPT-post
v=TLSRPTv1; rua=mailto:[email protected];
Låt oss dela upp komponenterna i den tillhandahållna TLS-rapporteringen:
v=TLSRPTv1:
Denna tagg anger vilken version av TLS-RPT-protokollet som används. I detta fall, "TLSRPTv1" den första versionen av TLS-RPT-protokollet.
rua=mailto:[email protected]:
Denna tagg anger rapporterings-URI för de aggregerade rapporterna (RUA). Den anger var mottagarens e-postserver ska skicka aggregerade rapporter om TLS-misslyckanden. rua står för "Reporting URI for Aggregated Reports".
Värde "mailto:[email protected]" är en URI som anger en e-postadress ([email protected]) till vilken de aggregerade rapporterna ska skickas via e-post.
I praktiken skulle du ersätta "dindomän.com" med det faktiska domännamn där du vill ta emot dessa rapporter.
Betydelsen av varje komponent:
v=TLSRPTv1:
Detta anger vilken version av TLS-RPT-protokollet som används. Det hjälper till att säkerställa kompatibilitet mellan sändaren och mottagaren av rapporterna.
rua=mailto:[email protected]:
Detta anger destinationen för aggregerade rapporter om TLS-leveransproblem. Genom att ange en e-postadress för rapportering kan domänägare få information om misslyckade eller problematiska TLS-anslutningar. Rapporterna är värdefulla för att diagnostisera potentiella säkerhets- eller konfigurationsproblem relaterade till e-postkommunikation.
TLS-rapporteringsformat och exempel på rapport
En JSON TLS-rapport följer ett specifikt format som definieras av TLS-RPT-specifikationen (Transport Layer Security Reporting Policy). Formatet används för att förmedla information om problem med e-postleveranser som är relaterade till TLS-kryptering. Nedan följer ett exempel på hur en JSON TLS-rapport kan se ut:
Här är uppdelningen av de viktigaste fälten i denna JSON TLS-rapport:
organisation: Den domänorganisation som äger TLS-RPT-posten.
e-post: E-postadressen dit aggregerade rapporter skickas.
start_datum: Rapporteringsperiodens startdatum.
slut_datum: Slutdatum för rapporteringsperioden.
politik: En uppsättning policyobjekt som beskriver de policyer som tillämpats under rapporteringsperioden.
politik: Innehåller information om den tillämpade policyn.
policy_typ: Anger typen av policy (t.ex. "policy" för en TLS-policy).
policy_sträng: Anger policysträngen som är associerad med policyn (t.ex. "reject" för en strikt TLS-policy).
sammanfattning: Innehåller sammanfattande information om de sessioner som försökts.
totalt antal framgångsrika sessioner: Det totala antalet framgångsrikt upprättade TLS-sessioner.
totalt_fel_session_antal: Det totala antalet misslyckade TLS-sessioner.
fel_detaljer: En matris med objekt som ger detaljer om specifika fel.
anledning: En sträng som anger orsaken till felet (t.ex. "certificate_expired").
räkna: Antalet sessioner som misslyckades av en viss anledning.
Orsaker och typer av fel på TLS-kryptering
Frågor om certifikat:
- certifikat_utgånget: Certifikatet som presenteras av fjärrservern har passerat utgångsdatumet, vilket gör det opålitligt för kryptering.
- certifikat_inte_giltigt_tidigt: Certifikatet som presenteras av fjärrservern är ännu inte giltigt, eventuellt på grund av felaktig servertid eller för tidig användning av certifikatet.
- certifikat_återkallat: Certifikatet som visas av fjärrservern har återkallats av certifikatutfärdaren på grund av säkerhetsproblem.
- otillförlitligt_certifikat: Certifikatkedjan som presenteras av fjärrservern är inte betrodd av avsändarens e-postserver eller klient, vilket indikerar en potentiell säkerhetsrisk.
- ingen_giltig_signatur: Certifikatet som fjärrservern visar är inte korrekt signerat av en betrodd certifikatutfärdare, vilket väcker frågor om dess äkthet.
- certifikat som inte stöds: Certifikatet som presenteras av fjärrservern använder krypteringsalgoritmer eller nyckellängder som inte stöds av avsändarens e-postserver, vilket förhindrar en säker anslutning.
Mismatch mellan värdnamn och identitet
- värdnamn_mismatch: Det värdnamn som anges i serverns certifikat stämmer inte överens med värdnamnet på den server som avsändarens e-postserver försöker ansluta till, vilket tyder på en möjlig man-in-the-middle-attack eller ett konfigurationsproblem.
Konfiguration av chiffersvit och kryptering
- osäker_kryptering_suite: Den chiffersvit som förhandlats fram mellan avsändarens och mottagarens e-postservrar anses vara svag eller osäker, vilket kan äventyra kommunikationens konfidentialitet och integritet.
- protokoll_version_mismatch: Det finns en avvikelse i de TLS-protokollversioner som stöds mellan avsändarens och mottagarens e-postservrar, vilket hindrar dem från att upprätta en kompatibel krypterad anslutning.
- no_shared_cipher_suite: Det finns ingen gemensam chiffersvit tillgänglig för både avsändarens och mottagarens e-postservrar att använda för kryptering, vilket resulterar i en misslyckad anslutning.
Handskakning och protokollfrågor
- handskakning_fel: Ett problem uppstod under den inledande TLS-handskakningsprocessen mellan avsändarens e-postserver och mottagarens e-postserver, vilket förhindrade att den säkra kanalen upprättades.
- oväntat_meddelande: Avsändarens e-postserver tog emot ett oväntat eller icke-stöttat meddelande under TLS-handskakningsprocessen, vilket indikerar en potentiell protokoll- eller implementeringsmissmatchning.
MTA-STS policyfrågor
- mta_sts_policy_not_found: Detta fel uppstår när avsändarens e-postserver inte kan hitta en MTA-STS-policy för mottagarens domän.
- mta_sts_policy_invalid: Det här felet uppstår när MTA-STS-policyn som finns i DNS för mottagarens domän är ogiltig, innehåller fel eller inte följer MTA-STS-specifikationen.
- mta_sts_policy_fetch_error: Detta fel inträffar när avsändarens e-postserver stöter på ett fel när den försöker hämta MTA-STS-policyn från mottagarens domäns DNS-poster.
- mta_sts_connection_failure: Detta fel inträffar när avsändarens e-postserver försöker upprätta en säker anslutning med MTA-STS men misslyckas på grund av orsaker som otillförlitliga certifikat, chiffersviter som inte stöds eller andra TLS-problem.
- mta_sts_invalid_hostname: Detta fel uppstår när värdnamnet på mottagarens e-postserver, som anges i MTA-STS-principen, inte stämmer överens med serverns faktiska värdnamn.
- mta_sts_policy_uppgradering: Detta fel uppstår när avsändarens e-postserver försöker uppgradera anslutningen till en säker anslutning med hjälp av MTA-STS, men mottagarens server inte stöder uppgraderingen.
Förenklad SMTP TLS-rapportering med PowerDMARC
PowerDMARC:s SMTP TLS-rapportering handlar om att förbättra din säkerhet och samtidigt göra ditt liv enklare med en hostad tjänst.
Översatta TLS-rapporter
Komplexa JSON-rapporter för TLS-rapportering omvandlas till förenklad information som du kan skumma igenom på några sekunder eller läsa i detalj
Identifiera problem automatiskt
PowerDMARC-plattformen pekar automatiskt ut problemet du står inför så att du kan lösa det utan att slösa tid
- Webbsäkerhet 101 - bästa praxis och lösningar - 29 november 2023
- Vad är e-postkryptering och vilka är dess olika typer? - Den 29 november 2023
- Vad är MTA-STS? Ställ in rätt MTA STS-policy - 25 november 2023
