Kortom, MTA-STS is een manier om e-mails verder te beschermen tegen onderschepping (dat wil zeggen man-in-the-middle-aanvallen, oftewel MitM) wanneer ze tussen mailservers worden verzonden. Het lost gedeeltelijk de oudere architectonische problemen van e-mailprotocollen op en wordt beschreven in de relatief recente standaard RFC 8461. Mail.ru is de eerste grote mailservice op RuNet die deze standaard implementeert. En het wordt in meer detail beschreven onder de snit.

Welk probleem lost MTA-STS op?

Historisch gezien verzonden e-mailprotocollen (SMTP, POP3, IMAP) informatie in duidelijke tekst, waardoor het mogelijk werd deze te onderscheppen, bijvoorbeeld bij toegang tot een communicatiekanaal.

Hoe ziet het mechanisme voor het bezorgen van een brief van de ene gebruiker naar de andere eruit:

Historisch gezien was een MitM-aanval mogelijk op alle plaatsen waar post circuleert.

RFC 8314 vereist het gebruik van TLS tussen de mailgebruikerstoepassing (MUA) en de mailserver. Als uw server en de mailapplicaties die u gebruikt voldoen aan RFC 8314, dan heeft u de mogelijkheid van Man-in-the-Middle-aanvallen tussen de gebruiker en de mailservers (grotendeels) geëlimineerd.

Door algemeen aanvaarde praktijken te volgen (gestandaardiseerd door RFC 8314) wordt de aanval dichtbij de gebruiker geëlimineerd:

Mail.ru-mailservers voldeden aan RFC 8314, zelfs voordat de standaard werd aangenomen; in feite legt het eenvoudigweg reeds geaccepteerde praktijken vast, en hoefden we niets extra's te configureren. Maar als uw mailserver nog steeds toestaat dat gebruikers onveilige protocollen gebruiken, zorg er dan voor dat u de aanbevelingen van deze standaard implementeert Hoogstwaarschijnlijk werken in ieder geval een deel van uw gebruikers met e-mail zonder encryptie, zelfs als u dit ondersteunt.

De mailclient werkt altijd met dezelfde mailserver van dezelfde organisatie. En je kunt alle gebruikers dwingen om op een veilige manier verbinding te maken, en het vervolgens technisch onmogelijk maken voor niet-beveiligde gebruikers om verbinding te maken (dit is precies wat RFC 8314 vereist). Dat is soms lastig, maar wel te doen. Het verkeer tussen mailservers is nog ingewikkelder. Servers zijn eigendom van verschillende organisaties en worden vaak gebruikt in een ‘instellen en vergeten’-modus, waardoor het onmogelijk is om in één keer over te schakelen naar een veilig protocol zonder de connectiviteit te verbreken. SMTP biedt al geruime tijd de STARTTLS-extensie, waarmee servers die encryptie ondersteunen, kunnen overschakelen naar TLS. Maar een aanvaller die het verkeer kan beïnvloeden, kan informatie over de ondersteuning van dit commando 'wegsnijden' en de servers dwingen te communiceren met behulp van een plat tekstprotocol (de zogenaamde downgrade-aanval). Om dezelfde reden controleert STARTTLS meestal niet de geldigheid van het certificaat (een niet-vertrouwd certificaat kan bescherming bieden tegen passieve aanvallen, en dit is niet slechter dan het verzenden van een bericht in gewone tekst). Daarom beschermt STARTTLS alleen tegen passief afluisteren.

MTA-STS elimineert gedeeltelijk het probleem van het onderscheppen van brieven tussen mailservers, wanneer de aanvaller de mogelijkheid heeft om het verkeer actief te beïnvloeden. Als het domein van de ontvanger een MTA-STS-beleid publiceert en de server van de afzender MTA-STS ondersteunt, wordt de e-mail alleen via een TLS-verbinding verzonden, alleen naar servers die door het beleid zijn gedefinieerd, en alleen met verificatie van het servercertificaat.

Waarom gedeeltelijk? MTA-STS werkt alleen als beide partijen deze standaard hebben geïmplementeerd, en MTA-STS beschermt niet tegen scenario's waarin een aanvaller een geldig domeincertificaat kan verkrijgen van een van de publieke CA's.

Hoe MTA-STS werkt

recipiënt

Configureert STARTTLS-ondersteuning met een geldig certificaat op de mailserver.
Publiceert het MTA-STS-beleid via HTTPS; voor publicatie wordt bijvoorbeeld een speciaal mta-sts-domein en een speciaal bekend pad gebruikt https://mta-sts.mail.ru/.well-known/mta-sts.txt. Het beleid bevat een lijst met mailservers (mx) die het recht hebben om mail voor dit domein te ontvangen.
Publiceert een speciaal TXT-record _mta-sts in DNS met de beleidsversie. Wanneer het beleid verandert, moet deze invoer worden bijgewerkt (dit geeft aan dat de afzender het beleid opnieuw moet opvragen). Bijvoorbeeld, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Afzender

De afzender vraagt het _mta-sts DNS-record op en doet, indien beschikbaar, een beleidsverzoek via HTTPS (waarbij het certificaat wordt gecontroleerd). Het resulterende beleid wordt in de cache opgeslagen (voor het geval een aanvaller de toegang daartoe blokkeert of de DNS-record vervalst).

Bij het versturen van post wordt gecontroleerd of:

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

Voordelen van MTA-STS

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

Nadelen van MTA-STS

Het is noodzakelijk om de geldigheid van het web- en mailservercertificaat, de correspondentie van namen en tijdige verlenging te controleren. Problemen met het certificaat hebben tot gevolg dat post niet kan worden afgeleverd.

Aan de afzenderzijde is een MTA met ondersteuning voor MTA-STS-beleid vereist; momenteel wordt MTA-STS niet standaard ondersteund in de MTA.

MTA-STS gebruikt een lijst met vertrouwde root-CA's.

MTA-STS beschermt niet tegen aanvallen waarbij de aanvaller een geldig certificaat gebruikt. In de meeste gevallen impliceert MitM nabij de server de mogelijkheid om een certificaat uit te geven. Een dergelijke aanval kan worden gedetecteerd met behulp van Certificate Transparency. Daarom beperkt MTA-STS in het algemeen de mogelijkheid van verkeersonderschepping, maar elimineert deze niet volledig.

De laatste twee punten maken MTA-STS minder veilig dan de concurrerende DANE-standaard voor SMTP (RFC 7672), maar technisch betrouwbaarder, d.w.z. voor MTA-STS is de kans klein dat de brief niet wordt afgeleverd vanwege technische problemen veroorzaakt door de implementatie van de standaard.

Concurrerende standaard - DANE

DANE gebruikt DNSSEC om certificaatinformatie te publiceren en vereist geen vertrouwen in externe certificeringsinstanties, wat veel veiliger is. Maar het gebruik van DNSSEC leidt aanzienlijk vaker tot technische storingen, zo blijkt uit statistieken over meerdere jaren gebruik (hoewel er over het algemeen een positieve trend is in de betrouwbaarheid van DNSSEC en de technische ondersteuning ervan). Om DANE in SMTP aan de ontvangerskant te implementeren is de aanwezigheid van DNSSEC voor de DNS-zone verplicht, en is correcte ondersteuning voor NSEC/NSEC3 essentieel voor DANE, waarmee er systemische problemen zijn in DNSSEC.

Als DNSSEC niet correct is geconfigureerd, kan dit leiden tot mislukte bezorging van e-mail als de verzendende kant DANE ondersteunt, zelfs als de ontvangende kant er niets van weet. Daarom zijn veel organisaties, ondanks het feit dat DANE een oudere en veiligere standaard is en al wordt ondersteund in sommige serversoftware aan de verzendzijde, in feite onbeduidend, niet klaar om deze te implementeren vanwege de noodzaak om DNSSEC te implementeren. dit heeft de implementatie van DANE al die jaren dat de standaard bestaat aanzienlijk vertraagd.

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

Hoe zit het met MTA-STS-ondersteuning in Mail.ru Mail?

Mail.ru publiceert al geruime tijd een MTA-STS-beleid voor alle grote domeinen. Momenteel zijn we bezig met de implementatie van het clientgedeelte van de standaard. Op het moment van schrijven wordt het beleid toegepast in een niet-blokkerende modus (als de bezorging wordt geblokkeerd door een beleid, wordt de brief afgeleverd via een “reserve” server zonder beleid toe te passen), waarna de blokkeermodus voor een klein deel wordt geforceerd van uitgaand SMTP-verkeer zal dit geleidelijk voor 100% van het verkeer het geval zijn. Handhaving van beleid wordt ondersteund.

Wie ondersteunt de standaard nog meer?

Tot nu toe publiceert het MTA-STS-beleid ongeveer 0.05% van de actieve domeinen, maar toch beschermt het al een groot volume aan e-mailverkeer, omdat De standaard wordt ondersteund door grote spelers: Google, Comcast en deels Verizon (AOL, Yahoo). Veel andere postdiensten hebben aangekondigd dat ondersteuning voor de standaard in de nabije toekomst zal worden geïmplementeerd.

Welke invloed zal dit op mij hebben?

Tenzij uw domein een MTA-STS-beleid publiceert. Als u het beleid publiceert, zijn e-mails voor gebruikers van uw mailserver beter beschermd tegen onderschepping.

Hoe implementeer ik MTA-STS?

MTA-STS-ondersteuning aan de ontvangende kant

Het volstaat om het beleid te publiceren via HTTPS en records in DNS, een geldig certificaat van een van de vertrouwde CA's te configureren (laten we coderen is mogelijk) voor STARTTLS in de MTA (STARTTLS wordt ondersteund in alle moderne MTA's), geen speciale ondersteuning van de MTA is vereist.

Stap voor stap ziet het er als volgt uit:

Configureer STARTTLS in de MTA die u gebruikt (postfix, exim, sendmail, Microsoft Exchange, etc.).
Zorg ervoor dat u een geldig certificaat gebruikt (uitgegeven door een vertrouwde CA, niet verlopen, het onderwerp van het certificaat komt overeen met de MX-record die e-mail bezorgt voor uw domein).
Configureer een TLS-RPT-record waarmee beleidstoepassingsrapporten worden geleverd (door services die het verzenden van TLS-rapporten ondersteunen). Voorbeeldinvoer (voor het domein example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Dit item geeft afzenders van e-mail de opdracht om statistische rapporten over TLS-gebruik in SMTP naar te sturen [email protected].

Houd de rapporten enkele dagen in de gaten om er zeker van te zijn dat er geen fouten zijn.
Publiceer het MTA-STS-beleid via HTTPS. Het beleid wordt gepubliceerd als tekstbestand met CRLF-regelafsluitingen per locatie.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Voorbeeld beleid:
```
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 (momenteel STSv1), Modus stelt de beleidstoepassingsmodus in, testen - testmodus (het beleid wordt niet toegepast), afdwingen - "gevechts" -modus. Publiceer eerst het beleid met modus: testen, als er geen problemen zijn met het beleid in de testmodus, kunt u na een tijdje overschakelen naar modus: afdwingen.

In mx wordt een lijst opgegeven van alle mailservers die mail voor uw domein kunnen accepteren (voor elke server moet een certificaat zijn geconfigureerd dat overeenkomt met de naam die is opgegeven in mx). Max_age specificeert de cachetijd van het beleid (zodra het onthouden beleid wordt toegepast, zelfs als de aanvaller de levering ervan blokkeert of de DNS-records corrumpeert tijdens de cachetijd, kunt u aangeven dat het beleid opnieuw moet worden aangevraagd door de mta-sts DNS te wijzigen dossier).
Publiceer een TXT-record in DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
In het id-veld kan een willekeurige identificatie (bijvoorbeeld een tijdstempel) worden gebruikt; wanneer het beleid verandert, moet dit ook veranderen. Hierdoor kunnen afzenders begrijpen dat ze het in de cache opgeslagen beleid opnieuw moeten aanvragen (als de identificatie anders is dan de één in de cache opgeslagen).

MTA-STS-ondersteuning aan de afzenderzijde

Tot nu toe gaat het slecht met haar, want... frisse standaard.

Exim - geen ingebouwde ondersteuning, er is een script van derden https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - er is geen ingebouwde ondersteuning, er is een script van derden dat in detail wordt beschreven op Habré https://habr.com/en/post/424961/

Als nawoord over “verplichte TLS”

De laatste tijd hebben toezichthouders aandacht besteed aan e-mailbeveiliging (en dat is maar goed ook). DMARC is bijvoorbeeld verplicht voor alle overheidsinstanties in de Verenigde Staten en wordt steeds vaker vereist in de financiële sector, waarbij de penetratie van de standaard in gereguleerde gebieden 90% bereikt. Nu eisen sommige toezichthouders de implementatie van “verplichte TLS” bij individuele domeinen, maar het mechanisme om “verplichte TLS” te garanderen is niet gedefinieerd en in de praktijk wordt deze instelling vaak geïmplementeerd op een manier die niet eens minimaal bescherming biedt tegen echte aanvallen die al plaatsvinden. voorzien in mechanismen zoals DANE of MTA-STS.

Als de toezichthouder de implementatie van “verplichte TLS” met afzonderlijke domeinen vereist, raden we aan MTA-STS of het gedeeltelijke analoog ervan als het meest geschikte mechanisme te beschouwen. Het elimineert de noodzaak om voor elk domein afzonderlijk beveiligde instellingen te maken. Als u problemen ondervindt bij het implementeren van het clientgedeelte van MTA-STS (totdat het protocol brede steun heeft gekregen, zal dit hoogstwaarschijnlijk het geval zijn), kunnen we deze aanpak aanbevelen:

Publiceer een MTA-STS-beleid en/of DANE-records (DANE heeft alleen zin als DNSSEC al is ingeschakeld voor uw domein, en MTA-STS in ieder geval), dit beschermt het verkeer in uw richting en elimineert de noodzaak om andere e-maildiensten te vragen om verplichte TLS voor uw domein te configureren als de mailservice MTA-STS en/of DANE al ondersteunt.
Voor grote e-maildiensten implementeert u een “analoog” van MTA-STS via afzonderlijke transportinstellingen voor elk domein, waardoor de MX wordt hersteld die wordt gebruikt voor het doorgeven van e-mail en waarvoor verplichte verificatie van een TLS-certificaat vereist is. Als de domeinen al een MTA-STS-beleid publiceren, kan dit waarschijnlijk pijnloos worden gedaan. Op zichzelf is het inschakelen van verplichte TLS voor een domein zonder de relais te repareren en het certificaat ervoor te verifiëren vanuit veiligheidsoogpunt ineffectief en voegt het niets toe aan de bestaande STARTTLS-mechanismen.

Bron: www.habr.com

Mail.ru mail begint MTA-STS-beleid toe te passen in de testmodus