Nu organisaties steeds meer vertrouwen op e-mail als primair communicatiemiddel, kan het belang van het versterken van deze kanalen tegen potentiële bedreigingen niet genoeg worden benadrukt. Transport Layer Security (TLS) is een hoeksteen in het waarborgen van de vertrouwelijkheid en integriteit van gegevens die over netwerken worden verzonden.
Verschillende protocollen helpen bij het versleutelen van SMTP-berichtkanalen om te voorkomen dat cyberaanvallers e-mailcommunicatie kunnen onderscheppen. Hieronder vallen STARTTLS, DANE en MTA-STS. Wanneer versleutelingspogingen mislukken bij het gebruik van deze protocollen, kan het echter gebeuren dat uw e-mail niet wordt afgeleverd. TLS-RPT (zoals beschreven onder RFC 8460) biedt een feedbackmechanisme om deze mislukte afleverpogingen te rapporteren.
We raden ten zeerste aan om TLS-RPT te gebruiken in combinatie met de MTA-STS protocol. Laten we eens begrijpen hoe deze protocollen samenwerken om de beveiliging van e-mail te versterken.
Wat is TLS-RPT?
TLS-RPT staat voor Transport Layer Security Reporting. Het is een standaard voor het rapporteren van e-mailafleveringsproblemen die optreden wanneer een e-mail niet is versleuteld met TLS. Het belang ervan voor e-mailverificatie gaat hand in hand met de reden voor het inschakelen van TLS-encryptie voor e-mails.
TLS-encryptie zorgt ervoor dat elke e-mail die naar je wordt verzonden veilig wordt afgeleverd. Als de verbinding niet veilig is, worden e-mails vaak niet afgeleverd. TLS-RPT maakt het mogelijk voor domeineigenaren om e-mailaflevering en verbindingsfouten te controleren. De rapporten kunnen informatie bevatten over:
- Problemen met MTA-STS beleidsafhandeling
- Reden en type van mislukte levering
- IP-adres van verzendende en ontvangende e-mail transfer agents
- Totaal aantal succesvolle en mislukte TLS-verbindingssessies
Dit biedt inzicht in je e-mailkanalen en de mogelijkheid om deliverabilityproblemen sneller aan te pakken.
Hoe werkt TLS-rapportage?
In SMTP e-mailcommunicatie is TLS-encryptie "opportunistisch". Dit betekent dat als er niet over een versleuteld kanaal kan worden onderhandeld, de e-mail nog steeds in een onversleuteld (platte tekst) formaat wordt verzonden. In feite ondersteunden SMTP e-mailprotocollen bijna 4 decennia geleden geen TLS-encryptie. Het moest later worden toegevoegd in de vorm van het STARTTLS commando.
Het commando STARTTLS wordt alleen gegeven in SMTP communicatie als beide zijden TLS encryptie ondersteunen. Anders wordt de e-mail nog steeds in platte tekst verzonden.
Om af te komen van opportunistische encryptie in SMTP is MTA-STS geïntroduceerd (RFC 8461). Het MTA-STS protocol zorgt ervoor dat e-mails worden versleuteld voordat ze worden afgeleverd. Je e-mailserver of Mail Transfer Agent (MTA) onderhandelt met de ontvangende server om te zien of deze het STARTTLS commando ondersteunt. Als dat het geval is, wordt de e-mail versleuteld met TLS en afgeleverd. Anders mislukt de aflevering.
Er kunnen verschillende redenen zijn voor mislukte TLS-versleuteling. Naast een gebrek aan ondersteuning voor encryptie aan beide kanten, kunnen meer sinistere redenen zoals een SMTP downgrade aanval leiden tot het falen van een TLS verbinding. Met MTA-STS ingeschakeld, zijn aanvallers niet in staat om berichten in platte tekst af te leveren wanneer een verbinding mislukt.
Maar domeineigenaren willen graag weten wanneer de levering mislukt is. TLS-rapportage (TLS-RPT) is een protocol dat u op de hoogte brengt. Bij mislukte aflevering ontvangt u uw TLS-rapport in een JSON-bestandsindeling op het e-mailadres dat is gedefinieerd in uw TLS-RPT record.
Waarom hebt u SMTP TLS rapportering nodig?
Domeineigenaren moeten op de hoogte blijven van e-mail d
afleverproblemen als gevolg van fouten in TLS-codering voor e-mails die zijn verzonden vanaf een MTA-STS-domein. TLS-rapportage maakt dit mogelijk door deze informatie te verstrekken. TLS-RPT
- Om feedbackrapporten te ontvangen die je polistype en
- Om de reden voor TLS-coderingsfouten te achterhalen
- Zichtbaarheid krijgen op e-mailkanalen
- Problemen met de levering oplossen
Stappen om TLS-RPT in te stellen
U kunt TLS-rapportage voor uw domein inschakelen door een TXT-record voor TLS-RPT aan te maken en dit in uw DNS te publiceren. Dit record moet gepubliceerd worden op het subdomein smtp.tls.uwdomein.com
Stap 1: Selecteer een TLS-RPT Record Generator Tool
U kunt aanmelden gratis aanmelden bij PowerDMARC en onze TLS-RPT recordgenerator gebruiken om je record te maken.
Stap 2: Voer je e-mailadres voor rapportage in
Voer een e-mailadres in waarop u uw SMTP TLS-rapporten wilt ontvangen.
Stap 3: Publiceer het TLS Record op uw DNS
U kunt contact opnemen met uw domeinregistrar om een nieuw TXT-record aan te maken voor TLS-RPT. Als u uw eigen DNS beheert, bewerkt u uw DNS-instellingen om het record op te nemen.
Voorbeeld TLS-RPT record
Syntax: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com;
Laten we de 2 componenten van de geleverde TLS-record uitsplitsen:
- v=TLSRPTv1: Deze tag specificeert de versie van het TLS-RPT protocol dat wordt gebruikt. In dit geval, "TLSRPTv1 de eerste versie van het protocol aan.
- rua=mailto:tlsrpt@yourdomain.com: rua staat voor "Reporting URI(s) for Aggregate Data". Deze tag specificeert waar de mailserver van de ontvanger de geaggregeerde TLS-rapporten naartoe moet sturen.
Je kunt meer dan één bestemming configureren voor het ontvangen van je rapporten. Voor meerdere bestemmingen, scheid je elke invoer met een komma (,). Je kunt "maito:" gebruiken om een e-mailadres op te geven voor deze stap, of de MTA instrueren om rapporten via POST naar eindpunt-URL's te sturen door "https:" te gebruiken in het rua= veld. Als je "https:" zorg er dan voor dat het veld de URL definieert naar een webserver met HTTPS en een geldig certificaat. Zowel "mailto:" als "https:" kunnen ook worden gebruikt in één record, gescheiden door een komma.
Voorbeeld: v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsreport.example.com;
Opmerking: In de praktijk zou je "uwdomein.nl" vervangen door de domeinnaam waarop u deze rapporten wilt ontvangen.
TLS-rapportageformaat
TLS-rapporten worden in JSON-formaat verstuurd. Hieronder staat een voorbeeld van hoe een JSON TLS-rapport eruit zou kunnen zien:
{
"organization-name": "Organization Inc.",
“date-range”: {
"start-datetime": “2020-10-22T00:00:00Z”,
"eind-datum-tijd": “2020-10-22T23:59:59Z”
},
"contact-info": "smtp-tls-reporting@organization.com",
"report-id": “2020-10-22T00:00:00Z_domain.com”,
"Beleid": [
{
“policy”: {
"beleidstype": "sts",
"policy-string": [
"versie: STSv1",
"modus: testen",
"mx: mx.domain.com",
"mx: mx2.domain.com",
"mx: mx3.domain.com",
"max_age: 604800"
],
"policy-domain": "domain.com".
},
“summary”: {
"totaal-succesvolle-sessie-telling": 15,
"Totaal aantal mislukte sessies": 0
}
Hier is de uitsplitsing van de belangrijkste velden in dit JSON TLS-rapport:
| Velden | Beschrijving |
| organisatie | De domeinorganisatie die eigenaar is van het TLS-RPT record. |
| Het e-mailadres waar samengevoegde rapporten naartoe worden gestuurd. | |
| begindatum | De begindatum van de rapportageperiode. |
| einddatum | De einddatum van de rapportageperiode. |
| beleid | Een matrix van beleidsobjecten die de beleidsregels beschrijven die tijdens de rapportageperiode zijn toegepast. |
| beleid | Bevat informatie over het toegepaste beleid. |
| beleidstype | Specificeert het type beleid |
| beleidsring | Specificeert de beleidsstring geassocieerd met het beleid |
| stand | Specificeert de MTA-STS beleidsmodus (Afdwingen/Testen) |
| samenvatting | Bevat samenvattende informatie over de sessies die geprobeerd zijn. |
| totaal_geslaagde_sessie_aantal | De totale telling van succesvol opgezette TLS-sessies. |
| totaal_storing_sessie_aantal | De totale telling van mislukte TLS-sessies. |
| storing_gegevens | Een array van objecten die details geven over specifieke fouten. |
| reden | Een tekenreeks die de reden van de mislukking aangeeft (bijv. "certificate_expired"). |
| tel | Het aantal sessies dat mislukte om een specifieke reden. |
Fouten in TLS-codering Redenen en typen
Certificaatkwesties
| Soorten storingen | Redenen | Suggesties voor mogelijke probleemoplossing |
| certificaat_verlopen | Het certificaat van de externe server is verlopen. Dit maakt het onbetrouwbaar voor encryptie. | Verleng je certificaat. |
| certificaat_niet_geldig | Het certificaat van de externe server is nog niet geldig. Dit kan komen door een onjuiste servertijd of voortijdig certificaatgebruik. | Neem contact op met uw certificaatleverancier. |
| certificaat_herroepen | Het certificaat van de externe server is ingetrokken door de certificeringsinstantie vanwege beveiligingsproblemen. | Neem contact op met uw certificaatleverancier. |
| geen_geldige_handtekening | De certificaatketen van de externe server wordt niet vertrouwd door de mailserver of client van de afzender, wat wijst op een potentieel veiligheidsrisico. | Neem contact op met uw certificaatleverancier. |
| niet-ondersteund_certificaat | Het certificaat van de externe server gebruikt versleutelingsalgoritmen of sleutellengtes die niet worden ondersteund door de mailserver van de verzender, waardoor er geen veilige verbinding tot stand kan komen. | Neem contact op met uw certificaatleverancier. |
Hostnaam en identiteit komen niet overeen
| Type storing | Reden | Suggesties voor mogelijke probleemoplossing |
| hostnaam_incongruentie | De hostnaam in het certificaat van de server komt niet overeen met de hostnaam van de server waarmee de mailserver van de afzender verbinding probeert te maken. Dit wijst op een mogelijke man-in-the-middle aanval of een configuratieprobleem. | Controleer de MX records in je MTA-STS beleidsbestand om er zeker van te zijn dat ze overeenkomen met het MX record voor het domein. |
Handdruk en protocolproblemen
| Soorten storingen | Redenen | Suggesties voor mogelijke probleemoplossing |
| handdruk_fout | Er deed zich een probleem voor tijdens het eerste TLS-handshake-proces tussen de mailserver van de verzender en de mailserver van de ontvanger, waardoor het beveiligde kanaal niet tot stand kon worden gebracht. | Controleer of de SMTP STARTTLS verbinding tot stand is gebracht. Er kunnen verschillende redenen zijn die bijdragen aan mislukte versleuteling, zoals gebrek aan ondersteuning voor STARTTLS of een TLS downgrade aanval. |
MTA-STS Beleidskwesties
| Soorten storingen | Redenen | Suggesties voor mogelijke probleemoplossing |
| mta_sts_policy_not_found | Deze fout treedt op wanneer de mailserver van de verzender geen MTA-STS beleid kan vinden voor het domein van de ontvanger. | Controleer je MTA-STS beleidsbestand.
Controleer je MTA-STS record om er zeker van te zijn dat het correct gepubliceerd is. |
| mta_sts_policy_invalid | Deze fout treedt op wanneer het MTA-STS beleid gevonden in DNS voor het domein van de ontvanger ongeldig is, fouten bevat of niet voldoet aan de MTA-STS specificatie. | Controleer je MTA-STS beleidsbestand.
Geef een geschikte MTA-STS beleidsmodus op. Dit kan zijn Geen, Afdwingen of Testen. Dit instrueert verzendende servers hoe om te gaan met e-mails die mislukte validatie van het MTA-STS-beleid ondergaan. Lees hier meer over de beleidsmodi. |
| mta_sts_policy_fetch_error | Deze fout treedt op wanneer de mailserver van de verzender een foutmelding krijgt bij het ophalen van het MTA-STS beleid uit de DNS records van het domein van de ontvanger. | Valideer de MTA-STS records in je DNS om er zeker van te zijn dat de record syntax correct is. |
| mta_sts_verbinding_storing | Deze fout treedt op wanneer de mailserver van de verzender een beveiligde verbinding probeert op te zetten met MTA-STS, maar faalt om redenen zoals niet-vertrouwde certificaten, niet-ondersteunde cipher suites of andere TLS-problemen. | Controleer de geldigheid van je certificaat, zorg ervoor dat het certificaat up-to-date is met de nieuwste TLS-standaard. |
| mta_sts_invalid_hostname | Deze fout treedt op wanneer de hostnaam van de mailserver van de ontvanger, zoals gespecificeerd in het MTA-STS beleid, niet overeenkomt met de werkelijke hostnaam van de server. | Controleer de MX records in je MTA-STS beleidsbestand om er zeker van te zijn dat ze overeenkomen met het MX record voor het domein. |
Vereenvoudigde SMTP TLS-rapportage met PowerDMARC
De SMTP TLS-rapportage van PowerDMARC is gericht op het verbeteren van uw beveiliging terwijl uw leven eenvoudiger wordt met een gehoste service.
Vertaalde TLS-verslagen
Uw complexe TLS-RPT JSON-rapporten worden omgezet in vereenvoudigde informatie die u in enkele seconden kunt doorbladeren of in detail kunt lezen.
Autodetectie problemen
Het PowerDMARC-platform lokaliseert en belicht het probleem waarmee je te maken hebt, zodat je het kunt oplossen zonder tijd te verspillen.
Er is niet één ding dat ik goed vind aan het PowerDMARC platform, ze hebben een makkelijk te gebruiken en te begrijpen lay-out met wat ik zou noemen volledige functies voor gehoste DMARC controle, SPF afvlakking, de mogelijkheid om gemakkelijk de SPF includes uit te breiden om de details van het record te inspecteren en zelfs volledige ondersteuning voor MTA-STS en TLS-RPT!
Dylan B (bedrijfseigenaar)
Veelgestelde vragen over beveiliging van transportlagen
1. Waar staat TLS voor?
TLS staat voor Transport Layer Security.
2. Wie geeft TLS-certificaten uit?
Certificaatautoriteiten (CA's) kunnen TLS-certificaten uitgeven. Het proces voor de uitgifte van het certificaat omvat de verificatie van de identiteit van de certificaathouder. Na succesvolle identificatie wordt het certificaat uitgegeven.
3. Waarom heb ik een TLS-certificaat nodig?
TLS-certificaten spelen een cruciale rol bij het beveiligen van communicatie via het internet. Ze helpen bij het versleutelen van gevoelige informatie die wordt uitgewisseld tussen communicerende webservers. Enkele van de meest gebruikte toepassingen zijn het beveiligen van e-mailcommunicatie en HTTPS.
4. Wat is de huidige TLS-standaard?
TLS 1.3 is de nieuwste versie van Transport Layer Security. TLS-RPT kan geïmplementeerd worden met elke versie van TLS. Dit kunnen oudere versies van het protocol zijn of toekomstige versies. De versie wordt meestal bepaald door criteria zoals de mogelijkheden van de communicerende servers.
Aanvullende bronnen
- SMTP Yahoo foutcodes uitgelegd - 1 mei 2024
- SPF Softfail Vs Hardfail: Wat is het verschil? - 26 april 2024
- FTC meldt dat e-mail een populair medium is voor oplichting door imitators - 16 april 2024