En resum, MTA-STS és una manera de protegir encara més els correus electrònics de la intercepció (és a dir, els atacs man-in-the-middle també coneguts com MitM) quan es transmeten entre servidors de correu. Soluciona parcialment els problemes arquitectònics heretats dels protocols de correu electrònic i es descriu a l'estàndard relativament recent RFC 8461. Mail.ru és el primer servei de correu important de RuNet que implementa aquest estàndard. I es descriu amb més detall sota el tall.
Quin problema resol MTA-STS?
Històricament, els protocols de correu electrònic (SMTP, POP3, IMAP) transmetien informació en text clar, fet que permetia interceptar-la, per exemple, en accedir a un canal de comunicació.
Com és el mecanisme per enviar una carta d'un usuari a un altre:
Històricament, un atac MitM era possible a tots els llocs on circula el correu.
RFC 8314 requereix l'ús de TLS entre l'aplicació d'usuari de correu (MUA) i el servidor de correu. Si el vostre servidor i les aplicacions de correu que utilitzeu compleixen la RFC 8314, aleshores heu eliminat (en gran part) la possibilitat d'atacs Man-in-the-Middle entre l'usuari i els servidors de correu.
Seguir les pràctiques generalment acceptades (estandarditzades per RFC 8314) elimina l'atac a prop de l'usuari:
Els servidors de correu Mail.ru complien amb la RFC 8314 fins i tot abans que s'adoptés l'estàndard; de fet, simplement captura pràctiques ja acceptades i no hem hagut de configurar res addicional. Però, si el vostre servidor de correu encara permet als usuaris utilitzar protocols insegurs, assegureu-vos d'implementar les recomanacions d'aquest estàndard, perquè El més probable és que almenys alguns dels vostres usuaris treballin amb correu sense xifratge, fins i tot si el doneu suport.
El client de correu sempre treballa amb el mateix servidor de correu de la mateixa organització. I podeu forçar tots els usuaris a connectar-se de manera segura i, a continuació, fer que tècnicament sigui impossible que els usuaris no segurs es connectin (això és exactament el que requereix RFC 8314). Això de vegades és difícil, però factible. El trànsit entre servidors de correu és encara més complicat. Els servidors pertanyen a diferents organitzacions i sovint s'utilitzen en un mode "establir i oblidar", cosa que fa impossible canviar a un protocol segur alhora sense trencar la connectivitat. SMTP fa temps que proporciona l'extensió STARTTLS, que permet als servidors que admeten el xifratge canviar a TLS. Però un atacant que té la capacitat d'influir en el trànsit pot "retallar" la informació sobre el suport per a aquesta ordre i obligar els servidors a comunicar-se mitjançant un protocol de text sense format (l'anomenat atac de baixada de nivell). Per la mateixa raó, STARTTLS normalment no verifica la validesa del certificat (un certificat no fiable pot protegir contra atacs passius, i això no és pitjor que enviar un missatge en text clar). Per tant, STARTTLS només protegeix contra escoltes passives.
MTA-STS elimina parcialment el problema d'interceptar cartes entre servidors de correu, quan l'atacant té la capacitat d'influir activament en el trànsit. Si el domini del destinatari publica una política MTA-STS i el servidor del remitent admet MTA-STS, només enviarà el correu electrònic mitjançant una connexió TLS, només als servidors definits per la política i només amb la verificació del certificat del servidor.
Per què parcialment? MTA-STS només funciona si ambdues parts han tingut cura d'implementar aquest estàndard, i MTA-STS no protegeix contra escenaris en què un atacant pot obtenir un certificat de domini vàlid d'una de les CA públiques.
Com funciona MTA-STS
Destinatari
- Configura el suport STARTTLS amb un certificat vàlid al servidor de correu.
- Publica la política MTA-STS mitjançant HTTPS; per a la publicació s'utilitza un domini especial mta-sts i un camí especial conegut per a la publicació, per exemple
https://mta-sts.mail.ru/.well-known/mta-sts.txt. La política conté una llista de servidors de correu (mx) que tenen dret a rebre correu per a aquest domini. - Publica un registre TXT especial _mta-sts al DNS amb la versió de la política. Quan la política canvia, aquesta entrada s'ha d'actualitzar (això indica al remitent que torni a consultar la política). Per exemple,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Remitent
El remitent sol·licita el registre DNS _mta-sts i, si està disponible, fa una sol·licitud de política mitjançant HTTPS (comprovant el certificat). La política resultant s'emmagatzema a la memòria cau (en cas que un atacant hi bloquegi l'accés o falsifica el registre DNS).
Quan s'envia correu, es comprova que:
- el servidor al qual es lliura el correu es troba a la política;
- el servidor accepta correu mitjançant TLS (STARTTLS) i té un certificat vàlid.
Avantatges de MTA-STS
MTA-STS utilitza tecnologies que ja estan implementades a la majoria de les organitzacions (SMTP+STARTTLS, HTTPS, DNS). Per a la implementació al costat del destinatari, no es requereix cap suport de programari especial per a l'estàndard.
Inconvenients de MTA-STS
Cal controlar la validesa del certificat del servidor web i de correu, la correspondència de noms i la renovació oportuna. Els problemes amb el certificat provocaran que el correu no es pugui lliurar.
Pel que fa al remitent, cal un MTA amb suport per a polítiques MTA-STS; actualment, MTA-STS no és compatible amb l'MTA.
MTA-STS utilitza una llista de CA arrel de confiança.
MTA-STS no protegeix contra atacs en què l'atacant utilitza un certificat vàlid. En la majoria dels casos, MitM a prop del servidor implica la possibilitat d'emetre un certificat. Aquest atac es pot detectar mitjançant Certificate Transparency. Per tant, en general, MTA-STS mitiga, però no elimina completament, la possibilitat d'intercepció del trànsit.
Els dos últims punts fan que MTA-STS sigui menys segur que l'estàndard DANE competidor per a SMTP (RFC 7672), però més fiable tècnicament, és a dir. per a MTA-STS hi ha poca probabilitat que la carta no s'entregui a causa de problemes tècnics causats per la implementació de la norma.
Estàndard competitiu - DANE
DANE utilitza DNSSEC per publicar informació del certificat i no requereix confiança en autoritats de certificació externes, que és molt més segur. Però l'ús de DNSSEC molt més sovint condueix a fallades tècniques, basades en estadístiques durant diversos anys d'ús (tot i que generalment hi ha una tendència positiva en la fiabilitat de DNSSEC i el seu suport tècnic). Per implementar DANE a SMTP al costat del destinatari, és obligatòria la presència de DNSSEC per a la zona DNS, i el suport correcte de NSEC/NSEC3 és essencial per a DANE, amb el qual hi ha problemes sistèmics en DNSSEC.
Si DNSSEC no està configurat correctament, pot provocar errors en el lliurament del correu si el costat emissor admet DANE, fins i tot si el costat receptor no en sap res. Per tant, malgrat que DANE és un estàndard més antic i segur i que ja és compatible amb alguns programaris de servidor del costat del remitent, de fet, la seva penetració segueix sent insignificant, moltes organitzacions no estan preparades per implementar-lo a causa de la necessitat d'implementar DNSSEC, això ha alentit significativament la implantació de DANE tots aquests anys que ha existit l'estàndard.
DANE i MTA-STS no entren en conflicte i es poden utilitzar junts.
Què hi ha amb el suport MTA-STS a Mail.ru Mail?
Mail.ru fa força temps que publica una política MTA-STS per a tots els dominis principals. Actualment estem implementant la part client de l'estàndard. En el moment d'escriure, les polítiques s'apliquen en un mode sense bloqueig (si el lliurament està bloquejat per una política, la carta s'enviarà a través d'un servidor "de recanvi" sense aplicar polítiques), llavors el mode de bloqueig es forçarà en una petita part. del trànsit SMTP de sortida, gradualment per al 100% del trànsit s'admet l'aplicació de polítiques.
Qui més admet l'estàndard?
Fins ara, les polítiques MTA-STS publiquen aproximadament el 0.05% dels dominis actius, però, tanmateix, ja protegeixen un gran volum de trànsit de correu, perquè L'estàndard és compatible amb els principals jugadors: Google, Comcast i en part Verizon (AOL, Yahoo). Molts altres serveis postals han anunciat que el suport per a l'estàndard s'implementarà en un futur proper.
Com m'afectarà això?
No tret que el vostre domini publiqui una política MTA-STS. Si publiqueu la política, els correus electrònics dels usuaris del vostre servidor de correu estaran millor protegits de la intercepció.
Com implemento MTA-STS?
Suport MTA-STS al costat del destinatari
N'hi ha prou amb publicar la política mitjançant HTTPS i registres en DNS, configurar un certificat vàlid d'una de les CA de confiança (és possible xifrar) per a STARTTLS a l'MTA (STARTTLS és compatible amb tots els MTA moderns), sense suport especial per part de la Es requereix MTA.
Pas a pas, es veu així:
- Configureu STARTTLS a l'MTA que feu servir (postfix, exim, sendmail, Microsoft Exchange, etc.).
- Assegureu-vos que feu servir un certificat vàlid (emès per una CA de confiança, no caducat, l'assumpte del certificat coincideix amb el registre MX que lliura el correu per al vostre domini).
- Configureu un registre TLS-RPT a través del qual es lliuraran els informes d'aplicació de polítiques (mitjançant serveis que admeten l'enviament d'informes TLS). Exemple d'entrada (per al domini example.com):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Aquesta entrada indica als remitents de correu que enviïn informes estadístics sobre l'ús de TLS a SMTP
[email protected].Superviseu els informes durant diversos dies per assegurar-vos que no hi hagi errors.
- Publiqueu la política MTA-STS mitjançant HTTPS. La política es publica com a fitxer de text amb terminadors de línia CRLF per ubicació.
https://mta-sts.example.com/.well-known/mta-sts.txtPolítica d'exemple:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400El camp de versió conté la versió de la política (actualment
STSv1), Mode estableix el mode d'aplicació de la política, testing — mode de prova (la política no s'aplica), enforce — mode “combat”. Primer publiqueu la política amb mode: prova, si no hi ha problemes amb la política en mode prova, al cap d'un temps podeu canviar al mode: aplica.A mx, s'especifica una llista de tots els servidors de correu que poden acceptar correu per al vostre domini (cada servidor ha de tenir un certificat configurat que coincideixi amb el nom especificat a mx). Max_age especifica el temps d'emmagatzematge a la memòria cau de la política (un cop s'aplicarà la política recordada fins i tot si l'atacant bloqueja el seu lliurament o corromp els registres DNS durant el temps d'emmagatzematge a la memòria cau, podeu indicar la necessitat de sol·licitar la política de nou canviant el DNS mta-sts). registre).
- Publicar un registre TXT al DNS:
_mta-sts.example.com. TXT “v=STS1; id=someid;”Es pot utilitzar un identificador arbitrari (per exemple, una marca de temps) al camp d'identificació; quan la política canvia, hauria de canviar, això permet als remitents entendre que han de tornar a sol·licitar la política de la memòria cau (si l'identificador és diferent del guardat en memòria cau).
Suport MTA-STS al costat del remitent
Fins ara està malament amb ella, perquè... estàndard fresc.
- Exim: no hi ha suport integrat, hi ha un script de tercers
- Postfix: no hi ha suport integrat, hi ha un script de tercers que es descriu detalladament a Habré
Com a epílogo sobre "TLS obligatori"
Darrerament, els reguladors han prestat atenció a la seguretat del correu electrònic (i això és bo). Per exemple, DMARC és obligatori per a totes les agències governamentals dels Estats Units i cada cop és més requerit en el sector financer, amb una penetració de l'estàndard que arriba al 90% a les àrees regulades. Ara alguns reguladors requereixen la implementació de "TLS obligatori" amb dominis individuals, però el mecanisme per garantir que "TLS obligatori" no està definit i, a la pràctica, aquest paràmetre sovint s'implementa d'una manera que ni tan sols protegeix mínimament contra atacs reals que ja són. previst en mecanismes com DANE o MTA-STS.
Si el regulador requereix la implementació de "TLS obligatori" amb dominis separats, recomanem considerar MTA-STS o el seu anàleg parcial com el mecanisme més adequat, elimina la necessitat de fer paràmetres segurs per a cada domini per separat. Si teniu dificultats per implementar la part client de MTA-STS (fins que el protocol no hagi rebut un suport generalitzat, probablement ho faran), podem recomanar aquest enfocament:
- Publiceu una política MTA-STS i/o registres DANE (DANE només té sentit si DNSSEC ja està habilitat per al vostre domini, i MTA-STS en qualsevol cas), això protegirà el trànsit en la vostra direcció i eliminarà la necessitat de demanar altres serveis de correu electrònic. per configurar TLS obligatori per al vostre domini si el servei de correu ja és compatible amb MTA-STS i/o DANE.
- Per a serveis de correu electrònic grans, implementeu un "analògic" de MTA-STS mitjançant una configuració de transport independent per a cada domini, que solucionarà el MX utilitzat per a la retransmissió de correu i requerirà la verificació obligatòria d'un certificat TLS per a aquest. Si els dominis ja publiquen una política MTA-STS, és probable que això es faci sense dolor. Per si mateix, habilitar TLS obligatori per a un domini sense arreglar el relé i verificar-ne el certificat és ineficaç des del punt de vista de la seguretat i no afegeix res als mecanismes STARTTLS existents.
Font: www.habr.com