Kuerz gesot, MTA-STS ass e Wee fir E-Maile weider ze schützen virun Offangen (dh Man-in-the-Middle Attacken aka MitM) wa se tëscht Mailserver iwwerdroe ginn. Et léist deelweis d'legacy architektonesch Problemer vun E-Mail-Protokoller a gëtt am relativ rezenten Standard RFC 8461 beschriwwen. Mail.ru ass den éischte grousse Mail Service op der RuNet fir dëse Standard ëmzesetzen. An et gëtt méi detailléiert ënner dem Schnëtt beschriwwen.
Wéi ee Problem léist MTA-STS?
Historesch hunn d'E-Mail-Protokoller (SMTP, POP3, IMAP) Informatioun a Kloertext iwwerdroen, wat et méiglech gemaach huet, se z'ënnerscheeden, zum Beispill beim Zougang zu engem Kommunikatiounskanal.
Wéi gesäit de Mechanismus aus fir e Bréif vun engem Benotzer op en aneren ze liwweren:
Historesch war e MitM Attack méiglech op alle Plazen wou d'Mail zirkuléiert.
RFC 8314 erfuerdert d'Benotzung vun TLS tëscht der Mail Benotzer Applikatioun (MUA) an dem Mail Server. Wann Äre Server an d'Mailapplikatiounen, déi Dir benotzt, mat RFC 8314 konform sinn, dann hutt Dir (gréisstendeels) d'Méiglechkeet vu Man-in-the-Middle Attacken tëscht dem Benotzer an de Mailserver eliminéiert.
Folgend allgemeng akzeptéiert Praktiken (standardiséiert vum RFC 8314) eliminéiert den Attack no beim Benotzer:
Mail.ru Mail Serveren entspriechen RFC 8314 och ier de Standard ugeholl gouf; Tatsächlech erfaasst et einfach schonn akzeptéiert Praktiken, a mir hunn näischt zousätzlech konfiguréieren. Awer wann Äre Mailserver ëmmer nach Benotzer erlaabt onsécher Protokoller ze benotzen, gitt sécher d'Empfehlungen vun dësem Standard ëmzesetzen, well Wahrscheinlech, op d'mannst e puer vun Äre Benotzer schaffen mat Mail ouni Verschlësselung, och wann Dir et ënnerstëtzt.
De Mail Client funktionnéiert ëmmer mam selwechte Mailserver vun der selwechter Organisatioun. An Dir kënnt all Benotzer zwéngen op eng sécher Manéier ze verbannen, an et dann technesch onméiglech maachen fir net-séchere Benotzer ze verbannen (dëst ass genau wat RFC 8314 erfuerdert). Dëst ass heiansdo schwéier, awer machbar. Den Traffic tëscht Mailserveren ass nach ëmmer méi komplizéiert. Serveren gehéieren zu verschiddenen Organisatiounen a ginn dacks an engem "Set a vergiessen" Modus benotzt, wat et onméiglech mécht op eemol op e séchere Protokoll ze wiesselen ouni d'Konnektivitéit ze briechen. SMTP huet laang d'STARTTLS Extensioun zur Verfügung gestallt, déi Serveren déi Verschlësselung ënnerstëtzen fir op TLS ze wiesselen. Awer en Ugräifer, deen d'Fäegkeet huet fir den Traffic ze beaflossen, kann Informatioun iwwer Ënnerstëtzung fir dëse Kommando "ausschneiden" an d'Server zwéngen fir mat engem Einfache Textprotokoll ze kommunizéieren (de sougenannte Downgrade Attack). Aus dem selwechte Grond iwwerpréift STARTTLS normalerweis net d'Gëltegkeet vum Zertifika (en net zouverléissege Certificat kann géint passiv Attacke schützen, an dëst ass net méi schlëmm wéi e Message am Kloertext ze schécken). Dofir schützt STARTTLS nëmme géint passiv Oflauschterskandal.
MTA-STS eliminéiert deelweis de Problem fir Bréiwer tëscht Mailserveren z'ënnerbriechen, wann den Ugräifer d'Fäegkeet huet den Traffic aktiv ze beaflossen. Wann d'Domain vum Empfänger eng MTA-STS-Politik publizéiert an de Server vum Sender MTA-STS ënnerstëtzt, schéckt se nëmmen d'E-Mail iwwer eng TLS-Verbindung, nëmmen op Serveren, déi vun der Politik definéiert sinn, an nëmme mat der Verifizéierung vum Serverzertifika.
Firwat deelweis? MTA-STS funktionnéiert nëmme wa béid Parteien sech oppassen fir dëse Standard ëmzesetzen, an MTA-STS schützt net géint Szenarien an deenen en Ugräifer fäeg ass e gëltege Domainzertifika vun engem vun den ëffentlechen CAs ze kréien.
Wéi funktionéiert MTA-STS
Den Empfänger
- Konfiguréiert STARTTLS Ënnerstëtzung mat engem valabel Certificat op der Mail Server.
- Verëffentlecht d'MTA-STS Politik iwwer HTTPS; e spezielle mta-sts Domain an e spezielle bekannte Wee gi fir d'Publikatioun benotzt, zum Beispill
https://mta-sts.mail.ru/.well-known/mta-sts.txt. D'Politik enthält eng Lëscht vu Mailserveren (mx) déi d'Recht hunn fir E-Mail fir dëst Domain ze kréien. - Verëffentlecht e speziellen TXT Rekord _mta-sts an DNS mat der Politik Versioun. Wann d'Politik ännert, muss dës Entrée aktualiséiert ginn (dëst signaliséiert de Sender fir d'Politik nei ze froen). Zum Beispill,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Sender
De Sender freet den _mta-sts DNS Rekord, a wann et verfügbar ass, mécht eng Politik Ufro iwwer HTTPS (iwwerpréift de Certificat). Déi doraus resultéierend Politik gëtt cache (am Fall wou en Ugräifer den Zougang dozou blockéiert oder den DNS-Rekord spooft).
Wann Dir E-Mail verschéckt, gëtt kontrolléiert datt:
- de Server op deen d'Mail geliwwert gëtt ass an der Politik;
- de Server akzeptéiert Mail mat TLS (STARTTLS) an huet e gültege Certificat.
Virdeeler vun MTA-STS
MTA-STS benotzt Technologien déi schonn an de meeschten Organisatiounen implementéiert sinn (SMTP + STARTTLS, HTTPS, DNS). Fir Implementatioun op der Empfänger Säit ass keng speziell Software Support fir de Standard erfuerderlech.
Nodeeler vun MTA-STS
Et ass néideg fir d'Gëltegkeet vum Web- a Mailserverzertifika ze iwwerwaachen, d'Korrespondenz vun den Nimm an d'rechtzäiteg Erneierung. Probleemer mam Zertifika féieren dozou datt d'Mail net geliwwert ka ginn.
Op der Sender Säit ass en MTA mat Ënnerstëtzung fir MTA-STS Politik erfuerderlech; Momentan gëtt MTA-STS net aus der Këscht an der MTA ënnerstëtzt.
MTA-STS benotzt eng Lëscht vu vertrauenswürdege Root CAs.
MTA-STS schützt net géint Attacken, an deenen den Ugräifer e gültege Certificat benotzt. An deene meeschte Fäll implizéiert MitM no beim Server d'Fäegkeet fir en Zertifika auszeginn. Esou en Attack kann mat Certificat Transparenz erkannt ginn. Dofir, am Allgemengen, reduzéiert MTA-STS, awer net komplett eliminéiert, d'Méiglechkeet vu Verkéiersinterceptioun.
Déi lescht zwee Punkte maachen MTA-STS manner sécher wéi de konkurréiere DANE Standard fir SMTP (RFC 7672), awer méi technesch zouverlässeg, d.h. fir MTA-STS gëtt et eng kleng Wahrscheinlechkeet datt de Bréif net geliwwert gëtt wéinst technesche Problemer, déi duerch d'Ëmsetzung vum Standard verursaacht ginn.
Konkurrenzstandard - DANE
DANE benotzt DNSSEC fir Zertifikatinformatioun ze verëffentlechen an erfuerdert kee Vertrauen an extern Zertifizéierungsautoritéiten, wat vill méi sécher ass. Awer d'Benotzung vun DNSSEC féiert wesentlech méi dacks zu technesche Feeler, baséiert op Statistiken iwwer e puer Joer Benotzung (obwuel et allgemeng e positiven Trend an der Zouverlässegkeet vun DNSSEC a senger technescher Ënnerstëtzung ass). Fir DANE an SMTP op der Empfänger Säit ëmzesetzen, ass d'Präsenz vun DNSSEC fir d'DNS Zone obligatoresch, a korrekt Ënnerstëtzung fir NSEC / NSEC3 ass essentiell fir DANE, mat deenen et systemesch Probleemer an DNSSEC sinn.
Wann DNSSEC net richteg konfiguréiert ass, kann et zu Mail Liwwerung Feeler Resultat wann d'Send Säit DANE ënnerstëtzt, och wann d'Empfang Säit näischt doriwwer weess. Dofir, trotz der Tatsaach, datt DANE en eelere a méi séchere Standard ass a schonn an e puer Serversoftware op der Sendersäit ënnerstëtzt gëtt, bleift tatsächlech seng Pénétratioun onbedeitend, vill Organisatiounen sinn net prett et ëmzesetzen wéinst der Bedierfnes fir DNSSEC ëmzesetzen, dëst huet d'Ëmsetzung vun DANE all déi Joeren datt de Standard existéiert däitlech verlangsamt.
DANE an MTA-STS Konflikt net mateneen a kënnen zesumme benotzt ginn.
Wat ass mat MTA-STS Ënnerstëtzung an Mail.ru Mail?
Mail.ru huet eng MTA-STS Politik fir all gréisser Domaine fir eng laang Zäit publizéiert. Mir implementéieren de Moment de Client Deel vum Standard. Zu der Zäit vum Schreiwen ginn d'Politik an engem net blockéierende Modus applizéiert (wann d'Liwwerung vun enger Politik blockéiert gëtt, gëtt de Bréif iwwer e "Ersatzstéck" Server geliwwert ouni Politiken anzebezéien), da gëtt de Blockmodus fir e klengen Deel gezwongen vum erausginn SMTP Traffic, lues a lues fir 100% vum Traffic wäert d'Ëmsetzung vu Politiken ënnerstëtzt ginn.
Wien soss ënnerstëtzt de Standard?
Bis elo publizéieren d'MTA-STS Politik ongeféier 0.05% vun den aktiven Domainen, awer trotzdem schützen se schonn e grousse Volumen vum Mailverkéier, well De Standard gëtt vu grousse Spiller ënnerstëtzt - Google, Comcast an deelweis Verizon (AOL, Yahoo). Vill aner Postservicer hunn ugekënnegt datt Ënnerstëtzung fir de Standard an der nächster Zukunft ëmgesat gëtt.
Wéi wäert dat mech beaflossen?
Net ausser wann Är Domain eng MTA-STS Politik publizéiert. Wann Dir d'Politik publizéiert, sinn E-Maile fir Benotzer vun Ärem Mail-Server besser geschützt vun der Interceptioun.
Wéi implementéieren ech MTA-STS?
MTA-STS Ënnerstëtzung op der Empfänger Säit
Et ass genuch fir d'Politik iwwer HTTPS a records an DNS ze verëffentlechen, e gültege Certificat vun engem vun de vertrauenswürdege CAs konfiguréieren (Loosst eis verschlësselen ass méiglech) fir STARTTLS am MTA (STARTTLS gëtt an all modernen MTAs ënnerstëtzt), keng speziell Ënnerstëtzung vun der MTA ass erfuerderlech.
Schrëtt fir Schrëtt gesäit et esou aus:
- Konfiguréieren STARTTLS an der MTA Dir benotzt (postfix, exim, sendmail, Microsoft Exchange, etc.).
- Vergewëssert Iech datt Dir e gëltege Certificat benotzt (ausgestallt vun engem vertrauenswürdege CA, net ofgelaaf, d'Thema vum Zertifika entsprécht dem MX-Rekord deen E-Mail fir Är Domain liwwert).
- Konfiguréiert en TLS-RPT-Rekord duerch deen d'Politikapplikatiounsberichter geliwwert ginn (vu Servicer déi d'Schécken vun TLS Berichter ënnerstëtzen). Beispill Entrée (fir den example.com Domain):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Dës Entrée instruéiert E-Mail Sender fir statistesch Berichter iwwer TLS Notzung am SMTP ze schécken
[email protected].Iwwerwaacht d'Rapporte fir e puer Deeg fir sécher ze sinn datt et keng Feeler gëtt.
- Verëffentlechen d'MTA-STS Politik iwwer HTTPS. D'Politik gëtt als Textdatei mat CRLF Linn Terminatoren no Standuert publizéiert.
https://mta-sts.example.com/.well-known/mta-sts.txtBeispill Politik:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400D'Versiounsfeld enthält d'Versioun vun der Politik (aktuell
STSv1), Modus setzt de Politikapplikatiounsmodus, Testen - Testmodus (d'Politik gëtt net ugewannt), erzwéngen - "Kampf" Modus. Éischt publizéieren d'Politik mam Modus: Testen, wann et keng Problemer mat der Politik am Testmodus gëtt, no enger Zäit kënnt Dir op Modus wiesselen: ëmsetzen.Am mx gëtt eng Lëscht vun alle Mailserveren spezifizéiert, déi E-Mail fir Ären Domain akzeptéiere kënnen (all Server muss e Certificat konfiguréiert hunn deen mam Numm an mx entsprécht). Max_age spezifizéiert d'Cachingzäit vun der Politik (wann déi erënnert Politik ugewannt gëtt, och wann den Ugräifer seng Liwwerung blockéiert oder d'DNS-Records während der Cache-Zäit korrupt, kënnt Dir d'Notwendegkeet signaliséieren d'Politik erëm ze froen andeems Dir d'mta-sts DNS ännert Rekord).
- Verëffentlechen en TXT Rekord an DNS:
_mta-sts.example.com. TXT “v=STS1; id=someid;”En arbiträren Identifizéierer (zum Beispill en Zäitstempel) kann am ID Feld benotzt ginn; wann d'Politik ännert, soll se änneren, dëst erlaabt d'Sendere ze verstoen datt se d'Cache-Politik erëm musse froen (wann den Identifizéierer anescht ass wéi een cache).
MTA-STS Ënnerstëtzung op der Sender Säit
Bis elo ass et schlecht mat hatt, well ... frësch Norm.
- Exim - keng agebauter Ënnerstëtzung, et gëtt en Drëtt Partei Skript
- Postfix - et gëtt keng agebauter Ënnerstëtzung, et gëtt en Drëtt Partei Skript deen am Detail op Habré beschriwwe gëtt
Als Afterword iwwer "obligatoresch TLS"
Zënter kuerzem hu Reguléierer op E-Mail Sécherheet opmierksam gemaach (an dat ass eng gutt Saach). Zum Beispill ass DMARC obligatoresch fir all Regierungsagenturen an den USA a gëtt ëmmer méi am Finanzsecteur erfuerderlech, mat Pénétratioun vum Standard erreecht 90% a geregelte Beräicher. Elo erfuerderen e puer Reguléierer d'Ëmsetzung vun "obligatoresche TLS" mat eenzelne Domainen, awer de Mechanismus fir "obligatoresch TLS" ze garantéieren ass net definéiert an an der Praxis gëtt dës Astellung dacks ëmgesat op eng Manéier déi net emol minimal schützt géint real Attacken déi scho sinn virgesinn a Mechanismen wéi DANE oder MTA-STS.
Wann de Reguléierer d'Ëmsetzung vun "obligatoresche TLS" mat getrennten Domainen erfuerdert, empfeelen mir MTA-STS oder seng partiell Analog als de gëeegente Mechanismus ze berücksichtegen, et eliminéiert d'Noutwendegkeet fir sécher Astellunge fir all Domain separat ze maachen. Wann Dir Schwieregkeeten hutt de Client Deel vun MTA-STS ëmzesetzen (bis de Protokoll verbreet Ënnerstëtzung kritt huet, wäerte se wahrscheinlech), kënne mir dës Approche recommandéieren:
- Verëffentlechen eng MTA-STS Politik an / oder DANE records (DANE mécht Sënn nëmmen wann DNSSEC scho fir Är Domain aktivéiert ass, an MTA-STS op jidde Fall), dëst wäert de Traffic an Ärer Richtung schützen an d'Noutwendegkeet eliminéieren aner Mail Servicer ze froen obligatoresch TLS fir Ären Domain ze konfiguréieren wann de Mail Service scho MTA-STS an/oder DANE ënnerstëtzt.
- Fir grouss E-Mail-Servicer, implementéiert en "Analog" vun MTA-STS duerch getrennten Transport-Astellunge fir all Domain, déi den MX fixéiert fir d'Mail-Relaising benotzt an eng obligatoresch Verifizéierung vun engem TLS-Zertifika dofir erfuerdert. Wann d'Domänen schonn eng MTA-STS Politik publizéieren, kann dëst wahrscheinlech schmerzlos gemaach ginn. Selwer, obligatoresch TLS fir en Domain z'aktivéieren ouni de Relais ze fixéieren an den Zertifika dofir z'iwwerpréiwen ass net effikass aus Sécherheetssiicht a füügt näischt un déi existent STARTTLS Mechanismen derbäi.
Source: will.com