Kwa kifupi, MTA-STS ni njia ya kulinda zaidi barua pepe dhidi ya kutekwa (yaani, mashambulizi ya mtu-kati-kati aka MitM) yanapotumwa kati ya seva za barua. Inasuluhisha kwa sehemu matatizo ya usanifu wa urithi wa itifaki za barua pepe na inaelezwa katika kiwango cha hivi karibuni cha RFC 8461. Mail.ru ni huduma kuu ya kwanza ya barua kwenye RuNet kutekeleza kiwango hiki. Na inaelezwa kwa undani zaidi chini ya kukata.

Je, MTA-STS hutatua tatizo gani?

Kwa kihistoria, itifaki za barua pepe (SMTP, POP3, IMAP) zilisambaza habari kwa maandishi wazi, ambayo ilifanya iwezekane kuikata, kwa mfano, wakati wa kufikia njia ya mawasiliano.

Utaratibu wa kuwasilisha barua kutoka kwa mtumiaji mmoja hadi mwingine unaonekanaje:

Kihistoria, shambulio la MitM liliwezekana katika maeneo yote ambapo barua huzunguka.

RFC 8314 inahitaji matumizi ya TLS kati ya programu ya mtumiaji wa barua (MUA) na seva ya barua. Ikiwa seva yako na programu za barua unazotumia zinatii RFC 8314, basi (kwa kiasi kikubwa) umeondoa uwezekano wa mashambulizi ya Man-in-the-Middle kati ya mtumiaji na seva za barua.

Kufuata mazoea yanayokubalika kwa jumla (yaliyosanifiwa na RFC 8314) huondoa shambulio karibu na mtumiaji:

Seva za barua za Mail.ru zilitii RFC 8314 hata kabla ya kupitishwa kwa kiwango; kwa kweli, inanasa mazoea ambayo tayari yamekubaliwa, na hatukulazimika kusanidi chochote cha ziada. Lakini, ikiwa seva yako ya barua bado inaruhusu watumiaji kutumia itifaki zisizo salama, hakikisha kutekeleza mapendekezo ya kiwango hiki, kwa sababu. Uwezekano mkubwa zaidi, angalau baadhi ya watumiaji wako hufanya kazi na barua bila usimbaji fiche, hata kama unaitumia.

Mteja wa barua kila wakati hufanya kazi na seva ya barua sawa ya shirika moja. Na unaweza kulazimisha watumiaji wote kuunganishwa kwa njia salama, na kisha kuifanya kuwa haiwezekani kiufundi kwa watumiaji wasio salama kuunganisha (hii ndiyo hasa RFC 8314 inahitaji). Hii wakati mwingine ni ngumu, lakini inawezekana. Trafiki kati ya seva za barua bado ni ngumu zaidi. Seva ni za mashirika tofauti na mara nyingi hutumiwa katika hali ya "kuweka na kusahau", ambayo inafanya kuwa haiwezekani kubadili itifaki salama mara moja bila kuvunja muunganisho. SMTP imetoa kiendelezi cha STARTTLS kwa muda mrefu, ambacho huruhusu seva zinazotumia usimbaji fiche kubadili hadi TLS. Lakini mshambulizi ambaye ana uwezo wa kuathiri trafiki anaweza "kukata" habari kuhusu usaidizi wa amri hii na kulazimisha seva kuwasiliana kwa kutumia itifaki ya maandishi wazi (kinachojulikana kuwa mashambulizi ya chini). Kwa sababu hiyo hiyo, STARTTLS kwa kawaida haiangalii uhalali wa cheti (cheti kisichoaminika kinaweza kulinda dhidi ya mashambulizi ya kupita kiasi, na hii sio mbaya zaidi kuliko kutuma ujumbe kwa maandishi wazi). Kwa hivyo, STARTTLS hulinda dhidi ya usikilizaji tu.

MTA-STS huondoa kwa sehemu shida ya kuingilia barua kati ya seva za barua, wakati mshambuliaji ana uwezo wa kushawishi trafiki kikamilifu. Ikiwa kikoa cha mpokeaji kitachapisha sera ya MTA-STS na seva ya mtumaji inatumia MTA-STS, itatuma barua pepe kupitia muunganisho wa TLS pekee, kwa seva zilizobainishwa na sera pekee, na kwa uthibitishaji wa cheti cha seva pekee.

Kwa nini kwa kiasi? MTA-STS hufanya kazi tu ikiwa wahusika wote wamechukua tahadhari kutekeleza kiwango hiki, na MTA-STS hailinde dhidi ya hali ambazo mvamizi anaweza kupata cheti halali cha kikoa kutoka kwa mojawapo ya CA za umma.

Jinsi MTA-STS inavyofanya kazi

mpokeaji

Inasanidi usaidizi wa STARTTLS na cheti halali kwenye seva ya barua.
Inachapisha sera ya MTA-STS kupitia HTTPS; kikoa maalum cha mta-sts na njia maalum inayojulikana hutumiwa kwa uchapishaji, kwa mfano. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Sera ina orodha ya seva za barua (mx) ambazo zina haki ya kupokea barua kwa kikoa hiki.
Huchapisha rekodi maalum ya TXT _mta-sts katika DNS na toleo la sera. Sera inapobadilika, ingizo hili lazima lisasishwe (hii inaashiria mtumaji kuuliza tena sera hiyo). Kwa mfano, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Mtumaji

Mtumaji huomba _mta-sts rekodi ya DNS, na ikiwa inapatikana, hufanya ombi la sera kupitia HTTPS (kuangalia cheti). Sera inayotokana imehifadhiwa (ikiwa mshambuliaji atazuia ufikiaji wake au kuharibu rekodi ya DNS).

Wakati wa kutuma barua, inakaguliwa kuwa:

seva ambayo barua hutumwa iko kwenye sera;
seva inakubali barua kwa kutumia TLS (STARTTLS) na ina cheti halali.

Faida za MTA-STS

MTA-STS hutumia teknolojia ambazo tayari zimetekelezwa katika mashirika mengi (SMTP+STARTTLS, HTTPS, DNS). Kwa utekelezaji kwa upande wa mpokeaji, hakuna usaidizi maalum wa programu kwa kiwango unahitajika.

Hasara za MTA-STS

Ni muhimu kufuatilia uhalali wa cheti cha seva ya wavuti na barua, mawasiliano ya majina, na upyaji wa wakati. Matatizo ya cheti yatasababisha barua kushindwa kutumwa.

Kwa upande wa mtumaji, MTA inayotumika kwa sera za MTA-STS inahitajika; kwa sasa, MTA-STS haitumiki nje ya kisanduku cha MTA.

MTA-STS hutumia orodha ya CA za mizizi zinazoaminika.

MTA-STS hailindi dhidi ya mashambulizi ambapo mvamizi hutumia cheti halali. Mara nyingi, MitM karibu na seva inamaanisha uwezo wa kutoa cheti. Shambulio kama hilo linaweza kutambuliwa kwa kutumia Uwazi wa Cheti. Kwa hiyo, kwa ujumla, MTA-STS inapunguza, lakini haiondoi kabisa, uwezekano wa kuzuia trafiki.

Alama mbili za mwisho hufanya MTA-STS kuwa salama kuliko kiwango shindani cha DANE cha SMTP (RFC 7672), lakini kinategemewa zaidi kiufundi, i.e. kwa MTA-STS kuna uwezekano mdogo kwamba barua haitawasilishwa kutokana na matatizo ya kiufundi yanayotokana na utekelezaji wa kiwango.

Kiwango cha kushindana - DANE

DANE hutumia DNSSEC kuchapisha maelezo ya cheti na haihitaji uaminifu katika mamlaka ya cheti cha nje, ambayo ni salama zaidi. Lakini matumizi ya DNSSEC mara nyingi zaidi husababisha kushindwa kwa kiufundi, kulingana na takwimu za miaka kadhaa ya matumizi (ingawa kwa ujumla kuna mwelekeo mzuri katika kuegemea kwa DNSSEC na msaada wake wa kiufundi). Ili kutekeleza DANE katika SMTP kwa upande wa mpokeaji, kuwepo kwa DNSSEC kwa eneo la DNS ni lazima, na usaidizi sahihi wa NSEC/NSEC3 ni muhimu kwa DANE, ambayo kuna matatizo ya kimfumo katika DNSSEC.

Ikiwa DNSSEC haijasanidiwa ipasavyo, inaweza kusababisha hitilafu katika uwasilishaji wa barua ikiwa upande wa kutuma unatumia DANE, hata kama upande unaopokea haujui lolote kuihusu. Kwa hiyo, pamoja na ukweli kwamba DANE ni kiwango cha zamani na salama zaidi na tayari kinasaidiwa katika baadhi ya programu za seva kwenye upande wa mtumaji, kwa kweli kupenya kwake kunabakia kuwa duni, mashirika mengi hayako tayari kutekeleza kwa sababu ya haja ya kutekeleza DNSSEC. hii imepunguza kasi ya utekelezaji wa DANE miaka yote ambayo kiwango hicho kimekuwepo.

DANE na MTA-STS hazipingani na zinaweza kutumika pamoja.

Je, kuna usaidizi wa MTA-STS katika Mail.ru Mail?

Mail.ru imekuwa ikichapisha sera ya MTA-STS kwa vikoa vyote vikuu kwa muda mrefu. Kwa sasa tunatekeleza sehemu ya mteja ya kiwango. Wakati wa kuandika, sera hutumiwa katika hali isiyo ya kuzuia (ikiwa uwasilishaji umezuiwa na sera, barua itawasilishwa kupitia seva ya "spea" bila kutumia sera), kisha hali ya kuzuia italazimika kwa sehemu ndogo. ya trafiki inayotoka ya SMTP, hatua kwa hatua kwa 100% ya trafiki itakuwa Utekelezaji wa sera unasaidiwa.

Nani mwingine anaunga mkono kiwango?

Kufikia sasa, sera za MTA-STS huchapisha takriban 0.05% ya vikoa amilifu, lakini, hata hivyo, tayari zinalinda idadi kubwa ya trafiki ya barua, kwa sababu. Kiwango hiki kinatumika na wachezaji wakuu - Google, Comcast na sehemu ya Verizon (AOL, Yahoo). Huduma zingine nyingi za posta zimetangaza kuwa msaada wa kiwango hicho utatekelezwa katika siku za usoni.

Je, hii itaniathirije?

Si isipokuwa kikoa chako kikichapisha sera ya MTA-STS. Ukichapisha sera, barua pepe za watumiaji wa seva yako ya barua zitalindwa vyema dhidi ya kuzuiwa.

Je, ninawezaje kutekeleza MTA-STS?

Usaidizi wa MTA-STS kwa upande wa mpokeaji

Inatosha kuchapisha sera kupitia HTTPS na rekodi katika DNS, kusanidi cheti halali kutoka kwa mojawapo ya CA zinazoaminika (Tunaweza kusimba kwa njia fiche) kwa STARTTLS katika MTA (STARTTLS inatumika katika MTA zote za kisasa), hakuna usaidizi maalum kutoka kwa MTA inahitajika.

Hatua kwa hatua, inaonekana kama hii:

Sanidi STARTTLS katika MTA unayotumia (postfix, exim, sendmail, Microsoft Exchange, n.k.).
Hakikisha kuwa unatumia cheti halali (kilichotolewa na CA anayeaminika, ambacho muda wake haujaisha, mada ya cheti inalingana na rekodi ya MX ambayo hutoa barua kwa kikoa chako).
Sanidi rekodi ya TLS-RPT ambayo kwayo ripoti za maombi ya sera zitawasilishwa (kwa huduma zinazotumia kutuma ripoti za TLS). Ingizo la mfano (kwa kikoa cha mfano.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Ingizo hili linawaagiza watumaji barua kutuma ripoti za takwimu za matumizi ya TLS katika SMTP kwa [email protected].

Fuatilia ripoti kwa siku kadhaa ili kuhakikisha kuwa hakuna makosa.
Chapisha sera ya MTA-STS kwenye HTTPS. Sera hiyo inachapishwa kama faili ya maandishi yenye viondoa laini vya CRLF kulingana na eneo.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Mfano wa sera:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Sehemu ya toleo ina toleo la sera (kwa sasa STSv1), Hali huweka modi ya utumaji sera, majaribio — modi ya majaribio (sera haijatumika), tekeleza — modi ya "pambana". Chapisha kwanza sera ukitumia hali: majaribio, ikiwa hakuna matatizo na sera katika hali ya majaribio, baada ya muda unaweza kubadili hadi modi: tekeleza.

Katika mx, orodha ya seva zote za barua pepe zinazoweza kukubali barua kwa kikoa chako imebainishwa (kila seva lazima iwe na cheti kilichosanidiwa ambacho kinalingana na jina lililotajwa katika mx). Max_age hubainisha muda wa kuweka akiba ya sera (mara tu sera inayokumbukwa itatumika hata kama mshambulizi atazuia uwasilishaji wake au kuharibu rekodi za DNS wakati wa kuweka akiba, unaweza kuashiria hitaji la kuomba sera tena kwa kubadilisha DNS ya mta-sts. rekodi).
Chapisha rekodi ya TXT katika DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Kitambulishi kiholela (kwa mfano, muhuri wa muda) kinaweza kutumika katika uga wa kitambulisho; sera inapobadilika, inapaswa kubadilika, hii inaruhusu watumaji kuelewa kwamba wanahitaji kuomba tena sera iliyoakibishwa (ikiwa kitambulisho ni tofauti na moja iliyohifadhiwa).

Usaidizi wa MTA-STS kwa upande wa mtumaji

Kufikia sasa ni mbaya kwake, kwa sababu ... kiwango safi.

Exim - hakuna usaidizi uliojengwa ndani, kuna hati ya mtu wa tatu https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - hakuna usaidizi uliojengwa ndani, kuna hati ya mtu wa tatu ambayo imeelezewa kwa kina juu ya Habre. https://habr.com/en/post/424961/

Kama neno la baadaye kuhusu "TLS ya lazima"

Hivi majuzi, wasimamizi wamekuwa wakizingatia usalama wa barua pepe (na hiyo ni jambo zuri). Kwa mfano, DMARC ni ya lazima kwa mashirika yote ya serikali nchini Marekani na inahitajika zaidi katika sekta ya fedha, na kupenya kwa kiwango kufikia 90% katika maeneo yaliyodhibitiwa. Sasa baadhi ya vidhibiti vinahitaji utekelezaji wa "TLS ya lazima" na vikoa vya mtu binafsi, lakini utaratibu wa kuhakikisha "TLS ya lazima" haijafafanuliwa na kwa vitendo mpangilio huu mara nyingi hutekelezwa kwa njia ambayo hailindi hata kidogo dhidi ya mashambulizi ya kweli ambayo tayari zinazotolewa katika mifumo kama vile DANE au MTA-STS.

Ikiwa kidhibiti kinahitaji utekelezaji wa "TLS ya lazima" iliyo na vikoa tofauti, tunapendekeza kuzingatia MTA-STS au analogi yake nusu kama njia inayofaa zaidi, itaondoa hitaji la kuweka mipangilio salama kwa kila kikoa kivyake. Ikiwa una shida kutekeleza sehemu ya mteja ya MTA-STS (mpaka itifaki ipate usaidizi ulioenea, kuna uwezekano mkubwa), tunaweza kupendekeza njia hii:

Chapisha sera ya MTA-STS na/au rekodi za DANE (DANE inaeleweka tu ikiwa DNSSEC tayari imewashwa kwa kikoa chako, na MTA-STS kwa hali yoyote), hii italinda trafiki kuelekea kwako na kuondoa hitaji la kuuliza huduma zingine za barua. kusanidi TLS ya lazima kwa kikoa chako ikiwa huduma ya barua tayari inaauni MTA-STS na/au DANE.
Kwa huduma kubwa za barua pepe, tumia "analogi" ya MTA-STS kupitia mipangilio tofauti ya usafiri kwa kila kikoa, ambayo itarekebisha MX inayotumiwa kutuma barua pepe na itahitaji uthibitishaji wa lazima wa cheti cha TLS kwa hiyo. Ikiwa vikoa tayari vinachapisha sera ya MTA-STS, hii inaweza kufanywa bila maumivu. Kwa peke yake, kuwezesha TLS ya lazima kwa kikoa bila kurekebisha relay na kuthibitisha cheti chake hakufanyi kazi kwa mtazamo wa usalama na hakuongezi chochote kwenye mifumo iliyopo ya STARTTLS.

Chanzo: mapenzi.com

Barua pepe ya Mail.ru huanza kutumia sera za MTA-STS katika hali ya majaribio