Sa laktod nga pagkasulti, ang MTA-STS usa ka paagi aron mapanalipdan pa ang mga email gikan sa interception (ie, man-in-the-middle attacks aka MitM) kung ipasa sa mga mail server. Gisulbad niini ang bahin sa mga problema sa arkitektura nga kabilin sa mga protocol sa email ug gihulagway sa medyo bag-o nga sumbanan nga RFC 8461. Ang Mail.ru mao ang una nga mayor nga serbisyo sa mail sa RuNet nga nagpatuman niini nga sumbanan. Ug kini gihulagway sa mas detalyado ubos sa pagputol.

Unsang problema ang nasulbad sa MTA-STS?

Sa kasaysayan, ang mga protocol sa email (SMTP, POP3, IMAP) nagpadala sa impormasyon sa tin-aw nga teksto, nga nagpaposible sa pag-intercept niini, pananglitan, sa pag-access sa usa ka channel sa komunikasyon.

Unsa ang hitsura sa mekanismo sa paghatud sa usa ka sulat gikan sa usa ka tiggamit ngadto sa lain:

Sa kasaysayan, ang usa ka pag-atake sa MitM posible sa tanang dapit diin ang mail nag-circulate.

Ang RFC 8314 nagkinahanglan sa paggamit sa TLS tali sa mail user application (MUA) ug sa mail server. Kung ang imong server ug ang mga aplikasyon sa mail nga imong gigamit nagsunod sa RFC 8314, nan imong (kadaghanan) giwagtang ang posibilidad sa mga pag-atake sa Man-in-the-Middle tali sa tiggamit ug sa mga mail server.

Ang pagsunod sa kasagarang gidawat nga mga gawi (gi-standardize sa RFC 8314) nagwagtang sa pag-atake duol sa tiggamit:

Ang mga mail server sa Mail.ru nagsunod sa RFC 8314 bisan sa wala pa gisagop ang sumbanan; sa tinuud, nakuha ra niini ang gidawat na nga mga gawi, ug wala na namon kinahanglan nga i-configure ang bisan unsang dugang. Apan, kung gitugotan gihapon sa imong mail server ang mga tiggamit gamit ang dili sigurado nga mga protocol, siguruha nga ipatuman ang mga rekomendasyon sa kini nga sumbanan, tungod kay Lagmit, labing menos pipila sa imong mga tiggamit nagtrabaho uban ang mail nga walay encryption, bisan kung gisuportahan nimo kini.

Ang mail client kanunay nga nagtrabaho sa parehas nga mail server sa parehas nga organisasyon. Ug mahimo nimong pugson ang tanan nga mga tiggamit sa pagkonektar sa usa ka luwas nga paagi, ug dayon himoon nga teknikal nga imposible alang sa dili luwas nga mga tiggamit sa pagkonektar (kini mao gayud ang gikinahanglan sa RFC 8314). Kini usahay lisud, apan mahimo. Ang trapiko tali sa mga mail server mas komplikado pa. Ang mga server nahisakop sa lain-laing mga organisasyon ug sagad gigamit sa usa ka "set and forget" mode, nga naghimo niini nga imposible nga mobalhin sa usa ka luwas nga protocol sa makausa nga dili maputol ang koneksyon. Ang SMTP dugay nang naghatag sa STARTTLS extension, nga nagtugot sa mga server nga nagsuporta sa encryption nga mobalhin sa TLS. Apan ang usa ka tig-atake nga adunay katakus sa pag-impluwensya sa trapiko mahimong "magputol" sa kasayuran bahin sa suporta alang niini nga mando ug pugson ang mga server nga makigkomunikar gamit ang usa ka yano nga protocol sa text (ang gitawag nga pag-atake sa downgrade). Sa samang rason, ang STARTTLS kasagaran dili magsusi sa kabalido sa sertipiko (ang dili kasaligan nga sertipiko makapanalipod batok sa pasibo nga mga pag-atake, ug kini dili mas grabe kay sa pagpadala og mensahe sa tin-aw nga teksto). Busa, ang STARTTLS nanalipod lamang batok sa passive eavesdropping.

Ang MTA-STS partially nagwagtang sa problema sa pag-intercept sa mga sulat tali sa mga mail server, kung ang tig-atake adunay abilidad sa aktibong pag-impluwensya sa trapiko. Kung ang domain sa tigdawat nagpatik sa usa ka palisiya sa MTA-STS ug ang server sa nagpadala nagsuporta sa MTA-STS, ipadala lang ang email sa usa ka koneksyon sa TLS, sa mga server ra nga gipasabut sa palisiya, ug adunay pag-verify sa sertipiko sa server.

Nganong partially? Ang MTA-STS molihok lang kung ang duha ka partido nag-amping sa pagpatuman niini nga sumbanan, ug ang MTA-STS dili manalipod batok sa mga sitwasyon diin ang usa ka tig-atake makakuha og balido nga domain certificate gikan sa usa sa mga publikong CA.

Giunsa paglihok ang MTA-STS

Dawata

Gi-configure ang suporta sa STARTTLS nga adunay balido nga sertipiko sa mail server.
Gipatik ang palisiya sa MTA-STS pinaagi sa HTTPS; usa ka espesyal nga domain sa mta-sts ug usa ka espesyal nga nailhan nga agianan gigamit alang sa pagmantala, pananglitan https://mta-sts.mail.ru/.well-known/mta-sts.txt. Ang polisiya naglangkob sa usa ka lista sa mga mail server (mx) nga adunay katungod sa pagdawat sa mail alang niini nga domain.
Nagpatik ug espesyal nga TXT record _mta-sts sa DNS nga adunay bersyon sa polisiya. Kung magbag-o ang palisiya, kini nga entry kinahanglan nga ma-update (kini nagpahibalo sa nagpadala sa pagpangutana pag-usab sa palisiya). Pananglitan, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Nagpadala

Ang nagpadala naghangyo sa _mta-sts DNS nga rekord, ug kon kini anaa, mohimo ug polisiya nga hangyo pinaagi sa HTTPS (pagsusi sa sertipiko). Ang resulta nga polisiya gi-cache (kung ang usa ka tig-atake mobabag sa pag-access niini o mag-spoof sa DNS record).

Sa pagpadala sa mail, gisusi nga:

ang server diin ipadala ang mail naa sa palisiya;
ang server modawat ug mail gamit ang TLS (STARTTLS) ug adunay balido nga sertipiko.

Mga bentaha sa MTA-STS

Ang MTA-STS naggamit sa mga teknolohiya nga gipatuman na sa kadaghanan sa mga organisasyon (SMTP+STARTTLS, HTTPS, DNS). Alang sa pagpatuman sa bahin sa nakadawat, walay espesyal nga suporta sa software alang sa sumbanan ang gikinahanglan.

Mga disbentaha sa MTA-STS

Kinahanglan nga bantayan ang kabalido sa sertipiko sa web ug mail server, ang mga sulat sa mga ngalan, ug tukma sa panahon nga pagbag-o. Ang mga problema sa sertipiko moresulta sa mail nga dili mahatud.

Sa bahin sa nagpadala, gikinahanglan ang MTA nga adunay suporta sa mga polisiya sa MTA-STS; sa pagkakaron, ang MTA-STS wala gisuportahan sa gawas sa kahon sa MTA.

Ang MTA-STS naggamit ug listahan sa mga kasaligang root CAs.

Ang MTA-STS wala manalipod batok sa mga pag-atake diin ang tig-atake naggamit ug balido nga sertipiko. Sa kasagaran nga mga kaso, ang MitM duol sa server nagpasabot sa abilidad sa pag-isyu og sertipiko. Ang ingon nga pag-atake mahimong mahibal-an gamit ang Certificate Transparency. Busa, sa kinatibuk-an, ang MTA-STS nagpagaan, apan dili hingpit nga nagwagtang, ang posibilidad sa interception sa trapiko.

Ang katapusan nga duha ka mga punto naghimo sa MTA-STS nga dili kaayo luwas kaysa sa nakigkompetensya nga sumbanan sa DANE alang sa SMTP (RFC 7672), apan mas kasaligan sa teknikal, i.e. alang sa MTA-STS adunay gamay nga posibilidad nga ang sulat dili mahatag tungod sa teknikal nga mga problema tungod sa pagpatuman sa sumbanan.

Estandard sa kompetisyon - DANE

Ang DANE naggamit sa DNSSEC sa pagmantala sa impormasyon sa sertipiko ug wala magkinahanglan og pagsalig sa mga awtoridad sa gawas nga sertipiko, nga mas luwas. Apan ang paggamit sa DNSSEC labi ka sagad nga hinungdan sa mga kapakyasan sa teknikal, pinasukad sa mga estadistika sa daghang mga tuig nga paggamit (bisan kung sa kasagaran adunay usa ka positibo nga uso sa kasaligan sa DNSSEC ug ang teknikal nga suporta niini). Aron ipatuman ang DANE sa SMTP sa nakadawat nga bahin, ang presensya sa DNSSEC alang sa DNS zone gikinahanglan, ug ang husto nga suporta alang sa NSEC/NSEC3 kinahanglanon alang sa DANE, diin adunay mga sistematikong problema sa DNSSEC.

Kung ang DNSSEC wala ma-configure sa husto, kini mahimong moresulta sa mga kapakyasan sa pagpadala sa mail kung ang nagpadala nga bahin nagsuporta sa DANE, bisan kung ang nakadawat nga bahin wala’y nahibal-an bahin niini. Busa, bisan pa sa kamatuoran nga ang DANE usa ka mas tigulang ug mas luwas nga sumbanan ug gisuportahan na sa pipila ka server software sa nagpadala nga bahin, sa pagkatinuod ang penetration niini nagpabilin nga dili importante, daghang mga organisasyon ang dili andam sa pagpatuman niini tungod sa panginahanglan sa pagpatuman sa DNSSEC, kini sa kamahinungdanon nagpahinay sa pagpatuman sa DANE sa tanan nga mga tuig nga ang sumbanan naglungtad.

Ang DANE ug MTA-STS dili magkasumpaki sa usag usa ug mahimong gamiton nga magkauban.

Unsa man ang suporta sa MTA-STS sa Mail.ru Mail?

Ang Mail.ru dugay nang nagpatik ug polisiya sa MTA-STS para sa tanang dagkong dominyo. Kami karon nagpatuman sa kliyente nga bahin sa sumbanan. Sa panahon sa pagsulat, ang mga palisiya gipadapat sa usa ka non-blocking mode (kung ang pagpadala gibabagan sa usa ka palisiya, ang sulat ipadala pinaagi sa usa ka "spare" nga server nga wala mag-apply sa mga palisiya), unya ang blocking mode mapugos sa gamay nga bahin. sa outgoing SMTP traffic, anam-anam alang sa 100% sa trapiko kini Pagpatuman sa mga palisiya gisuportahan.

Kinsa pa ang nagsuporta sa sumbanan?

Sa pagkakaron, ang mga polisiya sa MTA-STS nagpatik sa gibana-bana nga 0.05% sa mga aktibong domain, apan, bisan pa niana, nanalipod na sila sa daghang gidaghanon sa trapiko sa koreo, tungod kay Ang sumbanan gisuportahan sa mga dagkong magdudula - Google, Comcast ug bahin sa Verizon (AOL, Yahoo). Daghang uban pang mga serbisyo sa koreyo ang nagpahibalo nga ang suporta alang sa sumbanan ipatuman sa umaabot nga umaabot.

Unsay epekto niini kanako?

Dili gawas kung ang imong domain nagpatik sa usa ka palisiya sa MTA-STS. Kung imong imantala ang polisiya, ang mga email alang sa mga tiggamit sa imong mail server mas mapanalipdan gikan sa interception.

Unsaon nako pagpatuman ang MTA-STS?

Ang suporta sa MTA-STS sa nakadawat nga bahin

Igo na ang pagmantala sa polisiya pinaagi sa HTTPS ug mga rekord sa DNS, pag-configure og balido nga sertipiko gikan sa usa sa mga kasaligang CA (Posible ang pag-encrypt) para sa STARTTLS sa MTA (Ang STARTTLS gisuportahan sa tanang modernong MTA), walay espesyal nga suporta gikan sa Kinahanglan ang MTA.

Lakang sa lakang, kini ingon niini:

I-configure ang STARTTLS sa MTA nga imong gigamit (postfix, exim, sendmail, Microsoft Exchange, ug uban pa).
Siguruha nga naggamit ka usa ka balido nga sertipiko (gi-isyu sa usa ka kasaligan nga CA, wala ma-expire, ang hilisgutan sa sertipiko nahiangay sa rekord sa MX nga naghatud sa mail alang sa imong domain).
I-configure ang usa ka TLS-RPT nga rekord diin ang mga taho sa aplikasyon sa palisiya ipadala (sa mga serbisyo nga nagsuporta sa pagpadala sa mga taho sa TLS). Pananglitan nga entry (alang sa example.com domain):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Kini nga entry nagmando sa mga nagpadala sa mail sa pagpadala sa istatistikal nga mga taho sa paggamit sa TLS sa SMTP ngadto sa [email protected].

Pag-monitor sa mga taho sulod sa daghang mga adlaw aron masiguro nga wala’y mga sayup.
Imantala ang polisiya sa MTA-STS sa HTTPS. Ang polisiya gimantala isip text file nga adunay CRLF line terminators sa lokasyon.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Pananglitan nga polisiya:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Ang natad sa bersyon naglangkob sa bersyon sa palisiya (karon STSv1), Gitakda sa mode ang mode sa aplikasyon sa palisiya, pagsulay — mode sa pagsulay (wala gipadapat ang palisiya), gipatuman — mode nga "combat". Una nga imantala ang palisiya nga adunay mode: pagsulay, kung wala’y mga problema sa palisiya sa mode sa pagsulay, pagkahuman mahimo ka magbalhin sa mode: ipatuman.

Sa mx, usa ka lista sa tanan nga mail server nga makadawat ug mail para sa imong domain gitakda (matag server kinahanglan adunay usa ka sertipiko nga gi-configure nga mohaum sa ngalan nga gitakda sa mx). Gitino sa Max_age ang oras sa pag-cache sa polisiya (sa higayon nga ang nahinumduman nga palisiya magamit bisan kung ang tig-atake nag-block sa pagpadala niini o nagdaot sa mga rekord sa DNS sa panahon sa pag-cache, mahimo nimong ipahibalo ang panginahanglan sa paghangyo pag-usab sa palisiya pinaagi sa pagbag-o sa mta-sts DNS rekord).
Imantala ang TXT record sa DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Mahimo nimong gamiton ang usa ka arbitraryong identifier (pananglitan, usa ka timestamp) sa natad sa id; kung ang palisiya magbag-o, kinahanglan kini magbag-o, kini nagtugot sa mga nagpadala nga masabtan nga kinahanglan nila nga hangyoon pag-usab ang naka-cache nga palisiya (kung ang identifier lahi sa usa nga naka-cache).

Suporta sa MTA-STS sa kilid sa nagpadala

Sa pagkakaron dili maayo kaniya, tungod kay ... bag-o nga sumbanan.

Exim - walay built-in nga suporta, adunay usa ka third-party nga script https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - walay built-in nga suporta, adunay ikatulo nga partido nga script nga gihulagway sa detalye sa Habré https://habr.com/en/post/424961/

Ingon usa ka pagkahuman bahin sa "mandatory TLS"

Karong bag-o, ang mga regulator naghatag pagtagad sa seguridad sa email (ug kana usa ka maayong butang). Pananglitan, ang DMARC mao ang mandatory alang sa tanan nga mga ahensya sa gobyerno sa Estados Unidos ug mas gikinahanglan sa pinansyal nga sektor, uban sa penetration sa standard nga moabot sa 90% sa regulated nga mga dapit. Karon ang pipila ka mga regulators nagkinahanglan sa pagpatuman sa "mandatory TLS" uban sa tagsa-tagsa nga mga domain, apan ang mekanismo sa pagsiguro nga "mandatory TLS" wala gihubit ug sa praktis kini nga setting sa kasagaran gipatuman sa usa ka paagi nga dili bisan gamay nga pagpanalipod batok sa tinuod nga mga pag-atake nga na. gihatag sa mga mekanismo sama sa DANE o MTA-STS.

Kung gikinahanglan sa regulator ang pagpatuman sa "mandatory TLS" nga adunay bulag nga mga dominyo, among girekomendar nga ikonsiderar ang MTA-STS o ang partial analogue niini isip labing angay nga mekanismo, kini nagwagtang sa panginahanglan sa paghimo sa luwas nga mga setting alang sa matag domain nga gilain. Kung adunay ka mga kalisud sa pagpatuman sa bahin sa kliyente sa MTA-STS (hangtud nga ang protocol nakadawat sa kaylap nga suporta, lagmit mahimo nila), mahimo namon nga irekomenda kini nga pamaagi:

Imantala ang polisiya sa MTA-STS ug/o mga rekord sa DANE (ang DANE makahuluganon lang kung ang DNSSEC na-enable na para sa imong domain, ug ang MTA-STS sa bisan unsang kaso), kini makapanalipod sa trapiko sa imong direksyon ug magwagtang sa panginahanglan sa pagpangutana sa ubang mga serbisyo sa mail aron ma-configure ang mandatory TLS para sa imong domain kung ang serbisyo sa mail nagsuporta na sa MTA-STS ug/o DANE.
Alang sa dagkong mga serbisyo sa email, ipatuman ang usa ka "analogue" sa MTA-STS pinaagi sa bulag nga mga setting sa transportasyon alang sa matag domain, nga mag-ayo sa MX nga gigamit alang sa pagpadala sa mail ug magkinahanglan og mandatory nga pag-verify sa usa ka sertipiko sa TLS alang niini. Kung ang mga dominyo nagpatik na ug usa ka polisiya sa MTA-STS, lagmit mahimo kini nga walay sakit. Sa iyang kaugalingon, ang pagpagana sa mandatory nga TLS alang sa usa ka domain nga walay pag-ayo sa relay ug pag-verify sa sertipiko alang niini dili epektibo gikan sa usa ka punto sa seguridad ug dili makadugang bisan unsa sa kasamtangan nga mga mekanismo sa STARTTLS.

Source: www.habr.com

Ang Mail.ru mail nagsugod sa paggamit sa mga palisiya sa MTA-STS sa test mode