Sa madaling salita, ang MTA-STS ay isang paraan upang higit pang maprotektahan ang mga email mula sa pagharang (ibig sabihin, man-in-the-middle attacks aka MitM) kapag ipinadala sa pagitan ng mga mail server. Bahagyang nalulutas nito ang mga legacy na problema sa arkitektura ng mga protocol ng email at inilarawan sa medyo kamakailang pamantayang RFC 8461. Ang Mail.ru ay ang unang pangunahing serbisyo ng mail sa RuNet na nagpatupad ng pamantayang ito. At ito ay inilarawan nang mas detalyado sa ilalim ng hiwa.
Anong problema ang nalulutas ng MTA-STS?
Sa kasaysayan, ang mga protocol ng email (SMTP, POP3, IMAP) ay nagpapadala ng impormasyon sa malinaw na teksto, na naging posible na ma-intercept ito, halimbawa, kapag nag-access sa isang channel ng komunikasyon.
Ano ang hitsura ng mekanismo para sa paghahatid ng liham mula sa isang user patungo sa isa pa:
Sa kasaysayan, posible ang pag-atake ng MitM sa lahat ng lugar kung saan kumakalat ang mail.
Ang RFC 8314 ay nangangailangan ng paggamit ng TLS sa pagitan ng mail user application (MUA) at ng mail server. Kung ang iyong server at ang mga mail application na iyong ginagamit ay sumusunod sa RFC 8314, kung gayon ay inalis mo na (karamihan) ang posibilidad ng Man-in-the-Middle na pag-atake sa pagitan ng user at ng mga mail server.
Ang pagsunod sa mga karaniwang tinatanggap na kasanayan (ipinamantandaan ng RFC 8314) ay nag-aalis ng pag-atake malapit sa user:
Sumunod ang mga mail server ng Mail.ru sa RFC 8314 bago pa man gamitin ang pamantayan; sa katunayan, nakukuha lang nito ang mga tinanggap na kasanayan, at hindi na namin kailangang i-configure ang anumang karagdagang. Ngunit, kung pinapayagan pa rin ng iyong mail server ang mga user na gumagamit ng mga hindi secure na protocol, tiyaking ipatupad ang mga rekomendasyon ng pamantayang ito, dahil Malamang, hindi bababa sa ilan sa iyong mga user ang gumagana sa mail nang walang pag-encrypt, kahit na sinusuportahan mo ito.
Palaging gumagana ang mail client sa parehong mail server ng parehong organisasyon. At maaari mong pilitin ang lahat ng user na kumonekta sa isang secure na paraan, at pagkatapos ay gawin itong teknikal na imposible para sa mga hindi secure na user na kumonekta (ito mismo ang nangangailangan ng RFC 8314). Ito ay minsan mahirap, ngunit magagawa. Ang trapiko sa pagitan ng mga mail server ay mas kumplikado pa rin. Ang mga server ay nabibilang sa iba't ibang organisasyon at kadalasang ginagamit sa mode na "set and forget", na ginagawang imposibleng lumipat sa isang secure na protocol nang sabay-sabay nang hindi nasira ang koneksyon. Matagal nang ibinigay ng SMTP ang STARTTLS extension, na nagpapahintulot sa mga server na sumusuporta sa pag-encrypt na lumipat sa TLS. Ngunit ang isang umaatake na may kakayahang impluwensyahan ang trapiko ay maaaring "magputol" ng impormasyon tungkol sa suporta para sa command na ito at pilitin ang mga server na makipag-usap gamit ang isang plain text protocol (ang tinatawag na downgrade attack). Para sa parehong dahilan, karaniwang hindi sinusuri ng STARTTLS ang bisa ng sertipiko (ang hindi pinagkakatiwalaang sertipiko ay maaaring maprotektahan laban sa mga passive na pag-atake, at ito ay hindi mas masama kaysa sa pagpapadala ng mensahe sa malinaw na teksto). Samakatuwid, pinoprotektahan lamang ng STARTTLS laban sa passive eavesdropping.
Bahagyang inaalis ng MTA-STS ang problema ng pagharang ng mga titik sa pagitan ng mga mail server, kapag ang umaatake ay may kakayahang aktibong maimpluwensyahan ang trapiko. Kung ang domain ng tatanggap ay nag-publish ng isang patakaran sa MTA-STS at ang server ng nagpadala ay sumusuporta sa MTA-STS, ipapadala lamang nito ang email sa pamamagitan ng isang koneksyon sa TLS, sa mga server lamang na tinukoy ng patakaran, at sa pag-verify lamang ng certificate ng server.
Bakit bahagyang? Gumagana lamang ang MTA-STS kung ang parehong partido ay nag-ingat na ipatupad ang pamantayang ito, at hindi nagpoprotekta ang MTA-STS laban sa mga sitwasyon kung saan ang isang umaatake ay makakakuha ng wastong sertipiko ng domain mula sa isa sa mga pampublikong CA.
Paano gumagana ang MTA-STS
tumatanggap
- Kino-configure ang suporta ng STARTTLS na may wastong certificate sa mail server.
- Ini-publish ang patakaran ng MTA-STS sa pamamagitan ng HTTPS; isang espesyal na domain ng mta-sts at isang espesyal na kilalang path ang ginagamit para sa paglalathala, halimbawa
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Ang patakaran ay naglalaman ng isang listahan ng mga mail server (mx) na may karapatang tumanggap ng mail para sa domain na ito. - Nagpa-publish ng espesyal na TXT record _mta-sts sa DNS na may bersyon ng patakaran. Kapag nagbago ang patakaran, dapat na ma-update ang entry na ito (ito ay nagpapahiwatig sa nagpadala na muling i-query ang patakaran). Halimbawa,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Nagpadala
Hinihiling ng nagpadala ang _mta-sts DNS record, at kung available ito, gagawa ng kahilingan sa patakaran sa pamamagitan ng HTTPS (pagsusuri sa certificate). Naka-cache ang resultang patakaran (kung sakaling harangan ng attacker ang access dito o madaya ang DNS record).
Kapag nagpapadala ng mail, sinusuri na:
- ang server kung saan inihahatid ang mail ay nasa patakaran;
- tumatanggap ang server ng mail gamit ang TLS (STARTTLS) at may valid na certificate.
Mga kalamangan ng MTA-STS
Gumagamit ang MTA-STS ng mga teknolohiyang ipinapatupad na sa karamihan ng mga organisasyon (SMTP+STARTTLS, HTTPS, DNS). Para sa pagpapatupad sa panig ng tatanggap, walang espesyal na suporta sa software para sa pamantayan ang kinakailangan.
Mga disadvantages ng MTA-STS
Kinakailangang subaybayan ang bisa ng sertipiko ng web at mail server, ang pagsusulatan ng mga pangalan, at napapanahong pag-renew. Ang mga problema sa sertipiko ay magreresulta sa mail na hindi maihatid.
Sa panig ng nagpadala, isang MTA na may suporta para sa mga patakaran ng MTA-STS ay kinakailangan; sa kasalukuyan, ang MTA-STS ay hindi suportado out of the box sa MTA.
Gumagamit ang MTA-STS ng listahan ng mga pinagkakatiwalaang root CA.
Ang MTA-STS ay hindi nagpoprotekta laban sa mga pag-atake kung saan ang umaatake ay gumagamit ng wastong sertipiko. Sa karamihan ng mga kaso, ang MitM malapit sa server ay nagpapahiwatig ng kakayahang mag-isyu ng isang sertipiko. Maaaring matukoy ang naturang pag-atake gamit ang Certificate Transparency. Samakatuwid, sa pangkalahatan, ang MTA-STS ay nagpapagaan, ngunit hindi ganap na nag-aalis, ang posibilidad ng pagharang ng trapiko.
Ang huling dalawang puntos ay ginagawang mas ligtas ang MTA-STS kaysa sa nakikipagkumpitensyang pamantayan ng DANE para sa SMTP (RFC 7672), ngunit mas maaasahan sa teknikal, i.e. para sa MTA-STS ay may mababang posibilidad na ang sulat ay hindi maihatid dahil sa mga teknikal na problema na dulot ng pagpapatupad ng pamantayan.
Kakumpitensyang pamantayan - DANE
Gumagamit ang DANE ng DNSSEC para mag-publish ng impormasyon ng certificate at hindi nangangailangan ng tiwala sa mga external na awtoridad sa certificate, na mas secure. Ngunit ang paggamit ng DNSSEC ay mas madalas na humahantong sa mga teknikal na pagkabigo, batay sa mga istatistika sa loob ng ilang taon ng paggamit (bagama't sa pangkalahatan ay may positibong kalakaran sa pagiging maaasahan ng DNSSEC at ang teknikal na suporta nito). Upang ipatupad ang DANE sa SMTP sa panig ng tatanggap, ang pagkakaroon ng DNSSEC para sa DNS zone ay sapilitan, at ang tamang suporta para sa NSEC/NSEC3 ay mahalaga para sa DANE, kung saan mayroong mga sistematikong problema sa DNSSEC.
Kung ang DNSSEC ay hindi na-configure nang tama, maaari itong magresulta sa mga pagkabigo sa paghahatid ng mail kung ang panig ng pagpapadala ay sumusuporta sa DANE, kahit na ang tumatanggap na bahagi ay walang alam tungkol dito. Samakatuwid, sa kabila ng katotohanan na ang DANE ay isang mas matanda at mas ligtas na pamantayan at suportado na sa ilang software ng server sa panig ng nagpadala, sa katunayan ang pagtagos nito ay nananatiling hindi gaanong mahalaga, maraming mga organisasyon ang hindi handang ipatupad ito dahil sa pangangailangang ipatupad ang DNSSEC, ito ay makabuluhang nagpabagal sa pagpapatupad ng DANE sa lahat ng mga taon na ang pamantayan ay umiral.
Ang DANE at MTA-STS ay hindi nagkakasalungatan sa isa't isa at maaaring gamitin nang magkasama.
Ano ang mayroon sa suporta ng MTA-STS sa Mail.ru Mail?
Ang Mail.ru ay naglalathala ng isang patakaran ng MTA-STS para sa lahat ng mga pangunahing domain sa loob ng mahabang panahon. Kasalukuyan naming ipinapatupad ang bahagi ng kliyente ng pamantayan. Sa oras ng pagsulat, ang mga patakaran ay inilalapat sa isang non-blocking mode (kung ang paghahatid ay naharang ng isang patakaran, ang sulat ay ihahatid sa pamamagitan ng isang "reserbang" server nang hindi nag-aaplay ng mga patakaran), pagkatapos ay ang blocking mode ay sapilitang para sa isang maliit na bahagi ng papalabas na trapiko ng SMTP, unti-unti para sa 100% ng trapiko ito ay Susuportahan ang pagpapatupad ng mga patakaran.
Sino pa ang sumusuporta sa pamantayan?
Sa ngayon, ang mga patakaran ng MTA-STS ay nagpa-publish ng humigit-kumulang 0.05% ng mga aktibong domain, ngunit, gayunpaman, pinoprotektahan na nila ang isang malaking dami ng trapiko ng mail, dahil Ang pamantayan ay sinusuportahan ng mga pangunahing manlalaro - Google, Comcast at bahagyang Verizon (AOL, Yahoo). Maraming iba pang serbisyo sa koreo ang nagpahayag na ang suporta para sa pamantayan ay ipapatupad sa malapit na hinaharap.
Paano ito makakaapekto sa akin?
Hindi maliban kung ang iyong domain ay nag-publish ng isang patakaran sa MTA-STS. Kung ipa-publish mo ang patakaran, ang mga email para sa mga user ng iyong mail server ay mas mapoprotektahan mula sa pagharang.
Paano ko ipapatupad ang MTA-STS?
Suporta sa MTA-STS sa panig ng tatanggap
Sapat na i-publish ang patakaran sa pamamagitan ng HTTPS at mga tala sa DNS, i-configure ang isang wastong certificate mula sa isa sa mga pinagkakatiwalaang CA (Posible ang pag-encrypt natin) para sa STARTTLS sa MTA (Ang STARTTLS ay suportado sa lahat ng modernong MTA), walang espesyal na suporta mula sa Kinakailangan ang MTA.
Hakbang sa hakbang, ganito ang hitsura:
- I-configure ang STARTTLS sa MTA na iyong ginagamit (postfix, exim, sendmail, Microsoft Exchange, atbp.).
- Tiyaking gumagamit ka ng wastong certificate (na ibinigay ng isang pinagkakatiwalaang CA, hindi nag-expire, ang paksa ng certificate ay tumutugma sa MX record na naghahatid ng mail para sa iyong domain).
- Mag-configure ng TLS-RPT record kung saan ihahatid ang mga ulat sa application ng patakaran (sa pamamagitan ng mga serbisyong sumusuporta sa pagpapadala ng mga ulat sa TLS). Halimbawang entry (para sa example.com na domain):
smtp._tls.example.com. 300 IN TXT Β«v=TLSRPTv1;rua=mailto:[email protected]Β»Ang entry na ito ay nagtuturo sa mga nagpapadala ng mail na magpadala ng mga istatistikal na ulat sa paggamit ng TLS sa SMTP sa
[email protected].Subaybayan ang mga ulat sa loob ng ilang araw upang matiyak na walang mga error.
- I-publish ang patakaran ng MTA-STS sa HTTPS. Ang patakaran ay na-publish bilang isang text file na may CRLF line terminator ayon sa lokasyon.
https://mta-sts.example.com/.well-known/mta-sts.txtHalimbawang patakaran:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Ang field ng bersyon ay naglalaman ng bersyon ng patakaran (kasalukuyang
STSv1), Itinatakda ng Mode ang mode ng aplikasyon ng patakaran, pagsubok β mode ng pagsubok (hindi inilapat ang patakaran), ipatupad β mode na "labanan". I-publish muna ang patakaran gamit ang mode: testing, kung walang mga problema sa patakaran sa test mode, pagkaraan ng ilang sandali maaari kang lumipat sa mode: enforce.Sa mx, ang isang listahan ng lahat ng mga mail server na maaaring tumanggap ng mail para sa iyong domain ay tinukoy (ang bawat server ay dapat na may naka-configure na sertipiko na tumutugma sa pangalang tinukoy sa mx). Tinukoy ng Max_age ang oras ng pag-cache ng patakaran (sa sandaling mailapat ang natatandaang patakaran kahit na i-block ng attacker ang paghahatid nito o sirain ang mga DNS record sa oras ng pag-cache, maaari mong ipahiwatig ang pangangailangang hilingin muli ang patakaran sa pamamagitan ng pagpapalit ng mta-sts DNS tala).
- Mag-publish ng TXT record sa DNS:
_mta-sts.example.com. TXT βv=STS1; id=someid;βMaaaring gumamit ng arbitrary identifier (halimbawa, timestamp) sa field ng id; kapag nagbago ang patakaran, dapat itong magbago, binibigyang-daan nito ang mga nagpadala na maunawaan na kailangan nilang muling hilingin ang naka-cache na patakaran (kung iba ang identifier sa naka-cache ang isa).
Suporta sa MTA-STS sa panig ng nagpadala
Sa ngayon ay masama sa kanya, dahil... bagong pamantayan.
- Exim - walang built-in na suporta, mayroong isang third-party na script
- Postfix - walang built-in na suporta, mayroong isang third-party na script na inilarawan nang detalyado sa HabrΓ©
Bilang isang afterword tungkol sa "mandatory TLS"
Kamakailan lamang, binibigyang pansin ng mga regulator ang seguridad ng email (at iyon ay isang magandang bagay). Halimbawa, mandatory ang DMARC para sa lahat ng ahensya ng gobyerno sa United States at lalong kinakailangan sa sektor ng pananalapi, na may penetration ng standard na umaabot sa 90% sa mga regulated na lugar. Ngayon, ang ilang mga regulator ay nangangailangan ng pagpapatupad ng "mandatory TLS" na may mga indibidwal na domain, ngunit ang mekanismo para sa pagtiyak na "mandatory TLS" ay hindi tinukoy at sa pagsasanay ang setting na ito ay madalas na ipinapatupad sa paraang hindi kahit na hindi gaanong nagpoprotekta laban sa mga tunay na pag-atake na mayroon na. na ibinigay sa mga mekanismo tulad ng DANE o MTA-STS.
Kung ang regulator ay nangangailangan ng pagpapatupad ng "mandatory TLS" na may hiwalay na mga domain, inirerekomenda namin na isaalang-alang ang MTA-STS o ang bahagyang analogue nito bilang ang pinaka-angkop na mekanismo, inaalis nito ang pangangailangan na gumawa ng mga secure na setting para sa bawat domain nang hiwalay. Kung nahihirapan kang ipatupad ang bahagi ng kliyente ng MTA-STS (hanggang ang protocol ay nakatanggap ng malawakang suporta, malamang na gagawin nila), maaari naming irekomenda ang diskarteng ito:
- Mag-publish ng patakaran ng MTA-STS at/o mga tala ng DANE (makatuwiran lang ang DANE kung naka-enable na ang DNSSEC para sa iyong domain, at MTA-STS sa anumang kaso), poprotektahan nito ang trapiko sa iyong direksyon at aalisin ang pangangailangang magtanong sa iba pang mga serbisyo ng mail upang i-configure ang mandatoryong TLS para sa iyong domain kung sinusuportahan na ng serbisyo ng mail ang MTA-STS at/o DANE.
- Para sa malalaking serbisyo ng email, magpatupad ng "analogue" ng MTA-STS sa pamamagitan ng hiwalay na mga setting ng transportasyon para sa bawat domain, na aayusin ang MX na ginagamit para sa pag-relay ng mail at mangangailangan ng mandatoryong pag-verify ng TLS certificate para dito. Kung nag-publish na ang mga domain ng patakaran sa MTA-STS, malamang na magagawa ito nang walang sakit. Sa sarili nito, ang pagpapagana ng mandatoryong TLS para sa isang domain nang hindi inaayos ang relay at pagbe-verify ng certificate para dito ay hindi epektibo mula sa isang panseguridad na pananaw at hindi nagdaragdag ng anuman sa umiiral na mga mekanismo ng STARTTLS.
Pinagmulan: www.habr.com