Shkurtimisht, MTA-STS është një mënyrë për të mbrojtur shtesë email-et nga përgjimi gjatë transmetimit midis serverëve të postës (pra, nga sulmet man-in-the-middle, aka MitM). Ai zgjidh pjesërisht problemet e trashëguara arkitekturore të protokolleve të email-it dhe përshkruhet në standardin relativisht të ri RFC 8461. Mail.ru Mail është shërbimi i parë i madh i postës në Runet që zbaton këtë standard. Më poshtë gjeni shpjegimin më të detajuar.

Çfarë problemi zgjidh MTA-STS?

Historikisht, protokollet e postës elektronike (SMTP, POP3, IMAP) e transmetonin informacionin në formë të hapur, gjë që lejonte përgjimin e tij, për shembull kur ka qasje në kanalin e komunikimit.

Ja si duket mekanizmi i dorëzimit të një email-i nga një përdorues te tjetri:

Historikisht, sulmet MitM kanë qenë të mundshme në të gjitha pikat ku kalon posta elektronike.

Standardi RFC 8314 kërkon përdorimin e detyrueshëm të TLS midis programit të postës së përdoruesit (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 në masë të madhe mundësinë e sulmeve Man-in-the-Middle midis përdoruesit dhe serverëve të postës.

Zbatimi i praktikave të pranuara gjerësisht (të standardizuara në RFC 8314) eliminon sulmin pranë përdoruesit:

Serverët e postës së Mail.ru ishin në përputhje me RFC 8314 edhe para miratimit të standardit; në fakt, ai thjesht formalizon praktikat e zbatuara tashmë, ndaj nuk na u desh të konfiguronim asgjë shtesë. Por nëse serveri juaj i postës ende i lejon përdoruesit të lidhen përmes protokolleve të pasigurta, zbatoni patjetër rekomandimet e këtij standardi, sepse ka shumë gjasa që të paktën një pjesë e përdoruesve tuaj të punojnë me postën pa enkriptim, edhe nëse ju e mbështesni atë.

Klienti i postës punon gjithmonë me të njëjtin server postar të së njëjtës organizatë. Prandaj, mund të detyrohen të gjithë përdoruesit të lidhen në mënyrë të sigurt dhe më pas të bëhet teknikisht e pamundur lidhja në mënyrë të pasigurt (pikërisht këtë kërkon RFC 8314). Kjo ndonjëherë është e vështirë, por e realizueshme. Me trafikun ndërmjet serverëve postarë situata është edhe më e ndërlikuar. Serverët u përkasin organizatave të ndryshme dhe shpesh përdoren sipas parimit «konfiguro dhe harro», gjë që e bën të pamundur kalimin e menjëhershëm në një protokoll të sigurt pa cenuar lidhshmërinë. Në SMTP prej kohësh ekziston zgjerimi STARTTLS, i cili u lejon serverëve që mbështesin enkriptimin të kalojnë në TLS. Por një sulmues që ka mundësi të ndikojë në trafik mund të «heqë» informacionin për mbështetjen e kësaj komande dhe t’i detyrojë serverët të komunikojnë përmes protokollit të zakonshëm me tekst të hapur (i ashtuquajturi downgrade attack — sulm për uljen e versionit të protokollit). Për të njëjtën arsye, te STARTTLS zakonisht nuk verifikohet përputhshmëria e certifikatës (një certifikatë e pabesuar mund të mbrojë nga sulmet pasive dhe kjo nuk është më keq sesa dërgimi i emailit në tekst të hapur). Prandaj STARTTLS mbron vetëm nga përgjimi pasiv.

MTA-STS e zbut pjesërisht problemin e kapjes së email-eve ndërmjet serverëve postarë, kur sulmuesi ka mundësi të ndikojë aktivisht në trafik. Nëse domeni i marrësit publikon një politikë MTA-STS dhe serveri i dërguesit mbështet MTA-STS, ai do ta dërgojë emailin vetëm përmes një lidhjeje TLS, vetëm te serverët e përcaktuar nga politika dhe vetëm me verifikim të certifikatës së serverit.

Pse vetëm 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 sulmuesi ka mundësi të marrë një certifikatë të vlefshme të domenit nga një prej CA-ve publike.

Si funksionon MTA-STS

Marrësi

1. Konfiguron mbështetjen e STARTTLS me një certifikatë të vlefshme në serverin postar. 
2. Publikon përmes HTTPS politikën MTA-STS; për publikim përdoret domeni i posaçëm mta-sts dhe rruga speciale well-known, për shembull https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politika përmban një listë të serverëve postarë (mx) që kanë të drejtë të marrin postë për këtë domen.
3. Publikon një regjistrim të posaçëm TXT _mta-sts në DNS me versionin e politikës. Kur politika ndryshon, ky regjistrim duhet të përditësohet (kjo i sinjalizon dërguesit se politika duhet të kërkohet sërish). Për shembull, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Dërguesi

Dërguesi kërkon regjistrimin DNS _mta-sts; nëse ai ekziston, bën një kërkesë për politikën përmes HTTPS (duke verifikuar certifikatën). Politika e marrë ruhet në cache (në rast se një sulmues bllokon qasjen tek ajo ose zëvendëson regjistrimin DNS).

Gjatë dërgimit të postës verifikohet që:

• serveri ku dorëzohet posta të jetë i përfshirë 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ë zbatuar në shumicën e organizatave (SMTP+STARTTLS, HTTPS, DNS). Për zbatimin nga ana e marrësit nuk kërkohet mbështetje e posaçme softuerike për këtë standard.

Mangësitë e MTA-STS

Duhet të monitorohet vlefshmëria e certifikatës së serverit web dhe atij të postës, përputhshmëria e emrave dhe përditësimi në kohë. Problemet me certifikatën do ta bëjnë të pamundur dorëzimin e postës.

Nga ana e dërguesit kërkohet një MTA me mbështetje për politikat MTA-STS; aktualisht MTA-STS nuk mbështetet "out of the box" në MTA.

MTA-STS përdor një listë të CA rrënjë të besuara.

MTA-STS nuk mbron nga sulmet ku sulmuesi përdor një certifikatë të vlefshme. Në shumicën e rasteve, MitM pranë serverit nënkupton mundësinë e lëshimit të një certifikate. Një sulm i tillë mund të zbulohet përmes Certificate Transparency. Prandaj, në tërësi, MTA-STS e 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 më të besueshëm nga ana teknike, pra për MTA-STS probabiliteti që email-i të mos dorëzohet për shkak të problemeve teknike të shkaktuara nga zbatimi i standardit është i ulët.

Standardi konkurrues — DANE

DANE përdor DNSSEC për të publikuar informacion mbi certifikatat dhe nuk kërkon besim te autoritetet e jashtme të certifikimit, gjë që është dukshëm më e sigurt. Megjithatë, përdorimi i DNSSEC çon shumë më shpesh në dështime teknike, nëse mbështetemi te statistikat e disa viteve të përdorimit (edhe pse në besueshmërinë e DNSSEC dhe mbështetjen e tij teknike në përgjithësi vërehet një prirje pozitive). Për zbatimin e DANE në SMTP nga ana e marrësit, prania e DNSSEC për zonën DNS është e detyrueshme, ndërsa për DANE është thelbësore mbështetja korrekte e NSEC/NSEC3, me të cilën DNSSEC ka probleme sistemike.

Nëse DNSSEC është konfiguruar me gabime, kjo mund të çojë në dështime të dorëzimit të postës, nëse pala dërguese mbështet DANE, edhe nëse pala marrëse nuk di asgjë për të. Prandaj, edhe pse DANE është një standard më i vjetër dhe më i sigurt dhe tashmë mbështetet nga një pjesë e softuerit të serverëve në anën e dërguesit, në praktikë përhapja e tij mbetet e kufizuar. Shumë organizata nuk janë të gatshme ta zbatojnë për shkak të nevojës për të implementuar DNSSEC, dhe kjo e ka ngadalësuar ndjeshëm adoptimin e DANE gjatë gjithë viteve të ekzistencës së këtij standardi.

DANE dhe MTA-STS nuk bien në konflikt me njëri-tjetrin dhe mund të përdoren së bashku.

Si qëndron mbështetja për MTA-STS në Mail.ru

Mail.ru ka kohë që publikon politikën MTA-STS për të gjitha domenet kryesore. Aktualisht po punojmë për zbatimin e pjesës klient të standardit. Në momentin e shkrimit të artikullit, politikat zbatohen në modalitet jo-bllokues (nëse dorëzimi bllokohet nga politika, emaili do të dorëzohet përmes një serveri «rezervë» pa zbatimin e politikave), më pas do të aktivizohet modaliteti bllokues për një pjesë të vogël të trafikut dalës SMTP dhe gradualisht zbatimi i politikave do të mbulojë 100% të trafikut.

Kush tjetër e mbështet standardin

Për momentin, politikat MTA-STS publikohen nga rreth 0.05% e domeneve aktive, por megjithatë ato tashmë mbrojnë një vëllim të madh të trafikut të emailit, sepse standardi mbështetet nga lojtarë të mëdhenj si Google, Comcast dhe pjesërisht Verizon (AOL, Yahoo). Shumë shërbime të tjera të postës kanë deklaruar se mbështetja për standardin do të zbatohet në të ardhmen e afërt.

Si do të më ndikojë kjo?

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

Si ta zbatoj MTA-STS?

Mbështetja e MTA-STS në anën e marrësit

Mjafton të publikoni politikën përmes HTTPS dhe regjistrimeve në DNS, të konfiguroni një certifikatë të vlefshme nga një prej CA-ve të besuara (mund të përdorni edhe Let’s Encrypt) për STARTTLS në MTA (STARTTLS mbështetet nga të gjitha MTA moderne); nuk kërkohet mbështetje e veçantë nga ana e MTA-së.

Hap pas hapi, kjo duket kështu:

1. Konfiguroni STARTTLS në MTA që përdorni (postfix, exim, sendmail, Microsoft Exchange, etj.).
2. Sigurohuni që të përdoret një certifikatë e vlefshme (e lëshuar nga një CA i besuar, jo e skaduar, subjekti i certifikatës përputhet me regjistrimin MX përmes të cilit dorëzohet posta për domenin tuaj).
3. Konfiguroni regjistrimin TLS-RPT, përmes të cilit do të dërgohen raportet për zbatimin e politikave (nga shërbimet që mbështesin dërgimin e raporteve TLS). Shembull regjistrimi (për domenin example.com):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»

   Ky regjistrim u udhëzon dërguesve të postës të dërgojnë raporte statistikore për përdorimin e TLS në SMTP në adresën tlsrpt@exmple.com.

   Ndiqni raportet për disa ditë dhe sigurohuni që nuk ka gabime.

4. Publikoni politikën MTA-STS përmes HTTPS. Politika publikohet si një skedar teksti me terminatorë rreshtash CRLF në vendndodhjen:

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   Shembull politike:

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

   Fusha version përmban versionin e politikës (aktualisht është STSv1), Mode përcakton mënyrën e zbatimit të politikës: testing është mënyra e testimit (politika nuk zbatohet), ndërsa enforce është mënyra e plotë e zbatimit. Fillimisht publikoni politikën me mode: testing; nëse gjatë testimit nuk shfaqen probleme, pas një kohe mund ta kaloni në mode: enforce.

   Te mx përcaktohet lista e të gjithë serverëve të postës që mund të pranojnë postë për domenin tuaj (në secilin server duhet të konfigurohet një certifikatë që përputhet me emrin e caktuar në mx). Max_age përcakton kohën e ruajtjes në cache të politikës (një politikë e ruajtur do të zbatohet edhe nëse një sulmues bllokon dorëzimin e saj ose prish regjistrimet DNS gjatë periudhës së cache; nevoja për ta kërkuar sërish politikën mund të sinjalizohet përmes ndryshimit të regjistrimit DNS mta-sts).

5. Publikoni një regjistrim TXT në DNS: 

   _mta-sts.example.com. TXT “v=STS1; id=someid;”
   

   Në fushën id mund të përdoret një identifikues arbitrar (për shembull, një shenjë kohore); kur politika ndryshon, ai duhet të ndryshojë gjithashtu. Kjo u lejon dërguesve të kuptojnë se duhet të rikërkojnë politikën e ruajtur në cache (nëse identifikuesi ndryshon nga ai i cache).

Mbështetja e MTA-STS nga ana e dërguesit

Për momentin, situata nuk është e mirë, sepse standardi është i ri.

• Exim — nuk ka mbështetje të integruar, ka një skript nga palë të treta https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix — nuk ka mbështetje të integruar, ka një skript nga palë të treta për të cilin është shpjeguar hollësisht në Habr https://habr.com/en/post/424961/

Si përfundim, disa fjalë për «mandatory TLS»

Kohët e fundit, rregullatorët po i kushtojnë vëmendje sigurisë së email-it (dhe kjo është gjë e mirë). Për shembull, DMARC është i detyrueshëm për të gjitha institucionet shtetërore në SHBA dhe po kërkohet gjithnjë e më shpesh në sektorin financiar; në fushat e rregulluara, përhapja e standardit arrin në 90%. Tani disa rregullatorë kërkojnë zbatimin e «mandatory TLS» me domene të veçanta, por mekanizmi për garantimin e «mandatory TLS» nuk përcaktohet, dhe në praktikë ky konfigurim shpesh zbatohet në një mënyrë që nuk mbron as minimalisht nga sulmet reale, të cilat tashmë mbulohen nga mekanizma si DANE ose MTA-STS.

Nëse rregullatori kërkon zbatimin e «mandatory TLS» me domene të veçanta, ne rekomandojmë të shqyrtoni 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ë konfigurime të sigurta për secilin domen veçmas. Nëse keni vështirësi me zbatimin e pjesës klient të MTA-STS (për sa kohë që protokolli ende nuk ka marrë mbështetje të gjerë, me shumë gjasë do t’i hasni), mund të rekomandohet kjo qasje:

1. Publikoni politikën MTA-STS dhe/ose regjistrimet DANE (DANE ka kuptim të shtohet vetëm nëse DNSSEC është tashmë i aktivizuar për domenin tuaj, ndërsa MTA-STS në çdo rast); kjo do të mbrojë trafikun hyrës drejt jush dhe do t’ju lirojë nga nevoja për t’u kërkuar shërbimeve të tjera të postës të konfigurojnë mandatory TLS për domenin tuaj, nëse shërbimi i postës tashmë mbështet MTA-STS dhe/ose DANE.
2. Për shërbime të mëdha email-i, zbatoni një “analog” të MTA-STS përmes cilësimeve të veçanta të transportit për secilin domen, të cilat do të fiksojnë MX-in e përdorur për relay të postës dhe do të kërkojnë për të verifikim të detyrueshëm të certifikatës TLS. Nëse domenet tashmë publikojnë politikën MTA-STS, kjo me shumë gjasa mund të bëhet pa probleme. Aktivizimi i TLS të detyrueshëm për një domen, pa fiksim të relay-t dhe pa verifikimin e certifikatës për të, në vetvete është joefektiv nga pikëpamja e sigurisë dhe nuk shton asgjë ndaj mekanizmave ekzistues të STARTTLS.

Burimi: habr.com