Kort gezegd, is MTA-STS een manier om e-mails extra te beschermen tegen onderschepping (d.w.z. Man-in-the-Middle-aanvallen) tijdens de overdracht tussen e-mailservers. Het lost gedeeltelijk erfenisarchitecturale problemen van e-mailprotocollen op en is beschreven in de relatief recente standaard RFC 8461. Mail.ru is de eerste grote e-maildienst in het Russische internet die deze standaard heeft geïmplementeerd. Meer details worden verderop besproken.

Welke problemen lost MTA-STS op?

Historisch gezien verstuurden e-mailprotocollen (SMTP, POP3, IMAP) informatie in open tekst, waardoor deze onderschept kon worden, bijvoorbeeld bij toegang tot de communicatiekanalen.

Hoe ziet het mechanisme voor het verzenden van een e-mail van de ene gebruiker naar de andere eruit:

Historisch gezien was een MitM-aanval mogelijk op alle plekken waar e-mailverkeer plaatsvond.

De RFC 8314-standaard vereist het verplicht gebruik van TLS tussen de e-mailclient van de gebruiker (MUA) en de e-mailserver. Als uw server en de gebruikte e-mailapplicaties voldoen aan RFC 8314, heeft u (in grote mate) de mogelijkheid van Man-in-the-Middle-aanvallen tussen de gebruiker en de e-mailservers geëlimineerd.

Het naleven van algemeen aanvaarde praktijken (gestandaardiseerd in RFC 8314) elimineert de aanval nabij de gebruiker:

De Mail.ru-e-mailservers voldeden al aan RFC 8314 voordat de standaard werd aangenomen; feitelijk bevestigt het gewoon al geaccepteerde praktijken, en we hoefden niets extra in te stellen. Maar als uw e-mailserver nog steeds toegang toestaat via onveilige protocollen, implementeer dan de aanbevelingen van deze standaard, aangezien het waarschijnlijk is dat ten minste een deel van uw gebruikers e-mail zonder encryptie gebruikt, zelfs als u het ondersteunt.

Een e-mailclient werkt altijd met dezelfde e-mailserver van dezelfde organisatie. Het is mogelijk om alle gebruikers gedwongen veilig te laten verbinden, waarna het technisch onmogelijk wordt om onveilig te verbinden (zoals vereist door RFC 8314). Dit is soms lastig, maar haalbaar. Het verkeer tussen e-mailservers is nog complexer. Servers behoren tot verschillende organisaties en worden vaak in een ‘plaats en vergeet’ modus gebruikt, wat een gelijktijdige overstap naar een veilig protocol onmogelijk maakt zonder de connectiviteit te verstoren. SMTP voorziet al geruime tijd in de extensie STARTTLS, waarmee servers die encryptie ondersteunen kunnen overschakelen naar TLS. Maar een aanvaller die invloed heeft op het verkeer kan informatie over de ondersteuning van deze opdracht 'weghalen' en servers dwingen om per gewone tekstprotocol te communiceren (een zogenaamde downgrade-aanval). Om deze reden wordt er voor STARTTLS meestal geen validatie van het certificaat gecontroleerd (een onbetrouwbaar certificaat kan beschermen tegen passieve aanvallen, en is niet slechter dan het verzenden van een e-mail in platte tekst). Daarom beschermt STARTTLS alleen tegen passieve afluistering.

MTA-STS verhelpt gedeeltelijk het probleem van het onderscheppen van e-mails tussen e-mailservers, wanneer de aanvaller de mogelijkheid heeft om actief in te grijpen in het verkeer. Als het domein van de ontvanger een MTA-STS-beleid publiceert en de verzendende server MTA-STS ondersteunt, zal hij de e-mail alleen via een TLS-verbinding verzenden, alleen naar servers die door het beleid zijn gedefinieerd, en alleen met een certificaatvalidatie van de server.

Waarom gedeeltelijk? MTA-STS werkt alleen als beide partijen zich hebben bekommerd om deze standaard in te voeren, en MTA-STS biedt geen bescherming tegen scenario's waarbij een aanvaller in staat is om een geldig domeincertificaat te verkrijgen van een van de publieke CA's.

Hoe werkt MTA-STS

Ontvanger

Stelt ondersteuning voor STARTTLS in met een geldig certificaat op de e-mailserver.
Publiceert via HTTPS het MTA-STS-beleid; voor publicatie wordt een speciaal domein mta-sts en een speciaal well-known pad gebruikt, bijvoorbeeld https://mta-sts.mail.ru/.well-known/mta-sts.txt. Het beleid bevat een lijst van e-mailservers (mx) die het recht hebben om e-mail voor dit domein te ontvangen.
Publiceert een speciale TXT-record _mta-sts in DNS met de versie van het beleid. Bij wijziging van het beleid moet dit record worden bijgewerkt (dit signaleert de afzender om het beleid opnieuw op te vragen). Bijvoorbeeld, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Afzender

De afzender vraagt het DNS-record _mta-sts op, en als het aanwezig is, doet hij een beleidsovereenkomst via HTTPS (ter controle van het certificaat). Het verkregen beleid wordt gecached (voor het geval een aanvaller toegang blokkeert of het DNS-record vervangt).

Bij het verzenden van e-mail wordt gecontroleerd of:

de server waarop de e-mail wordt afgeleverd in het beleid voorkomt;
de server e-mail accepteert met gebruik van TLS (STARTTLS) en een geldig certificaat heeft.

Voordelen van MTA-STS

MTA-STS maakt gebruik van technologieën die al in de meeste organisaties zijn geïmplementeerd (SMTP+STARTTLS, HTTPS, DNS). Voor implementatie aan de ontvangende kant is er geen speciale softwareondersteuning van de standaard nodig.

Nadelen van MTA-STS

Het is noodzakelijk om de geldigheid van het certificaat van de web- en mailserver te controleren, evenals de naamconsistentie en tijdige updates. Problemen met het certificaat zullen leiden tot onmogelijkheid om de e-mail te bezorgen.

Aan de zenderzijde is een MTA met ondersteuning voor MTA-STS-beleidsregels vereist; momenteel wordt MTA-STS niet 'out of the box' ondersteund in MTA.

MTA-STS maakt gebruik van een lijst van vertrouwde root-CA's.

MTA-STS beschermt niet tegen aanvallen waarbij de aanvaller een geldig certificaat gebruikt. In de meeste gevallen impliceert MitM in de nabijheid van de server de mogelijkheid van het uitgeven van een certificaat. Dergelijke aanvallen kunnen worden gedetecteerd via Certificate Transparency. Daarom mitigaties MTA-STS, maar elimineert het niet volledig de mogelijkheid van verkeersafluisteren.

De laatste twee punten maken MTA-STS minder veilig dan de concurrerende standaard DANE voor SMTP (RFC 7672), maar technisch betrouwbaarder, dat wil zeggen dat de kans dat een e-mail niet wordt afgeleverd door technische problemen als gevolg van de implementatie van de standaard laag is.

De concurrerende standaard is DANE

DANE maakt gebruik van DNSSEC voor de publicatie van certificaatinformatie en vereist geen vertrouwen in externe certificeringsautoriteiten, wat veel veiliger is. Echter, het gebruik van DNSSEC leidt aanzienlijk vaker tot technische storingen, wanneer we kijken naar statistieken over meerdere jaren gebruik (hoewel de betrouwbaarheid van DNSSEC en de algemene technische ondersteuning positief lijkt te verbeteren). Voor de implementatie van DANE in SMTP aan de zijde van de ontvanger is de aanwezigheid van DNSSEC in de DNS-zone verplicht, en voor DANE is correcte ondersteuning van NSEC/NSEC3 essentieel, waarvoor DNSSEC systematische problemen kent.

Als DNSSEC verkeerd is geconfigureerd, kan dit leiden tot bezorgproblemen van e-mail, als de verzendende partij DANE ondersteunt, zelfs als de ontvangende partij hierover niets weet. Daarom, hoewel DANE een ouder en veiliger standaard is dat al wordt ondersteund door bepaalde serversoftware aan de verzendende kant, is de feitelijke adoptie ervan gering, aangezien veel organisaties aarzelen om het te implementeren vanwege de noodzaak om DNSSEC te realiseren, wat de implementatie van DANE jarenlang heeft vertraagd.

DANE en MTA-STS conflicteren niet met elkaar en kunnen samen worden gebruikt.

Wat is de ondersteuning van MTA-STS in Mail.ru?

Mail.ru publiceert al geruime tijd het MTA-STS-beleid voor alle belangrijke domeinen. Momenteel zijn we bezig met de implementatie van de klantzijde van de standaard. Op het moment van schrijven van dit artikel worden de beleidsregels toegepast in een niet-blokkerende modus (indien de bezorging wordt geblokkeerd door het beleid, wordt de e-mail afgeleverd via een ‘back-up’ server zonder toepassing van het beleid), daarna zal er een blokkerende modus worden afgedwongen voor een klein deel van het uitgaande SMTP-verkeer, en geleidelijk zal voor 100% van het verkeer de toepassing van beleidsregels worden ondersteund.

Wie ondersteunt de standaard nog meer?

Momenteel publiceert ongeveer 0,05% van de actieve domeinen MTA-STS-beleidsregels, maar toch beschermen ze al een aanzienlijk volume van het e-mailverkeer, aangezien grote spelers zoals Google, Comcast en gedeeltelijk Verizon (AOL, Yahoo) de standaard ondersteunen. Veel andere e-maildiensten hebben aangekondigd dat ondersteuning voor de standaard in de nabije toekomst zal worden geïmplementeerd.

Hoe raakt dit mij?

Geen, als uw domein geen MTA-STS-beleid publiceert. Als u een beleid publiceert, worden de e-mails voor de gebruikers van uw mailserver beter beschermd tegen onderschepping.

Hoe implementeer ik MTA-STS?

Ondersteuning voor MTA-STS aan de ontvangende kant

Het is voldoende om een beleid te publiceren via HTTPS en DNS-records, een geldig certificaat te configureren van een van de vertrouwde CA's (zoals Let’s Encrypt) voor STARTTLS in de MTA (STARTTLS wordt ondersteund in alle moderne MTA's), speciale ondersteuning van de MTA is niet vereist.

In stappen ziet dat er als volgt uit:

Configureer STARTTLS in de gebruikte MTA (postfix, exim, sendmail, Microsoft Exchange, enz.).
Zorg ervoor dat er een geldig certificaat wordt gebruikt (uitgegeven door een vertrouwde CA, niet verlopen, het onderwerp van het certificaat komt overeen met het MX-record waarvoor de e-mail voor uw domein wordt afgeleverd).
Configureer een TLS-RPT-record waarop rapporten over het gebruik van het beleid zullen worden afgeleverd (door diensten die het verzenden van TLS-rapporten ondersteunen). Voorbeeldrecord (voor domein example.com):
```
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
```
Dit record instrueert e-mailverzenders om statistische rapporten over het gebruik van TLS in SMTP te verzenden naar het adres tlsrpt@exmple.com.
Houd de rapporten een paar dagen in de gaten, zorg ervoor dat er geen fouten zijn.
Publiceer het MTA-STS-beleid via HTTPS. Het beleid wordt gepubliceerd als een tekstbestand met CRLF-regelterminators op de aangegeven locatie.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Voorbeeldbeleid:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Het versieveld bevat de versie van het beleid (dit is momenteel STSv1), Mode specificeert de toepassing van het beleid, testing - testmodus (het beleid wordt niet toegepast), enforce - 'live' modus. Publiceer het beleid eerst met mode: testing; als er geen problemen zijn met het beleid in de testmodus, kan na enige tijd worden overgeschakeld naar mode: enforce.
In mx wordt een lijst gedefinieerd van alle mailservers die e-mail voor uw domein kunnen ontvangen (elk server moet een certificaat hebben dat overeenkomt met de naam die in mx is opgegeven). Max_age bepaalt de tijdsduur voor het cachen van het beleid (eenmaal gecached, zal het beleid worden toegepast, zelfs als een aanvaller het ophalen ervan blokkeert of DNS-records tijdens de cachingperiode beschadigt. Aangeven dat het nodig is om het beleid opnieuw op te vragen kan via het wijzigen van het mta-sts DNS-record).
Publiceer een DNS TXT-record:
```
_mta-sts.example.com. TXT "v=STS1; id=someid;"
```
In het id-veld kan een willekeurige identificator worden gebruikt (bijvoorbeeld een timestamp); bij wijziging van het beleid moet deze ook wijzigen, zodat verzenders begrijpen dat ze de gecachete beleidsinstelling opnieuw moeten opvragen (als de identificator verschilt van de gecachete versie).

Ondersteuning voor MTA-STS aan de kant van de verzender

Tot nu toe is de ondersteuning slecht, omdat de standaard nieuw is.

Exim — er is geen ingebouwde ondersteuning, er is een extern script beschikbaar https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix — er is geen ingebouwde ondersteuning, er is een extern script dat uitgebreid wordt beschreven op Habr https://habr.com/en/post/424961/

Als naschrift over 'verplichte TLS'

Recentelijk besteden toezichthouders aandacht aan de beveiliging van e-mail (en dat is goed). Zo is DMARC verplicht voor alle overheidsinstellingen in de VS en wordt steeds vaker vereist in de financiële sector; in gereguleerde sectoren bereikt de implementatie van de standaard 90%. Sommige toezichthouders vereisen nu de invoering van 'verplichte TLS' met afzonderlijke domeinen, maar de mechanismen voor het waarborgen van 'verplichte TLS' worden niet gedefinieerd en in de praktijk wordt deze instelling vaak op een manier geïmplementeerd die zelfs minimaal niet beschermt tegen echte aanvallen, die al zijn voorzien in mechanismen zoals DANE of MTA-STS.

Als een toezichthouder de implementatie van 'verplichte TLS' met afzonderlijke domeinen vereist, raden we aan om MTA-STS of een gedeeltelijk equivalent als de meest geschikte mechanismen te overwegen; dit elimineert de noodzaak om veilige instellingen voor elk domein afzonderlijk te maken. Als je problemen hebt met de implementatie van de clientzijde van MTA-STS (aangezien het protocol nog niet breed wordt ondersteund, zullen deze waarschijnlijk optreden), kan de volgende aanpak worden aanbevolen:

Publiceer het MTA-STS-beleid en/of DANE-records (DANE heeft alleen zin als DNSSEC voor jouw domein al is ingeschakeld, en MTA-STS in ieder geval), dit beschermt het verkeer naar jouw domein en maakt het overbodig om andere e-maildiensten te vragen om verplichte TLS voor jouw domein in te stellen, als de e-maildienst al MTA-STS en/of DANE ondersteunt.
Voor grote e-mailservices implementeer je een 'evenement' MTA-STS via aparte transportinstellingen voor elk domein, die de MX vastleggen die gebruikt wordt voor het doorsturen van e-mail en zullen vereisen dat er een verplichte controle van het TLS-certificaat plaatsvindt. Als de domeinen al een MTA-STS-beleid publiceren, kan dit waarschijnlijk zonder problemen worden gedaan. Het inschakelen van verplichte TLS voor een domein zonder vastlegging van de relay en controle van het certificaat is op zich niet effectief vanuit beveiligingsperspectief en voegt niets toe aan de bestaande STARTTLS-mechanismen.

Bron: habr.com