Mallonge, MTA-STS estas maniero por plue protekti retpoŝtojn kontraŭ interkapto (t.e., man-en-la-mezaj atakoj alinome MitM) kiam transdonitaj inter poŝtserviloj. Ĝi parte solvas la heredajn arkitekturajn problemojn de retpoŝtaj protokoloj kaj estas priskribita en la relative lastatempa normo RFC 8461. Mail.ru estas la unua grava poŝtservo en la RuNet se temas pri efektivigi ĉi tiun normon. Kaj ĝi estas priskribita pli detale sub la tranĉo.

Kiun problemon solvas MTA-STS?

Historie retpoŝtaj protokoloj (SMTP, POP3, IMAP) transdonis informojn en klara teksto, kio ebligis ĝin interkapti, ekzemple, alirante komunikan kanalon.

Kiel aspektas la mekanismo por transdoni leteron de unu uzanto al alia:

Historie, MitM-atako estis ebla en ĉiuj lokoj kie poŝto cirkulas.

RFC 8314 postulas la uzon de TLS inter la poŝta uzantaplikaĵo (MUA) kaj la poŝtservilo. Se via servilo kaj la poŝtaplikoj, kiujn vi uzas, konformas al RFC 8314, tiam vi (plejparte) forigis la eblecon de Man-en-la-mezo-atakoj inter la uzanto kaj la poŝtserviloj.

Sekvi ĝenerale akceptitajn praktikojn (normigitajn fare de RFC 8314) eliminas la atakon proksime de la uzanto:

Mail.ru poŝtserviloj plenumis RFC 8314 eĉ antaŭ ol la normo estis adoptita; fakte, ĝi simple kaptas jam akceptitajn praktikojn, kaj ni ne devis agordi ion kroman. Sed, se via poŝtservilo ankoraŭ permesas uzantojn uzi nesekurajn protokolojn, nepre efektivigu la rekomendojn de ĉi tiu normo, ĉar Plej verŝajne, almenaŭ kelkaj el viaj uzantoj laboras kun poŝto sen ĉifrado, eĉ se vi subtenas ĝin.

La poŝtokliento ĉiam funkcias kun la sama poŝtservilo de la sama organizo. Kaj vi povas devigi ĉiujn uzantojn konekti en sekura maniero, kaj poste igi ĝin teknike malebla por ne-sekuraj uzantoj konektiĝi (ĝuste tio postulas RFC 8314). Ĉi tio foje estas malfacila, sed farebla. Trafiko inter poŝtserviloj estas ankoraŭ pli komplika. Serviloj apartenas al malsamaj organizoj kaj ofte estas uzataj en "agordu kaj forgesu" reĝimo, kio malebligas tuj ŝanĝi al sekura protokolo sen rompi konekteblecon. SMTP longe disponigis la STARTTLS etendon, kiu permesas al serviloj kiuj subtenas ĉifradon ŝanĝi al TLS. Sed atakanto, kiu havas la kapablon influi trafikon, povas "eltranĉi" informojn pri subteno por ĉi tiu komando kaj devigi la servilojn komuniki uzante klartekstan protokolon (la tielnomita malsupera atako). Pro la sama kialo, STARTTLS kutime ne kontrolas la validecon de la atestilo (nefidinda atestilo povas protekti kontraŭ pasivaj atakoj, kaj ĉi tio ne estas pli malbona ol sendi mesaĝon en klara teksto). Tial STARTTLS nur protektas kontraŭ pasiva subaŭskultado.

MTA-STS parte forigas la problemon de kaptado de leteroj inter poŝtserviloj, kiam la atakanto havas la kapablon aktive influi trafikon. Se la domajno de la ricevanto publikigas MTA-STS-politikon kaj la servilo de la sendinto subtenas MTA-STS, ĝi nur sendos la retpoŝton per TLS-konekto, nur al serviloj difinitaj de la politiko, kaj nur kun konfirmo de la atestilo de la servilo.

Kial parte? MTA-STS funkcias nur se ambaŭ partioj zorgis efektivigi ĉi tiun normon, kaj MTA-STS ne protektas kontraŭ scenaroj en kiuj atakanto povas akiri validan domajnan atestilon de unu el la publikaj CAs.

Kiel MTA-STS funkcias

Ricevanto

Agordas STARTTLS-subtenon kun valida atestilo sur la poŝtservilo.
Eldonas la politikon de MTA-STS per HTTPS; speciala mta-sts-domajno kaj speciala konata vojo estas uzataj por publikigo, ekzemple https://mta-sts.mail.ru/.well-known/mta-sts.txt. La politiko enhavas liston de poŝtserviloj (mx) kiuj havas la rajton ricevi poŝton por ĉi tiu domajno.
Eldonas specialan TXT-rekordon _mta-sts en DNS kun la politika versio. Kiam la politiko ŝanĝiĝas, ĉi tiu eniro devas esti ĝisdatigita (ĉi tio signalas al la sendinto redemandi la politikon). Ekzemple, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Sendanto

La sendinto petas la _mta-sts DNS-rekordon, kaj se ĝi estas disponebla, faras politikan peton per HTTPS (kontrolante la atestilon). La rezulta politiko estas kaŝmemorigita (kaze atakanto blokas aliron al ĝi aŭ falsigas la DNS-rekordon).

Sendante poŝton, oni kontrolas, ke:

la servilo al kiu poŝto estas liverita estas en la politiko;
la servilo akceptas poŝton per TLS (STARTTLS) kaj havas validan atestilon.

Avantaĝoj de MTA-STS

MTA-STS uzas teknologiojn kiuj jam estas efektivigitaj en plej multaj organizoj (SMTP+STARTTLS, HTTPS, DNS). Por efektivigo ĉe la ricevanto, neniu speciala softvarsubteno por la normo estas bezonata.

Malavantaĝoj de MTA-STS

Necesas kontroli la validecon de la atestilo pri ret- kaj poŝtservilo, la korespondado de nomoj kaj ĝustatempa renovigo. Problemoj kun la atestilo kaŭzos ke poŝto ne povos esti liverita.

Ĉe la sendinto, MTA kun subteno por MTA-STS-politikoj estas postulata; nuntempe, MTA-STS ne estas subtenata el la kesto en la MTA.

MTA-STS uzas liston de fidindaj radikaj CAoj.

MTA-STS ne protektas kontraŭ atakoj en kiuj la atakanto uzas validan atestilon. Plejofte, MitM proksime de la servilo implicas la kapablon eldoni atestilon. Tia atako povas esti detektita uzante Certificate Transparency. Tial, ĝenerale, MTA-STS mildigas, sed ne tute forigas, la eblecon de trafika interkapto.

La lastaj du punktoj faras MTA-STS malpli sekura ol la konkuranta DANE-normo por SMTP (RFC 7672), sed pli teknike fidinda, t.e. por MTA-STS estas malalta probablo ke la letero ne estos liverita pro teknikaj problemoj kaŭzitaj de la efektivigo de la normo.

Konkuranta normo - DANE

DANE uzas DNSSEC por publikigi atestilinformojn kaj ne postulas fidon je eksteraj atestaj aŭtoritatoj, kio estas multe pli sekura. Sed la uzo de DNSSEC signife pli ofte kondukas al teknikaj misfunkciadoj, surbaze de statistiko dum pluraj jaroj da uzo (kvankam ĝenerale estas pozitiva tendenco en la fidindeco de DNSSEC kaj ĝia teknika subteno). Por efektivigi DANE en SMTP ĉe la ricevanto, la ĉeesto de DNSSEC por la DNS-zono estas deviga, kaj ĝusta subteno por NSEC/NSEC3 estas esenca por DANE, kun kiu ekzistas ĉieaj problemoj en DNSSEC.

Se DNSSEC ne estas agordita ĝuste, ĝi povas rezultigi poŝtajn liverajn fiaskojn se la sendanta flanko subtenas DANE, eĉ se la ricevanta flanko scias nenion pri ĝi. Tial, malgraŭ la fakto, ke DANE estas pli malnova kaj pli sekura normo kaj jam estas subtenata en iu servila programaro ĉe la sendinto, fakte ĝia penetrado restas sensignifa, multaj organizoj ne pretas efektivigi ĝin pro la bezono efektivigi DNSSEC, tio signife bremsis la efektivigon de DANE ĉiujn tiujn jarojn ke la normo ekzistis.

DANE kaj MTA-STS ne konfliktas unu kun la alia kaj povas esti uzataj kune.

Kio estas kun MTA-STS-subteno en Mail.ru Mail?

Mail.ru publikigas MTA-STS-politikon por ĉiuj ĉefaj domajnoj dum sufiĉe da tempo. Ni nuntempe efektivigas la klientan parton de la normo. En la momento de skribado, politikoj estas aplikataj en ne-bloka reĝimo (se livero estas blokita de politiko, la letero estos liverita per "rezerva" servilo sen aplikado de politikoj), tiam bloka reĝimo estos devigita por malgranda parto. de eksiĝinta SMTP-trafiko, iom post iom por 100% de trafiko ĝi estos Devigo de politikoj estas subtenata.

Kiu alia subtenas la normon?

Ĝis nun, MTA-STS-politikoj publikigas proksimume 0.05% de aktivaj domajnoj, sed, tamen, ili jam protektas grandan volumon de poŝta trafiko, ĉar La normo estas subtenata de ĉefaj ludantoj - Google, Comcast kaj parte Verizon (AOL, Yahoo). Multaj aliaj poŝtaj servoj anoncis, ke subteno por la normo estos efektivigita en proksima estonteco.

Kiel ĉi tio influos min?

Ne krom se via domajno publikigas politikon de MTA-STS. Se vi publikigas la politikon, retpoŝtoj por uzantoj de via poŝtservilo estos pli bone protektitaj kontraŭ interkapto.

Kiel mi efektivigas MTA-STS?

MTA-STS-subteno ĉe la ricevanto

Sufiĉas publikigi la politikon per HTTPS kaj rekordoj en DNS, agordi validan atestilon de unu el la fidindaj CA (Ni ĉifri eblas) por STARTTLS en la MTA (STARTTLS estas subtenata en ĉiuj modernaj MTA), neniu speciala subteno de la MTA estas postulata.

Paŝo post paŝo, ĝi aspektas jene:

Agordu STARTTLS en la MTA, kiun vi uzas (postfikso, eksim, sendmail, Microsoft Exchange, ktp.).
Certiĝu, ke vi uzas validan atestilon (eldonitan de fidinda CA, ne eksvalidiĝinta, la temo de la atestilo kongruas kun la MX-rekordo, kiu liveras poŝton por via domajno).
Agordu TLS-RPT-rekordon per kiu raportoj pri politikaj aplikaĵoj estos liveritaj (per servoj, kiuj subtenas sendi TLS-raportojn). Ekzempla eniro (por la domajno example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Ĉi tiu eniro instrukcias poŝtsendantojn sendi statistikajn raportojn pri TLS-uzado en SMTP al [email protected].

Monitoru la raportojn dum pluraj tagoj por certigi, ke ne estas eraroj.
Publikigi la politikon de MTA-STS per HTTPS. La politiko estas publikigita kiel tekstdosiero kun CRLF-liniaj finaĵoj laŭ loko.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Ekzempla politiko:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
La versio-kampo enhavas la version de la politiko (nuntempe STSv1), Reĝimo fiksas la politikan aplikan reĝimon, testadon — provan reĝimon (la politiko ne estas aplikata), devigi — "batala" reĝimo. Unue publikigu la politikon kun reĝimo: testado, se ne estas problemoj kun la politiko en testreĝimo, post iom da tempo vi povas ŝanĝi al reĝimo: devigi.

En mx, listo de ĉiuj poŝtserviloj kiuj povas akcepti poŝton por via domajno estas specifita (ĉiu servilo devas havi atestilon agordita kiu kongruas kun la nomo specifita en mx). Max_age specifas la kaŝmemortempon de la politiko (post kiam la memorita politiko estos aplikita eĉ se la atakanto blokas ĝian liveron aŭ koruptas la DNS-rekordojn dum la kaŝmemortempo, vi povas signali la bezonon peti la politikon denove ŝanĝante la mta-sts DNS. rekordo).
Eldonu TXT-rekordon en DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Arbitra identigilo (ekzemple, tempomarko) povas esti uzita en la id-kampo; kiam la politiko ŝanĝiĝas, ĝi devus ŝanĝiĝi, tio permesas al sendintoj kompreni ke ili devas re-peti la kaŝmemorigitan politikon (se la identigilo estas diferenca de la kaŝmemorigita unu).

MTA-STS-subteno ĉe la sendinto

Ĝis nun ĝi estas malbone kun ŝi, ĉar... freŝa normo.

Exim - neniu enkonstruita subteno, ekzistas triaparta skripto https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfikso - ne ekzistas enkonstruita subteno, ekzistas triaparta skripto, kiu estas detale priskribita en Habré https://habr.com/en/post/424961/

Kiel postparolo pri "deviga TLS"

Lastatempe, regulistoj atentis retpoŝtan sekurecon (kaj tio estas bona). Ekzemple, DMARC estas deviga por ĉiuj registaraj agentejoj en Usono kaj estas ĉiam pli postulata en la financa sektoro, kun penetro de la normo atingante 90% en reguligitaj areoj. Nun iuj reguligistoj postulas la efektivigon de "deviga TLS" kun individuaj domajnoj, sed la mekanismo por certigi "deviga TLS" ne estas difinita kaj praktike ĉi tiu agordo ofte estas efektivigita en maniero, kiu eĉ ne minimume protektas kontraŭ realaj atakoj kiuj jam estas. provizite en mekanismoj kiel ekzemple DANE aŭ MTA-STS.

Se la reguligisto postulas la efektivigon de "deviga TLS" kun apartaj domajnoj, ni rekomendas konsideri MTA-STS aŭ ĝian partan analogon kiel la plej taŭgan mekanismon, ĝi forigas la bezonon fari sekurajn agordojn por ĉiu domajno aparte. Se vi havas malfacilaĵojn efektivigi la klientan parton de MTA-STS (ĝis la protokolo ricevis vastan subtenon, ili plej verŝajne faros), ni povas rekomendi ĉi tiun aliron:

Publikigi MTA-STS-politikon kaj/aŭ DANE-rekordojn (DANE havas sencon nur se DNSSEC jam estas ebligita por via domajno, kaj MTA-STS ĉiukaze), ĉi tio protektos trafikon en via direkto kaj forigos la bezonon peti aliajn retpoŝtajn servojn. por agordi devigan TLS por via domajno se la poŝta servo jam subtenas MTA-STS kaj/aŭ DANE.
Por grandaj retpoŝtaj servoj, efektivigu "analogon" de MTA-STS per apartaj transportaj agordoj por ĉiu domajno, kiu riparos la MX uzatan por poŝtsendado kaj postulos devigan konfirmon de TLS-atestilo por ĝi. Se la domajnoj jam publikigas MTA-STS-politikon, ĉi tio verŝajne povas esti farita sendolore. Per si mem, ebligi devigan TLS por domajno sen ripari la relajson kaj kontroli la atestilon por ĝi estas neefika de sekureca vidpunkto kaj ne aldonas ion al la ekzistantaj STARTTLS-mekanismoj.

fonto: www.habr.com

Mail.ru-poŝto komencas apliki MTA-STS-politikojn en prova reĝimo