Mail.ru posta MTA-STS politikak proba moduan aplikatzen hasten da

Mail.ru posta MTA-STS politikak proba moduan aplikatzen hasten da

Laburbilduz, MTA-STS mezu elektronikoak atzematetik gehiago babesteko modu bat da (hau da, gizon-erdian-erasoak MitM aka) posta-zerbitzarien artean transmititzen direnean. Posta elektronikoaren protokoloen arkitektura-arazoak partzialki konpontzen ditu eta RFC 8461 estandar nahiko berrian deskribatzen da. Mail.ru da RuNet-eko lehen posta-zerbitzu nagusia estandar hau inplementatzen duena. Eta xehetasun gehiagorekin deskribatzen da ebakiaren azpian.

Zein arazo ebazten du MTA-STS-k?

Historikoki, posta elektronikoko protokoloek (SMTP, POP3, IMAP) informazioa testu argian transmititzen zuten, eta horri esker atzematea posible zen, adibidez, komunikazio-kanal batera sartzean.

Nolakoa da erabiltzaile bati gutun bat beste bati bidaltzeko mekanismoa:

Mail.ru posta MTA-STS politikak proba moduan aplikatzen hasten da

Historikoki, MitM eraso bat posible zen posta zirkulatzen den leku guztietan.

RFC 8314-k TLS erabiltzea eskatzen du posta-erabiltzailearen aplikazioaren (MUA) eta posta-zerbitzariaren artean. Zure zerbitzariak eta erabiltzen dituzun posta-aplikazioek RFC 8314-arekin bat egiten badute, orduan (neurri handi batean) ezabatu duzu Man-in-the-Middle-en erasoak erabiltzailearen eta posta-zerbitzarien artean.

Orokorrean onartutako praktikak jarraituz (RFC 8314-k estandarizatuta) erabiltzailearen gertuko erasoa ezabatzen da:

Mail.ru posta MTA-STS politikak proba moduan aplikatzen hasten da

Mail.ru posta zerbitzariek RFC 8314 estandarra onartu aurretik ere betetzen zuten; izan ere, jada onartutako praktikak jasotzen ditu eta ez genuen ezer gehigarririk konfiguratu behar izan. Baina, zure posta zerbitzariak erabiltzaileei protokolo seguruak erabiltzeari uzten badie oraindik, ziurtatu estandar honen gomendioak inplementatzen dituzula, izan ere Seguruenik, zure erabiltzaileetako batzuek gutxienez enkriptatutako postarekin lan egiten dute, onartzen baduzu ere.

Posta-bezeroak erakunde bereko posta-zerbitzari berarekin lan egiten du beti. Erabiltzaile guztiak modu seguruan konektatzera behartu ditzakezu, eta gero teknikoki ezinezkoa izan daiteke seguruak ez diren erabiltzaileek konektatzea (hau da RFC 8314-k eskatzen duena). Hau batzuetan zaila da, baina egingarria. Posta-zerbitzarien arteko trafikoa oraindik zailagoa da. Zerbitzariak erakunde ezberdinetakoak dira eta askotan "ezarri eta ahaztu" moduan erabiltzen dira, eta horrek ezinezkoa egiten du aldi berean protokolo seguru batera aldatzea konektibitatea hautsi gabe. SMTP-k STARTTLS luzapena eskaintzen du, enkriptatzea onartzen duten zerbitzariei TLSra aldatzeko aukera ematen diena. Baina trafikoan eragiteko gaitasuna duen erasotzaile batek komando horri euskarriaren inguruko informazioa "moztu" dezake eta zerbitzariak testu arrunteko protokolo bat erabiliz komunikatzeko behartu (downgrade erasoa deritzona). Arrazoi beragatik, STARTTLS-k normalean ez du egiaztatzen ziurtagiriaren baliozkotasuna (fidagarria ez den ziurtagiri batek eraso pasiboetatik babestu dezake, eta hori ez da mezu bat testu argian bidaltzea baino okerragoa). Hori dela eta, STARTTLS-ek entzute pasiboetatik soilik babesten du.

MTA-STS-k partzialki ezabatzen du posta-zerbitzarien arteko gutunak atzematearen arazoa, erasotzaileak trafikoan aktiboki eragiteko gaitasuna duenean. Hartzailearen domeinuak MTA-STS politika bat argitaratzen badu eta igorlearen zerbitzariak MTA-STS onartzen badu, mezu elektronikoa TLS konexio baten bidez soilik bidaliko du, politikak zehaztutako zerbitzarietara soilik, eta zerbitzariaren ziurtagiria egiaztatuta soilik.

Zergatik partzialki? MTA-STS-k bakarrik funtzionatzen du bi alderdiek estandar hau inplementatzen zaindu badute, eta MTA-STS-k ez du babesten erasotzaile batek CA publikoetako baten baliozko domeinu-ziurtagiria lortzeko gai diren agertokietatik.

Nola funtzionatzen duen MTA-STS

hartzaileak

  1. STARTTLS euskarria konfiguratzen du posta zerbitzarian baliozko ziurtagiri batekin. 
  2. MTA-STS politika HTTPS bidez argitaratzen du; mta-sts domeinu berezi bat eta bide ezagun berezi bat erabiltzen dira argitaratzeko, adibidez https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politikak domeinu honetarako posta jasotzeko eskubidea duten posta-zerbitzarien (mx) zerrenda bat dauka.
  3. TXT erregistro berezi bat argitaratzen du _mta-sts DNSn politikaren bertsioarekin. Politika aldatzen denean, sarrera hau eguneratu egin behar da (horrek igorleari gidalerroa berriro kontsultatzeko seinalea ematen dio). Adibidez, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Bidaltzailea

Bidaltzaileak _mta-sts DNS erregistroa eskatzen du, eta erabilgarri badago, politika eskaera bat egiten du HTTPS bidez (ziurtagiria egiaztatuz). Sortzen den politika cachean gordetzen da (erasotzaile batek sarbidea blokeatzen badu edo DNS erregistroa faltsatzen badu).

Posta bidaltzean, egiaztatzen da:

  • posta bidaltzen zaion zerbitzaria politikan dago;
  • zerbitzariak TLS (STARTTLS) erabiliz posta onartzen du eta baliozko ziurtagiria du.

MTA-STSren abantailak

MTA-STS erakunde gehienetan jada ezarrita dauden teknologiak erabiltzen ditu (SMTP+STARTTLS, HTTPS, DNS). Hartzailearen aldean ezartzeko, ez da estandarraren software-laguntza berezirik behar.

MTA-STSen desabantailak

Beharrezkoa da web eta posta zerbitzariaren ziurtagiriaren baliozkotasuna, izenen korrespondentzia eta garaiz berritzea. Ziurtagiriarekin arazoen ondorioz, posta ezin izango da entregatu.

Bidaltzailearen aldetik, MTA-STS gidalerroetarako laguntza duen MTA bat behar da; gaur egun, MTA-STS ez da MTA-n kutxatik kanpo onartzen.

MTA-STS-k erroko CA fidagarrien zerrenda erabiltzen du.

MTA-STS ez du babesten erasotzaileak baliozko ziurtagiri bat erabiltzen duen erasoetatik. Kasu gehienetan, zerbitzaritik gertu dagoen MitM-k ziurtagiria emateko gaitasuna dakar. Eraso hori detektatu daiteke Ziurtagiriaren Gardentasuna erabiliz. Hori dela eta, oro har, MTA-STS-k trafikoa atzemateko aukera arintzen du, baina ez du guztiz ezabatzen.

Azken bi puntuek MTA-STS SMTP (RFC 7672) lehian dagoen DANE estandarra baino seguruago bihurtzen dute, baina teknikoki fidagarriagoa, alegia. MTA-STSrentzat probabilitate txikia da gutuna ez entregatzeko araua ezartzeak eragindako arazo teknikoengatik.

Estandar lehiakorra - DANE

DANEk DNSSEC erabiltzen du ziurtagiriaren informazioa argitaratzeko eta ez du kanpoko ziurtagiri-agintarien konfiantzarik eskatzen, askoz seguruagoa baita. Baina DNSSEC erabiltzeak askoz maizago akats teknikoak ekartzen ditu, hainbat urtetako erabileran egindako estatistiketan oinarrituta (nahiz eta DNSSECen eta bere laguntza teknikoaren fidagarritasunean joera positiboa izan ohi den). Hartzailearen aldean SMTP-n DANE ezartzeko, DNS eremurako DNSSEC egotea derrigorrezkoa da, eta NSEC/NSEC3-ren laguntza zuzena ezinbestekoa da DANErentzat, DNSSEC-en arazo sistemikoak baitaude.

DNSSEC behar bezala konfiguratuta ez badago, posta bidaltzeko hutsegiteak eragin ditzake bidaltzaileak DANE onartzen badu, nahiz eta hartzaileak ezer ez dakien. Hori dela eta, DANE estandar zaharrago eta seguruagoa den arren, eta dagoeneko igorlearen aldetik zerbitzariaren software batzuetan onartzen den arren, bere sartzea hutsala izaten jarraitzen du, erakunde asko ez daude prest ezartzeko DNSSEC ezartzeko beharragatik, horrek nabarmen moteldu du DANEren ezarpena estandarra egon den urte horietan guztietan.

DANE eta MTA-STS ez dira gatazkarik sortzen eta elkarrekin erabil daitezke.

Zer da MTA-STS euskarria Mail.ru Mail-en?

Mail.ru-k denbora dezente daramatza MTA-STS politika domeinu nagusi guztientzat argitaratzen. Gaur egun estandarraren bezeroaren zatia ezartzen ari gara. Idazteko unean, politikak blokeorik gabeko moduan aplikatzen dira (politika batek bidalketa blokeatzen badu, gutuna "ordezko" zerbitzari baten bidez bidaliko da politikak aplikatu gabe), orduan blokeo modua behartuko da zati txiki batean. irteerako SMTP trafikoari dagokionez, pixkanaka trafikoaren % 100erako politikak betearaztea onartzen da.

Nork onartzen du estandarra?

Orain arte, MTA-STS politikek domeinu aktiboen %0.05 gutxi gorabehera argitaratzen dute, baina, hala ere, dagoeneko posta-trafiko bolumen handia babesten dute, izan ere. Estandarra eragile nagusiek onartzen dute: Google, Comcast eta neurri batean Verizon (AOL, Yahoo). Beste posta-zerbitzu askok iragarri dute etorkizun hurbilean estandarraren laguntza ezarriko dela.

Nola eragingo dit horrek?

Ez zure domeinuak MTA-STS politika bat argitaratzen ez badu. Politika argitaratzen baduzu, zure posta-zerbitzariaren erabiltzaileen mezu elektronikoak hobeto babestuko dira atzematetik.

Nola inplementatzen dut MTA-STS?

Hartzailearen aldean MTA-STS euskarria

Nahikoa da politika HTTPS eta erregistroak DNS bidez argitaratzea, CA fidagarrietako baten baliozko ziurtagiri bat konfiguratzea (zifra dezagun posible da) STARTTLS MTAn (STARTTLS MTA moderno guztietan onartzen da), ez dago laguntza berezirik. MTA beharrezkoa da.

Pausoz pauso, honela ikusten da:

  1. Konfiguratu STARTTLS erabiltzen ari zaren MTAn (postfixa, exim, sendmail, Microsoft Exchange, etab.).
  2. Ziurtatu baliozko ziurtagiri bat erabiltzen ari zarela (CA fidagarri batek emandakoa, iraungi gabea, ziurtagiriaren gaia zure domeinurako posta bidaltzen duen MX erregistroarekin bat datorrela).
  3. Konfiguratu TLS-RPT erregistro bat zeinaren bidez bidaliko diren politika-aplikazioen txostenak (TLS txostenak bidaltzea onartzen duten zerbitzuek). Sarrera adibidea (example.com domeinurako):
    smtp._tls.example.com. 300 IN TXT Β«v=TLSRPTv1;rua=mailto:[email protected]Β»

    Sarrera honek posta-igorleei SMTP-n TLS erabilerari buruzko txosten estatistikoak bidaltzeko agintzen die [email protected].

    Jarraitu txostenak hainbat egunez akatsik ez dagoela ziurtatzeko.

  4. Argitaratu MTA-STS politika HTTPS bidez. Gidalerroa testu-fitxategi gisa argitaratzen da CRLF lerro amaieradun kokapenen arabera.
    https://mta-sts.example.com/.well-known/mta-sts.txt
    

    Politika adibidea:

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

    Bertsio-eremuak politikaren bertsioa dauka (gaur egun STSv1), Moduak politika aplikatzeko modua ezartzen du, probak β€” proba modua (politika ez da aplikatzen), bete β€” β€œborroka” modua. Lehenik eta behin argitaratu politika moduarekin: probak, proba moduan politikarekin arazorik ez badago, pixka bat igaro ondoren modura alda dezakezu: betearazi.

    mx-n, zure domeinurako posta onar dezaketen posta-zerbitzari guztien zerrenda zehazten da (zerbitzari bakoitzak mx-n zehaztutako izenarekin bat datorren ziurtagiri bat izan behar du konfiguratuta). Max_age-k politikaren cache-denbora zehazten du (gogoratzen den politika aplikatuko denean, nahiz eta erasotzaileak bere entrega blokeatu edo DNS erregistroak hondatzen dituen cachean gordetzeko garaian, politika berriro eskatzeko beharra adierazi dezakezu mta-sts DNS-a aldatuz. erregistroa).

  5. Argitaratu TXT erregistro bat DNSn: 
    _mta-sts.example.com. TXT β€œv=STS1; id=someid;”
    

    Identifikatzaile arbitrario bat erabil dezakezu (adibidez, denbora-zigilua) id eremuan; politika aldatzen denean, aldatu beharko litzateke, honek igorleek cachean gordetako politika berriro eskatu behar dutela uler dezakete (identifikatzailea desberdina bada). cachean gordetako bat).

MTA-STS euskarria igorlearen aldetik

Orain arte berarekin txarra da, zeren... estandar freskoa.

"Derrigorrezko TLS"-ri buruzko hitzaurre gisa

Azkenaldian, erregulatzaileak arreta jartzen ari dira posta elektronikoaren segurtasunari (eta hori ona da). Esaterako, DMARC derrigorrezkoa da Estatu Batuetako gobernu-agentzia guztientzat eta gero eta gehiago eskatzen da finantza-sektorean, arauaren barneratzea % 90era iristen baita eremu arautuetan. Orain erregulatzaile batzuek domeinu indibidualekin "derrigorrezko TLS" ezartzea eskatzen dute, baina "derrigorrezko TLS" bermatzeko mekanismoa ez dago zehaztuta eta praktikan ezarpen hau sarritan ezartzen da, dagoeneko dauden benetako erasoetatik gutxien babesten ez duen moduan. DANE edo MTA-STS bezalako mekanismoetan aurreikusita.

Erregulatzaileak domeinu bereiziekin "derrigorrezko TLS" ezartzea eskatzen badu, MTA-STS edo bere analogo partziala mekanismorik egokienatzat hartzea gomendatzen dugu, domeinu bakoitzerako ezarpen seguruak bereizita egiteko beharra ezabatzen du. MTA-STS-ren bezeroaren zatia ezartzeko zailtasunak badituzu (protokoloak laguntza zabala jaso arte, ziurrenik egingo dute), ikuspegi hau gomenda dezakegu:

  1. Argitaratu MTA-STS politika eta/edo DANE erregistroak (DANEk zentzua du DNSSEC dagoeneko gaituta badago zure domeinurako, eta MTA-STS edozein kasutan), zure norabideko trafikoa babestuko du eta beste posta-zerbitzu batzuei galdetzeko beharra kenduko du. zure domeinurako derrigorrezko TLS konfiguratzeko, posta-zerbitzuak dagoeneko MTA-STS eta/edo DANE onartzen baditu.
  2. Posta elektronikoko zerbitzu handietarako, inplementatu MTA-STS-ren "analogiko" bat domeinu bakoitzeko garraio-ezarpen bereizien bidez, posta-bidaltzeko erabiltzen den MXa konponduko duena eta horretarako TLS ziurtagiria derrigorrezkoa egiaztatu beharko du. Domeinuek MTA-STS politika bat argitaratzen badute, ziurrenik hori minik gabe egin daiteke. Berez, domeinu baterako derrigorrezko TLS gaitzea erreleboa konpondu gabe eta horren ziurtagiria egiaztatzea ez da eraginkorra segurtasunaren ikuspuntutik eta ez die ezer gehitzen lehendik dauden STARTTLS mekanismoei.

Iturria: www.habr.com

Gehitu iruzkin berria