Shkurtimisht, MTA-STS është një mënyrë për të mbrojtur më tej emailet nga përgjimi (d.m.th., sulmet nga njeriu në mes të njohur si MitM) kur transmetohen midis serverëve të postës. Ai zgjidh pjesërisht problemet arkitekturore të protokolleve të postës elektronike dhe përshkruhet në standardin relativisht të fundit RFC 8461. Mail.ru është shërbimi i parë i madh i postës në RuNet që zbaton këtë standard. Dhe përshkruhet më në detaje nën prerje.

Çfarë problemi zgjidh MTA-STS?

Historikisht, protokollet e postës elektronike (SMTP, POP3, IMAP) transmetonin informacion në tekst të qartë, gjë që bëri të mundur përgjimin e tij, për shembull, kur hyni në një kanal komunikimi.

Si duket mekanizmi për dërgimin e një letre nga një përdorues te tjetri:

Historikisht, një sulm MitM ishte i mundur në të gjitha vendet ku qarkullonte posta.

RFC 8314 kërkon përdorimin e TLS midis aplikacionit të përdoruesit të postës (MUA) dhe serverit të postës. Nëse serveri juaj dhe aplikacionet e postës që përdorni janë në përputhje me RFC 8314, atëherë ju keni eliminuar (kryesisht) mundësinë e sulmeve Man-in-the-Middle midis përdoruesit dhe serverëve të postës.

Ndjekja e praktikave të pranuara përgjithësisht (të standardizuara nga RFC 8314) eliminon sulmin pranë përdoruesit:

Serverët e postës Mail.ru përputheshin me RFC 8314 edhe përpara se standardi të miratohej; në fakt, ai thjesht kap praktikat tashmë të pranuara dhe ne nuk na duhej të konfiguronim asgjë shtesë. Por, nëse serveri juaj i postës ende lejon përdoruesit të përdorin protokolle të pasigurta, sigurohuni që të zbatoni rekomandimet e këtij standardi, sepse Me shumë mundësi, të paktën disa nga përdoruesit tuaj punojnë me postë pa kriptim, edhe nëse e mbështesni atë.

Klienti i postës gjithmonë punon me të njëjtin server të postës së së njëjtës organizatë. Dhe ju mund t'i detyroni të gjithë përdoruesit të lidhen në një mënyrë të sigurt dhe më pas ta bëni teknikisht të pamundur lidhjen e përdoruesve jo të sigurt (kjo është pikërisht ajo që kërkon RFC 8314). Kjo ndonjëherë është e vështirë, por e realizueshme. Trafiku ndërmjet serverëve të postës është akoma më i ndërlikuar. Serverët i përkasin organizatave të ndryshme dhe shpesh përdoren në modalitetin "vendos dhe harro", gjë që e bën të pamundur kalimin në një protokoll të sigurt menjëherë pa ndërprerë lidhjen. SMTP ka ofruar prej kohësh zgjerimin STARTTLS, i cili lejon serverët që mbështesin enkriptimin të kalojnë në TLS. Por një sulmues që ka aftësinë të ndikojë në trafik mund të "shkëputë" informacionin në lidhje me mbështetjen për këtë komandë dhe t'i detyrojë serverët të komunikojnë duke përdorur një protokoll teksti të thjeshtë (i ashtuquajturi sulm i degradimit). Për të njëjtën arsye, STARTTLS zakonisht nuk kontrollon vlefshmërinë e certifikatës (një certifikatë e pabesueshme mund të mbrojë kundër sulmeve pasive, dhe kjo nuk është më e keqe se dërgimi i një mesazhi në tekst të qartë). Prandaj, STARTTLS mbron vetëm nga përgjimi pasiv.

MTA-STS eliminon pjesërisht problemin e përgjimit të letrave midis serverëve të postës, kur sulmuesi ka aftësinë të ndikojë në mënyrë aktive në trafik. Nëse domeni i marrësit publikon një politikë MTA-STS dhe serveri i dërguesit mbështet MTA-STS, ai do të dërgojë emailin vetëm përmes një lidhjeje TLS, vetëm te serverët e përcaktuar nga politika dhe vetëm me verifikimin e certifikatës së serverit.

Pse pjesërisht? MTA-STS funksionon vetëm nëse të dyja palët janë kujdesur për zbatimin e këtij standardi dhe MTA-STS nuk mbron nga skenarët në të cilët një sulmues është në gjendje të marrë një certifikatë të vlefshme domeni nga një prej CA-ve publike.

Si funksionon MTA-STS

marrës

Konfiguron mbështetjen STARTTLS me një certifikatë të vlefshme në serverin e postës.
Publikon politikën MTA-STS nëpërmjet HTTPS; një domen special mta-sts dhe një shteg special i mirënjohur përdoren për publikim, për shembull https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politika përmban një listë të serverëve të postës (mx) që kanë të drejtën të marrin postë për këtë domen.
Publikon një rekord të veçantë TXT _mta-sts në DNS me versionin e politikës. Kur politika ndryshon, kjo hyrje duhet të përditësohet (kjo i sinjalizon dërguesit që të rikërkojë politikën). Për shembull, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Dërguesi

Dërguesi kërkon rekordin DNS _mta-sts dhe nëse është i disponueshëm, bën një kërkesë për politikë nëpërmjet HTTPS (duke kontrolluar certifikatën). Politika që rezulton ruhet në memorie (në rast se një sulmues bllokon hyrjen në të ose fal rekordin DNS).

Kur dërgoni postë, kontrollohet që:

serveri në të cilin dërgohet posta është në politikë;
serveri pranon postën duke përdorur TLS (STARTTLS) dhe ka një certifikatë të vlefshme.

Përparësitë e MTA-STS

MTA-STS përdor teknologji që tashmë janë implementuar në shumicën e organizatave (SMTP+STARTTLS, HTTPS, DNS). Për zbatimin në anën e marrësit, nuk kërkohet mbështetje speciale softuerike për standardin.

Disavantazhet e MTA-STS

Është e nevojshme të monitorohet vlefshmëria e certifikatës së ueb-serverit të postës, korrespondenca e emrave dhe rinovimi në kohë. Problemet me certifikatën do të rezultojnë që posta të mos mund të dërgohet.

Nga ana e dërguesit, kërkohet një MTA me mbështetje për politikat MTA-STS; aktualisht, MTA-STS nuk mbështetet jashtë kutisë në MTA.

MTA-STS përdor një listë të CA-ve rrënjësore të besueshme.

MTA-STS nuk mbron nga sulmet në të cilat sulmuesi përdor një certifikatë të vlefshme. Në shumicën e rasteve, MitM pranë serverit nënkupton aftësinë për të lëshuar një certifikatë. Një sulm i tillë mund të zbulohet duke përdorur Transparencën e Certifikatës. Prandaj, në përgjithësi, MTA-STS zbut, por nuk e eliminon plotësisht mundësinë e përgjimit të trafikut.

Dy pikat e fundit e bëjnë MTA-STS më pak të sigurt se standardi konkurrues DANE për SMTP (RFC 7672), por teknikisht më i besueshëm, d.m.th. për MTA-STS ka një probabilitet të ulët që letra të mos dorëzohet për shkak të problemeve teknike të shkaktuara nga zbatimi i standardit.

Standardi konkurrues - DANE

DANE përdor DNSSEC për të publikuar informacionin e certifikatës dhe nuk kërkon besim tek autoritetet e jashtme të certifikatave, gjë që është shumë më e sigurt. Por përdorimi i DNSSEC në mënyrë të konsiderueshme më shpesh çon në dështime teknike, bazuar në statistikat gjatë disa viteve të përdorimit (edhe pse në përgjithësi ka një tendencë pozitive në besueshmërinë e DNSSEC dhe mbështetjen e tij teknike). Për të zbatuar DANE në SMTP nga ana e marrësit, prania e DNSSEC për zonën DNS është e detyrueshme dhe mbështetja e saktë për NSEC/NSEC3 është thelbësore për DANE, me të cilën ka probleme sistemike në DNSSEC.

Nëse DNSSEC nuk është konfiguruar saktë, mund të rezultojë në dështime të dërgimit të postës nëse pala dërguese mbështet DANE, edhe nëse pala marrëse nuk di asgjë për të. Prandaj, përkundër faktit se DANE është një standard më i vjetër dhe më i sigurt dhe tashmë mbështetet në disa softuer serverësh në anën e dërguesit, në fakt depërtimi i tij mbetet i parëndësishëm, shumë organizata nuk janë të gatshme ta zbatojnë atë për shkak të nevojës për të zbatuar DNSSEC. kjo ka ngadalësuar ndjeshëm zbatimin e DANE gjatë gjithë atyre viteve që standardi ka ekzistuar.

DANE dhe MTA-STS nuk bien ndesh me njëra-tjetrën dhe mund të përdoren së bashku.

Çfarë është me mbështetjen e MTA-STS në Mail.ru Mail?

Mail.ru ka publikuar një politikë MTA-STS për të gjitha fushat kryesore për mjaft kohë. Aktualisht jemi duke zbatuar pjesën e klientit të standardit. Në kohën e shkrimit, politikat aplikohen në një modalitet jo-bllokues (nëse dorëzimi bllokohet nga një politikë, letra do të dorëzohet përmes një serveri "rezervë" pa aplikuar politika), atëherë mënyra e bllokimit do të detyrohet për një pjesë të vogël e trafikut dalës SMTP, gradualisht për 100% të trafikut do të mbështetet zbatimi i politikave.

Kush tjetër e mbështet standardin?

Deri më tani, politikat MTA-STS publikojnë afërsisht 0.05% të domeneve aktive, por, megjithatë, ato tashmë mbrojnë një vëllim të madh të trafikut të postës, sepse Standardi mbështetet nga lojtarët kryesorë - Google, Comcast dhe pjesërisht Verizon (AOL, Yahoo). Shumë shërbime të tjera postare kanë njoftuar se mbështetja për standardin do të zbatohet në të ardhmen e afërt.

Si do të ndikojë kjo tek unë?

Jo nëse domeni juaj nuk publikon një politikë MTA-STS. Nëse publikoni politikën, emailet për përdoruesit e serverit tuaj të postës do të mbrohen më mirë nga përgjimi.

Si të zbatoj MTA-STS?

Mbështetje MTA-STS nga ana e marrësit

Mjafton të publikoni politikën përmes HTTPS dhe regjistrimet në DNS, të konfiguroni një certifikatë të vlefshme nga një prej CA-ve të besuara (Le të kripojmë është e mundur) për STARTTLS në MTA (STARTTLS mbështetet në të gjitha MTA-të moderne), asnjë mbështetje speciale nga MTA kërkohet.

Hap pas hapi, duket kështu:

Konfiguro STARTTLS në MTA që po përdorni (postfix, exim, sendmail, Microsoft Exchange, etj.).
Sigurohuni që jeni duke përdorur një certifikatë të vlefshme (e lëshuar nga një CA e besuar, e pa skaduar, subjekti i certifikatës përputhet me rekordin MX që dërgon postën për domenin tuaj).
Konfiguro një rekord TLS-RPT përmes të cilit do të dorëzohen raportet e aplikimit të politikave (nga shërbimet që mbështesin dërgimin e raporteve TLS). Shembull i hyrjes (për domenin shembull.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Kjo hyrje udhëzon dërguesit e postës që të dërgojnë raporte statistikore mbi përdorimin e TLS në SMTP [email protected].

Monitoroni raportet për disa ditë për t'u siguruar që nuk ka gabime.
Publikoni politikën MTA-STS mbi HTTPS. Politika publikohet si një skedar teksti me terminatorë të linjës CRLF sipas vendndodhjes.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Shembull i politikës:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Fusha e versionit përmban versionin e politikës (aktualisht STSv1), Modaliteti vendos modalitetin e aplikimit të politikës, testimi - modaliteti i testimit (politika nuk zbatohet), zbatimi - modaliteti "luftarak". Fillimisht publikoni politikën me modalitetin: testimi, nëse nuk ka probleme me politikën në modalitetin e testimit, pas një kohe mund të kaloni në modalitetin: zbato.

Në mx, specifikohet një listë e të gjithë serverëve të postës që mund të pranojnë postë për domenin tuaj (çdo server duhet të ketë një certifikatë të konfiguruar që përputhet me emrin e specifikuar në mx). Max_age specifikon kohën e ruajtjes në memorie të politikës (pasi politika e mbajtur mend do të zbatohet edhe nëse sulmuesi bllokon dorëzimin e saj ose korrupton të dhënat DNS gjatë kohës së memorizimit, mund të sinjalizoni nevojën për të kërkuar përsëri politikën duke ndryshuar mta-sts DNS rekord).
Publikoni një rekord TXT në DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Një identifikues arbitrar (për shembull, një vulë kohore) mund të përdoret në fushën id; kur politika ndryshon, ajo duhet të ndryshojë, kjo i lejon dërguesit të kuptojnë se duhet të rikërkojnë politikën e ruajtur në memorie (nëse identifikuesi është i ndryshëm nga një i ruajtur në memorie).

Mbështetje MTA-STS në anën e dërguesit

Deri më tani është keq me të, sepse ... standard i freskët.

Exim - nuk ka mbështetje të integruar, ekziston një skenar i palës së tretë https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - nuk ka mbështetje të integruar, ekziston një skript i palës së tretë i cili përshkruhet në detaje në Habré https://habr.com/en/post/424961/

Si pasthënie për "TLS të detyrueshme"

Kohët e fundit, rregullatorët i kanë kushtuar vëmendje sigurisë së emailit (dhe kjo është një gjë e mirë). Për shembull, DMARC është i detyrueshëm për të gjitha agjencitë qeveritare në Shtetet e Bashkuara dhe kërkohet gjithnjë e më shumë në sektorin financiar, me depërtimin e standardit që arrin 90% në zonat e rregulluara. Tani disa rregullatorë kërkojnë zbatimin e "TLS të detyrueshme" me domene individuale, por mekanizmi për të siguruar "TLS të detyrueshme" nuk është i përcaktuar dhe në praktikë ky cilësim zbatohet shpesh në një mënyrë që as minimalisht nuk mbron nga sulmet reale që janë tashmë. parashikuar në mekanizma të tillë si DANE ose MTA-STS.

Nëse rregullatori kërkon zbatimin e "TLS të detyrueshme" me domene të veçanta, ju rekomandojmë të konsideroni MTA-STS ose analogun e tij të pjesshëm si mekanizmin më të përshtatshëm, ai eliminon nevojën për të bërë cilësime të sigurta për secilin domen veç e veç. Nëse keni vështirësi në zbatimin e pjesës së klientit të MTA-STS (derisa protokolli të ketë marrë mbështetje të gjerë, ata me shumë mundësi do ta kenë), ne mund të rekomandojmë këtë qasje:

Publikoni një politikë MTA-STS dhe/ose regjistrime DANE (DANE ka kuptim vetëm nëse DNSSEC është aktivizuar tashmë për domenin tuaj, dhe MTA-STS në çdo rast), kjo do të mbrojë trafikun në drejtimin tuaj dhe do të eliminojë nevojën për të kërkuar shërbime të tjera postare për të konfiguruar TLS të detyrueshme për domenin tuaj nëse shërbimi i postës tashmë mbështet MTA-STS dhe/ose DANE.
Për shërbimet e mëdha të postës elektronike, zbatoni një "analog" të MTA-STS përmes cilësimeve të veçanta të transportit për secilin domen, i cili do të rregullojë MX-në e përdorur për transmetimin e postës dhe do të kërkojë verifikimin e detyrueshëm të një certifikate TLS për të. Nëse domenet tashmë publikojnë një politikë MTA-STS, kjo ka të ngjarë të bëhet pa dhimbje. Në vetvete, aktivizimi i TLS-së së detyrueshme për një domen pa rregullimin e stafetës dhe verifikimin e certifikatës për të është i paefektshëm nga pikëpamja e sigurisë dhe nuk shton asgjë në mekanizmat ekzistues STARTTLS.

Burimi: www.habr.com

Posta Mail.ru fillon të zbatojë politikat MTA-STS në modalitetin e testimit