Mail.ru pasts sāk piemērot MTA-STS politikas testa režīmā

Mail.ru pasts sāk piemērot MTA-STS politikas testa režīmā

ÄŖsāk sakot, MTA-STS ir veids, kā vēl vairāk aizsargāt e-pastus no pārtverÅ”anas (t.i., uzbrukumiem starp uzbrukumiem, ko sauc par MitM), kad tie tiek pārsÅ«tÄ«ti starp pasta serveriem. Tas daļēji atrisina mantotās e-pasta protokolu arhitektÅ«ras problēmas un ir aprakstÄ«ts salÄ«dzinoÅ”i nesenajā standartā RFC 8461. Mail.ru ir pirmais lielākais pasta pakalpojums RuNet, kas ieviesis Å”o standartu. Un tas ir sÄ«kāk aprakstÄ«ts zem griezuma.

Kādu problēmu atrisina MTA-STS?

Vēsturiski e-pasta protokoli (SMTP, POP3, IMAP) pārsūtīja informāciju skaidrā tekstā, kas ļāva to pārtvert, piemēram, piekļūstot sakaru kanālam.

Kā izskatās mehānisms vēstules nosÅ«tÄ«Å”anai no viena lietotāja citam:

Mail.ru pasts sāk piemērot MTA-STS politikas testa režīmā

Vēsturiski MitM uzbrukums bija iespējams visās vietās, kur cirkulē pasts.

RFC 8314 pieprasa TLS izmantoÅ”anu starp pasta lietotāja lietojumprogrammu (MUA) un pasta serveri. Ja jÅ«su serveris un izmantotās pasta lietojumprogrammas ir saderÄ«gas ar RFC 8314, jÅ«s (lielākoties) esat novērsis Man-in-the-Middle uzbrukumu iespējamÄ«bu starp lietotāju un pasta serveriem.

Vispārpieņemtas prakses ievēroÅ”ana (standartizēta ar RFC 8314) novērÅ” uzbrukumu lietotāja tuvumā:

Mail.ru pasts sāk piemērot MTA-STS politikas testa režīmā

Mail.ru pasta serveri atbilda RFC 8314 jau pirms standarta pieņemÅ”anas; patiesÄ«bā tas vienkārÅ”i tver jau pieņemto praksi, un mums nebija jākonfigurē nekas papildu. Bet, ja jÅ«su pasta serveris joprojām ļauj lietotājiem izmantot nedroÅ”os protokolus, noteikti ieviesiet Ŕī standarta ieteikumus, jo Visticamāk, vismaz daži jÅ«su lietotāji strādā ar pastu bez Å”ifrÄ“Å”anas, pat ja jÅ«s to atbalstāt.

Pasta klients vienmēr strādā ar vienu un to paÅ”u organizācijas pasta serveri. Un jÅ«s varat piespiest visus lietotājus izveidot savienojumu droŔā veidā un pēc tam padarÄ«t tehniski neiespējamu nedroÅ”iem lietotājiem izveidot savienojumu (tas ir tieÅ”i tas, ko pieprasa RFC 8314). Tas dažreiz ir grÅ«ti, bet izdarāms. Satiksme starp pasta serveriem joprojām ir sarežģītāka. Serveri pieder dažādām organizācijām un bieži tiek izmantoti ā€œiestatÄ«t un aizmirstā€ režīmā, kas neļauj uzreiz pārslēgties uz droÅ”u protokolu, nepārtraucot savienojumu. SMTP jau sen ir nodroÅ”inājis STARTTLS paplaÅ”inājumu, kas ļauj serveriem, kas atbalsta Å”ifrÄ“Å”anu, pārslēgties uz TLS. Taču uzbrucējs, kuram ir iespēja ietekmēt trafiku, var ā€œizgrieztā€ informāciju par Ŕīs komandas atbalstu un piespiest serverus sazināties, izmantojot vienkārÅ”a teksta protokolu (tā sauktais pazemināŔanas uzbrukums). Tā paÅ”a iemesla dēļ STARTTLS parasti nepārbauda sertifikāta derÄ«gumu (neuzticams sertifikāts var aizsargāt pret pasÄ«viem uzbrukumiem, un tas nav sliktāks par ziņojuma nosÅ«tÄ«Å”anu skaidrā tekstā). Tāpēc STARTTLS aizsargā tikai pret pasÄ«vu noklausÄ«Å”anos.

MTA-STS daļēji novērÅ” vēstuļu pārtverÅ”anas problēmu starp pasta serveriem, kad uzbrucējam ir iespēja aktÄ«vi ietekmēt trafiku. Ja adresāta domēns publicē MTA-STS politiku un sÅ«tÄ«tāja serveris atbalsta MTA-STS, tas nosÅ«tÄ«s e-pastu tikai, izmantojot TLS savienojumu, tikai uz politikā definētajiem serveriem un tikai ar servera sertifikāta pārbaudi.

Kāpēc daļēji? MTA-STS darbojas tikai tad, ja abas puses ir parÅ«pējuŔās par Ŕī standarta ievieÅ”anu, un MTA-STS neaizsargā pret gadÄ«jumiem, kad uzbrucējs var iegÅ«t derÄ«gu domēna sertifikātu no vienas no publiskajām CA.

Kā darbojas MTA-STS

saņēmējs

  1. Konfigurē STARTTLS atbalstu ar derÄ«gu sertifikātu pasta serverÄ«. 
  2. Publicē MTA-STS politiku, izmantojot HTTPS; publicÄ“Å”anai tiek izmantots Ä«paÅ”s mta-sts domēns un Ä«paÅ”s labi zināms ceļŔ, piemēram, https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politikā ir saraksts ar pasta serveriem (mx), kuriem ir tiesÄ«bas saņemt Ŕī domēna pastu.
  3. Publicē Ä«paÅ”u TXT ierakstu _mta-sts DNS ar politikas versiju. Kad politika mainās, Å”is ieraksts ir jāatjaunina (tas norāda sÅ«tÄ«tājam, lai atkārtoti pieprasÄ«tu politiku). Piemēram, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Sūtītājs

SÅ«tÄ«tājs pieprasa _mta-sts DNS ierakstu un, ja tas ir pieejams, veic politikas pieprasÄ«jumu, izmantojot HTTPS (pārbaudot sertifikātu). Rezultātā iegÅ«tā politika tiek saglabāta keÅ”atmiņā (ja uzbrucējs bloķē piekļuvi tai vai vilto DNS ierakstu).

Nosūtot pastu, tiek pārbaudīts, vai:

  • serveris, uz kuru tiek piegādāts pasts, ir polisē;
  • serveris pieņem pastu, izmantojot TLS (STARTTLS), un tam ir derÄ«gs sertifikāts.

MTA-STS priekŔrocības

MTA-STS izmanto tehnoloÄ£ijas, kas jau ir ieviestas lielākajā daļā organizāciju (SMTP+STARTTLS, HTTPS, DNS). ÄŖstenoÅ”anai saņēmēja pusē standartam nav nepiecieÅ”ams Ä«paÅ”s programmatÅ«ras atbalsts.

MTA-STS trūkumi

Ir jāuzrauga tÄ«mekļa un pasta servera sertifikāta derÄ«gums, vārdu atbilstÄ«ba un savlaicÄ«ga atjaunoÅ”ana. Ja rodas problēmas ar sertifikātu, pastu nevarēs piegādāt.

No sūtītāja puses ir nepiecieŔama MTA ar MTA-STS politiku atbalstu; paŔlaik MTA-STS netiek atbalstīts MTA.

MTA-STS izmanto uzticamo saknes CA sarakstu.

MTA-STS neaizsargā pret uzbrukumiem, kuros uzbrucējs izmanto derÄ«gu sertifikātu. Vairumā gadÄ«jumu MitM servera tuvumā nozÄ«mē iespēju izsniegt sertifikātu. Šādu uzbrukumu var noteikt, izmantojot Certificate Transparency. Tāpēc kopumā MTA-STS mazina, bet pilnÄ«bā nenovērÅ” satiksmes pārtverÅ”anas iespēju.

Pēdējie divi punkti padara MTA-STS mazāk droÅ”u par konkurējoÅ”o DANE standartu SMTP (RFC 7672), taču tehniski uzticamāku, t.i. MTA-STS ir maza varbÅ«tÄ«ba, ka vēstule netiks piegādāta standarta ievieÅ”anas izraisÄ«tu tehnisku problēmu dēļ.

Sacensību standarts - DANE

DANE izmanto DNSSEC, lai publicētu sertifikātu informāciju, un tai nav nepiecieÅ”ama uzticÄ“Å”anās ārējām sertifikātu iestādēm, kas ir daudz droŔāka. Bet DNSSEC izmantoÅ”ana ievērojami biežāk izraisa tehniskas kļūmes, pamatojoties uz statistiku vairāku gadu lietoÅ”anas laikā (lai gan kopumā ir pozitÄ«va tendence DNSSEC un tā tehniskā atbalsta uzticamÄ«bā). Lai ieviestu DANE SMTP adresāta pusē, DNSSEC klātbÅ«tne DNS zonai ir obligāta, un DANE ir bÅ«tisks pareizs atbalsts NSEC/NSEC3, ar kuru DNSSEC ir sistēmiskas problēmas.

Ja DNSSEC nav pareizi konfigurēts, tas var izraisÄ«t pasta piegādes kļūmes, ja sÅ«tÄ«tāja puse atbalsta DANE, pat ja saņēmēja puse par to neko nezina. Tāpēc, neskatoties uz to, ka DANE ir vecāks un droŔāks standarts un jau tiek atbalstÄ«ts kādā servera programmatÅ«rā sÅ«tÄ«tāja pusē, faktiski tā izplatÄ«ba joprojām ir nenozÄ«mÄ«ga, daudzas organizācijas nav gatavas to ieviest, jo ir nepiecieÅ”ams ieviest DNSSEC, tas ir bÅ«tiski palēninājuÅ”i DANE ievieÅ”anu visus standarta pastāvÄ“Å”anas gadus.

DANE un MTA-STS nav pretrunā viens ar otru un var tikt izmantoti kopā.

Kas notiek ar MTA-STS atbalstu pakalpojumā Mail.ru Mail?

Mail.ru jau ilgu laiku ir publicējis MTA-STS politiku visiem galvenajiem domēniem. Å obrÄ«d mēs ievieÅ”am standarta klienta daļu. RakstÄ«Å”anas laikā politikas tiek piemērotas nebloÄ·Ä“Å”anas režīmā (ja piegāde ir bloķēta ar politiku, vēstule tiks piegādāta caur "rezerves" serveri, neizmantojot politikas), tad bloÄ·Ä“Å”anas režīms tiks piespiests nelielai daļai. no izejoŔās SMTP trafika, pakāpeniski 100% trafika tiks atbalstÄ«ta politiku izpilde.

KurÅ” vēl atbalsta standartu?

LÄ«dz Å”im MTA-STS politikas publicē aptuveni 0.05% aktÄ«vo domēnu, taču, neskatoties uz to, tās jau aizsargā lielu pasta trafika apjomu, jo Standartu atbalsta lielākie spēlētāji - Google, Comcast un daļēji Verizon (AOL, Yahoo). Daudzi citi pasta dienesti ir paziņojuÅ”i, ka tuvākajā laikā tiks ieviests standarta atbalsts.

Kā tas mani ietekmēs?

Ja vien jÅ«su domēnā nav publicēta MTA-STS politika. Ja publicēsit politiku, jÅ«su pasta servera lietotāju e-pasta ziņojumi tiks labāk aizsargāti pret pārtverÅ”anu.

Kā ieviest MTA-STS?

MTA-STS atbalsts saņēmēja pusē

Pietiek publicēt politiku, izmantojot HTTPS, un ierakstus DNS, konfigurēt derÄ«gu sertifikātu no vienas no uzticamajām CA (Iespējams Å”ifrēt) STARTTLS MTA (STARTTLS tiek atbalstÄ«ts visos mÅ«sdienu MTA), nav Ä«paÅ”a atbalsta no NepiecieÅ”ama MTA.

Soli pa solim tas izskatās Ŕādi:

  1. Konfigurējiet STARTTLS izmantotajā MTA (postfix, exim, sendmail, Microsoft Exchange utt.).
  2. Pārliecinieties, vai izmantojat derÄ«gu sertifikātu (to izdevusi uzticama CA, kam nav beidzies derÄ«guma termiņŔ, sertifikāta priekÅ”mets atbilst MX ierakstam, kas piegādā pastu jÅ«su domēnam).
  3. Konfigurējiet TLS-RPT ierakstu, caur kuru tiks piegādāti politikas lietojumprogrammu atskaites (pakalpojumi, kas atbalsta TLS atskaiÅ”u sÅ«tÄ«Å”anu). Ieraksta piemērs (domēnam example.com):
    smtp._tls.example.com. 300 IN TXT Ā«v=TLSRPTv1;rua=mailto:[email protected]Ā»

    Å is ieraksts uzdod pasta sÅ«tÄ«tājiem nosÅ«tÄ«t statistikas pārskatus par TLS lietojumu SMTP uz [email protected].

    Pārraugiet pārskatus vairākas dienas, lai pārliecinātos, ka nav kļūdu.

  4. Publicējiet MTA-STS politiku, izmantojot HTTPS. Politika tiek publicēta kā teksta fails ar CRLF rindiņas terminatoriem pēc atraÅ”anās vietas.
    https://mta-sts.example.com/.well-known/mta-sts.txt
    

    Politikas piemērs:

    version: STSv1
    mode: enforce
    mx: mxs.mail.ru
    mx: emx.mail.ru
    mx: mx2.corp.mail.ru
    max_age: 86400
    

    Versijas laukā ir norādÄ«ta politikas versija (paÅ”laik STSv1), Režīms iestata politikas piemēroÅ”anas režīmu, testÄ“Å”ana ā€” testa režīms (politika netiek piemērota), Enforce ā€” ā€œcīņasā€ režīms. Vispirms publicējiet politiku ar režīmu: testÄ“Å”ana, ja testa režīmā ar politiku nav problēmu, pēc kāda laika varat pārslēgties uz režīmu: enforce.

    Mx ir norādÄ«ts visu pasta serveru saraksts, kas var pieņemt jÅ«su domēna pastu (katram serverim ir jābÅ«t konfigurētam sertifikātam, kas atbilst mx norādÄ«tajam nosaukumam). Max_age norāda politikas keÅ”atmiņas laiku (kad atcerētā politika tiks lietota pat tad, ja uzbrucējs keÅ”atmiņas laikā bloķē tās piegādi vai sabojā DNS ierakstus, varat signalizēt par nepiecieÅ”amÄ«bu vēlreiz pieprasÄ«t politiku, mainot mta-sts DNS ieraksts).

  5. Publicējiet TXT ierakstu DNS: 
    _mta-sts.example.com. TXT ā€œv=STS1; id=someid;ā€
    

    ID laukā var izmantot patvaļīgu identifikatoru (piemēram, laikspiedolu); kad politika mainās, tai ir jāmainās, tādējādi sÅ«tÄ«tāji var saprast, ka viņiem ir atkārtoti jāpieprasa keÅ”atmiņā saglabātā politika (ja identifikators atŔķiras no keÅ”atmiņā saglabātais).

MTA-STS atbalsts sūtītāja pusē

Pagaidām ar viņu ir slikti, jo... svaigs standarts.

Kā pēcvārds par "obligāto TLS"

Pēdējā laikā regulatori ir pievērsuÅ”i uzmanÄ«bu e-pasta droŔībai (un tas ir labi). Piemēram, DMARC ir obligāts visām valsts aÄ£entÅ«rām Amerikas Savienotajās ValstÄ«s, un tas arvien vairāk tiek pieprasÄ«ts finanÅ”u sektorā, jo regulētajās jomās standarta izplatÄ«ba sasniedz 90%. Tagad daži regulatori pieprasa ā€œobligātā TLSā€ ievieÅ”anu ar atseviŔķiem domēniem, taču ā€œobligātā TLSā€ nodroÅ”ināŔanas mehānisms nav definēts un praksē Å”is uzstādÄ«jums nereti tiek ieviests tā, ka pat minimāli neaizsargā pret reāliem uzbrukumiem, kas jau ir kas paredzēti tādos mehānismos kā DANE vai MTA-STS.

Ja regulators pieprasa ā€œobligātā TLSā€ ievieÅ”anu ar atseviŔķiem domēniem, iesakām kā piemērotāko mehānismu uzskatÄ«t MTA-STS vai tā daļēju analogu, tas novērÅ” nepiecieÅ”amÄ«bu veikt droÅ”us iestatÄ«jumus katram domēnam atseviŔķi. Ja jums ir grÅ«tÄ«bas ar MTA-STS klienta daļas ievieÅ”anu (kamēr protokols nav saņēmis plaÅ”u atbalstu, viņi, visticamāk, saņems), mēs varam ieteikt Ŕādu pieeju:

  1. Publicējiet MTA-STS politiku un/vai DANE ierakstus (DANE ir jēga tikai tad, ja jÅ«su domēnam jau ir iespējots DNSSEC, un jebkurā gadÄ«jumā MTA-STS), tas aizsargās trafiku jÅ«su virzienā un novērsÄ«s nepiecieÅ”amÄ«bu lÅ«gt citus pasta pakalpojumus. lai konfigurētu obligāto TLS savam domēnam, ja pasta pakalpojums jau atbalsta MTA-STS un/vai DANE.
  2. Lieliem e-pasta pakalpojumiem ieviesiet MTA-STS ā€œanaloguā€, izmantojot atseviŔķus transporta iestatÄ«jumus katram domēnam, kas novērsÄ«s pasta pārsÅ«tÄ«Å”anai izmantoto MX un prasÄ«s obligātu tā TLS sertifikāta pārbaudi. Ja domēni jau publicē MTA-STS politiku, to, visticamāk, var izdarÄ«t nesāpÄ«gi. Pati par sevi obligātā TLS iespējoÅ”ana domēnam, nelabojot releju un tam nepārbaudot sertifikātu, no droŔības viedokļa ir neefektÄ«va un neko nepievieno esoÅ”ajiem STARTTLS mehānismiem.

Avots: www.habr.com

Pievieno komentāru