Nëse e përmbledhim, MTA-STS është një mënyrë për të mbrojtur shtesë email-et nga kapja (dmth. sulmet e njeriut në mes aka MitM) gjatë transmetimit midis serverëve të email-it. Ai zgjidh pjesërisht problemet arkitektonike të trashëguara të protokolleve të email-it dhe është përshkruar në standardin relativisht të ri RFC 8461. Mail.ru është shërbimi i parë i madh i email-it në Rusi që implementon këtë standard. Një përshkrim më i hollësishëm jepet më poshtë.

Cilën problem zgjidh MTA-STS?

Historikisht, protokollet e email-it (SMTP, POP3, IMAP) transmetonin informacionin në formë të hapur, duke e bërë atë të ndjeshëm ndaj kapjes, për shembull, gjatë qasjes në kanalin e komunikimit.

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

Historikisht, sulmi MitM ka qenë i mundshëm në të gjitha vendet ku kalon posta.

Standardi RFC 8314 kërkon përdorimin e detyrueshëm të TLS mes programit të përdoruesit të email-it (MUA) dhe serverit të email-it. Nëse serveri juaj dhe aplikacionet e email-it që përdorni përputhen me RFC 8314, atëherë ju (në masë të konsiderueshme) keni eliminuar mundësinë për sulme Man-in-the-Middle midis përdoruesit dhe serverëve të email-it.

Respektimi i praktikave të pranuara (RFC 8314 të standardizuara) eliminon sulmet afër përdoruesit:

Serverët e postës Mail.ru kanë përmbushur RFC 8314 edhe para miratimit të standardit; në fakt, ai thjesht fikson praktikat e pranuara, dhe nuk na duhej të bënim ndonjë konfigurim shtesë. Por, nëse serveri juaj i postës ende lejon përdoruesit të hyjnë përmes protokolleve të pasigurta, sigurohuni që të zbatosh rekomandimet e këtij standardi, pasi ka shumë të ngjarë që të paktën një pjesë e përdoruesve tuaj punojnë me postë pa enkriptim, edhe nëse ju e mbështesni atë.

Почтовый клиент всегда работает с одним и тем же почтовым сервером одной и той же организации. И можно принудительно заставить всех пользователей подключаться безопасным образом, после чего сделать технически невозможным подключаться небезопасным (это как раз и требует RFC 8314). Это иногда сложно, но реализуемо. С трафиком между почтовыми серверами все еще сложней. Серверы принадлежат разным организациям и зачастую используются в режиме «поставил и забыл», что делает невозможным одномоментное переключение на безопасный протокол без нарушения связности. В SMTP уже достаточно давно предусмотрено расширение STARTTLS, позволяющее серверам поддерживающим шифрование переключиться на TLS. Но атакующий, у которого есть возможно влиять на трафик, может «вырезать» информацию о поддержке этой команды и заставить серверы общаться по обычному текстовому протоколу (т.н. downgrade attack — атака на понижение версии протокола). По этой же причине, для STARTTLS обычно не проверяется соответствие сертификата (недоверенный сертификат может защищать от пассивных атак, и это не хуже отправки письма открытым текстом). Поэтому STARTTLS защищает только от пассивной прослушки.

MTA-STS pjesërisht zbut problemin e ndërhyrjes së mesazheve midis serverëve të email-it, kur sulmuesi ka mundësinë të ndikojë aktivisht në trafikun. Nëse domeni i marrësit publikojnë një politikë MTA-STS, dhe serveri i dërguesit mbështet MTA-STS, ai do të dërgojë mesazhin vetëm përmes një lidhjeje TLS, vetëm në serverët e përcaktuar nga politika, dhe vetëm pas verifikimit të certifikatës së serverit.

Pse pjesërisht? MTA-STS funksionon vetëm nëse të dy anët janë kujdesur për zbatimin e këtij standardi, dhe MTA-STS nuk mbron nga skenarët ku sulmuesi ka mundësinë të marrë një certifikatë valide të domenit nga ndonjë nga CA-të publike.

Si funksionon MTA-STS

Marrësi

1. Konfiguron mbështetje për STARTTLS me një certifikatë valide në serverin e email-it. 
2. Publikon politikën MTA-STS përmes HTTPS, për publikimin përdoret një domen i veçantë mta-sts dhe një rrugë e njohur e veçantë, për shembull https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politika përmban një listë të serverëve të email-it (mx) që kanë të drejta për të marrë email për këtë domen.
3. Publikon një regjistrim të veçantë TXT _mta-sts në DNS me versionin e politikës. Kur politika ndryshohet, ky regjistrim duhet të azhurnohet (kjo sinjalizon dërguesin për nevojën për të rikërkuar politikën). Për shembull, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Dërguesi

Dërguesi kërkon regjistrimin DNS _mta-sts, dhe nëse ka një të tillë, bën një kërkesë për politikën përmes HTTPS (duke verifikuar certifikatën). Politika e marrë ruhet në cache (për rastin nëse sulmuesi bllokon qasjen në të ose ndërron regjistrimin DNS).

Kur dërgohet postë, kontrollohet që:

• serveri, ku dërgohet posta, është në politikë;
• serveri pranon postë duke përdorur TLS (STARTTLS) dhe ka një certifikatë valide.

Përfitimet e MTA-STS

MTA-STS përdor teknologji që janë tashmë të implementuara në shumicën e organizatave (SMTP+STARTTLS, HTTPS, DNS). Për realizimin në anën e marrësit nuk kërkohet mbështetje e veçantë programore për standardin.

Disavantazhet e MTA-STS

Duhet të monitoroni vlefshmërinë e certifikatës së serverit të uebit dhe postës, përputhshmërinë e emrave, dhe përditësimin e saj në kohë. Problemet me certifikatën do të çojnë në pamundësinë për të dërguar postë.

Në anën e dërguesit, kërkohet një MTA me mbështetje për politikat MTA-STS; për momentin, MTA-STS nuk mbështetet "nga kutia" në MTA.

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

MTA-STS nuk mbron nga sulmet ku sulmuesi përdor një certifikatë valide. Në shumicën e rasteve, MitM afër serverit nënkupton mundësinë e lëshimit të një certifikate. Një sulm i tillë mund të zbulohet përmes Transparency të Certifikatave. Prandaj, në përgjithësi, MTA-STS mitigon, por nuk e eliminon plotësisht mundësinë e kapjes së trafikut.

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

Standardi konkurrues është DANE

DANE përdor DNSSEC për të publikuar informacion rreth certifikatave dhe nuk kërkon besim në autoritetet e jashtme të certifikimit, që është shumë më të sigurta. Por përdorimi i DNSSEC shpesh çon në defekte teknike, nëse mbështetet në statistikat e disa viteve të përdorimit (edhe pse është vënë re një dinamikë pozitive në besueshmërinë e DNSSEC dhe mbështetje teknike të tij). Për të implementuar DANE në SMTP në anën e marrësit, prania e DNSSEC për zonën DNS është e domosdoshme, dhe për DANE mbështetje korrekte e NSEC/NSEC3 është thelbësore, për 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 ana dërguese mbështet DANE, edhe nëse ana pranuese nuk e di asgjë rreth tij. Prandaj, përkundër faktit se DANE është një standart më i vjetër dhe i sigurt dhe tashmë mbështetet në disa programe serveri në anën e dërguesit, në praktikë depërtimi i tij mbetet i pakët; shumë organizata nuk janë të gatshme ta implementojnë atë për shkak të nevojës për të implementuar DNSSEC, këtë e ka ngadalësuar ndjeshëm implementimin e DANE për gjithë vitet që egziston standardi.

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

Çfarë ndodh me mbështetje për MTA-STS në Mail.ru?

Mail.ru ka publikuar politikën MTA-STS për të gjitha domain-t kryesore për një kohë të gjatë. Tani jemi duke punuar për zbatimin e pjesës klientit të standardit. Në momentin kur u shkrua ky artikull, politikat aplikohen në një modë jo bllokuese (nëse dorëzimi bllokohet nga politika, letra do të dorëzohet përmes një serveri 'rezervë' pa përdorur politikat), dhe më pas do të detyrohet të aplikohet një modë bllokuese për një pjesë të vogël të trafikut SMTP të dërguar, gradualisht për 100% të trafikut do të mbështetet aplikimi i politikave.

Kush tjetër e mbështet standardin?

Aktualisht, politikat MTA-STS po publikohen nga rreth 0.05% e domain-eve aktive, por megjithatë, ato tashmë mbrojnë një volum të madh të trafikut të postës elektronike, pasi standardi mbështetet nga lojtarë të mëdhenj - Google, Comcast dhe pjesërisht Verizon (AOL, Yahoo). Shërbime të tjera të postës elektronike kanë njoftuar se mbështetje për standardin do të realizohet në të ardhmen e afërt.

Si do të më ndikojë?

Asnjëherë, nëse domaini juaj nuk publikon një politikë MTA-STS. Nëse publikoni një politikë, atëherë emailat për përdoruesit e serverit tuaj të postës do të jenë më të sigurt nga ndërhyrjet.

Si mund ta implementoj MTA-STS?

Mbështetje për MTA-STS në anën e marrësit

Në mënyrë të mjaftueshme për të publikuar një politikë përmes HTTPS dhe regjistrimeve në DNS, duke konfiguruar një certifikat të vlefshme nga një nga CA të besueshme (mund të përdorni Let’s Encrypt) për STARTTLS në MTA (STARTTLS mbështetet në të gjithë MTA të sotëm), mbështetje të veçantë nga MTA nuk kërkohet.

Hapat, duken si vijon:

1. Konfiguroni STARTTLS në MTA-në që po përdorni (postfix, exim, sendmail, Microsoft Exchange etj.).
2. Sigurohuni që të përdoret një certifikat e vlefshme (e lëshuar nga një CA të besueshme, e pa skaduar, subjekti i certifikatës përputhet me regjistrin MX për të cilin dërgohet posta për domainin tuaj).
3. Konfiguroni një regjistrim TLS-RPT, mbi të cilin do të dërgohen raportet për zbatimin e politikave (nga shërbimet që mbështesin dërgimin e raporteve TLS). Një shembull regjistrimi (për domainin example.com):

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

   Ky regjistrim udhëzon dërguesit e emailit të dërgojnë raportet statistikore mbi përdorimin e TLS në SMTP në adresën tlsrpt@exmple.com.

   Ndjekni raportet për disa ditë, sigurohuni që të mos ketë gabime.

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

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

   Shembulli i politikës:

   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 kjo është STSv1), Mode përcakton mënyrën e përdorimit të politikës, testing — mënyrë testimi (politika nuk aplikohet), enforce — mënyrë operimi. Së pari, publikoni politikën me mode: testing, nëse nuk ka probleme me politikën në mënyrën testuese, pas një kohe mund të kaloni në mode: enforce.

   Në mx jepet lista e të gjithë serverëve të postës që mund të pranojnë postë për domenin tuaj (çdo server duhet të ketë të konfiguruar një sertifikat që përputhet me emrin e caktuar në mx). Max_age përcakton kohën e cache-it të politikës (një herë e mbajtur politika do të aplikohet edhe nëse sulmuesi e bllokon kthimin e saj ose dëmtuan regjistrimet e DNS-së gjatë kohës së cache-it, sinjalizimi për nevojën për të kërkuar sërish politikën mund të bëhet përmes ndryshimit të regjistrimit mta-sts DNS).

5. Publikoni në DNS një regjistrim TXT: 

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

   Në fushën id mund të përdoret një identifikues i rastësishëm (p.sh. marka e kohës), kur politika ndryshon ai duhet të ndryshohet, kjo lejon dërguesit të kuptojnë se duhet të rifreskohet politika e cache-uar (nëse identifikuesi ndryshon nga ai i cache-it).

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

Aktualisht nuk është mirë, pasi standardi është i ri.

• Exim - nuk ka mbështetje të integruar, ka një skenar të jashtëm. https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - nuk ka mbështetje të integruar, ka një skenar të jashtëm për të cilin flitet gjerësisht në Habr. https://habr.com/en/post/424961/

Si një pasthënie në lidhje me «TLS të detyrueshëm»

Në kohët e fundit, rregullatorët po i kushtojnë vëmendje sigurisë së postës (dhe kjo është 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ë shumë në sektorin financiar; në fushat e rregulluara, përhapja e standardit arrin 90%. Aktualisht, disa rregullatorë kërkojnë zbatimin e «TLS të detyrueshëm» me domene të veçanta, por mekanizmi për sigurimin e «TLS të detyrueshëm» nuk përcaktohet dhe në praktikë kjo konfigurim shpesh zbatohen në një mënyrë që as minimalisht nuk mbron nga sulmet reale, të cilat tashmë parashikohen në mekanizma si DANE ose MTA-STS.

Nëse rregullatori kërkon zbatimin e «mandatory TLS» me domaine të veçanta, ne rekomandojmë të shqyrtoni MTA-STS ose një analog të tij si mekanizmin më të përshtatshëm, sepse ai eliminon nevojën për të bërë konfigurime të sigurta për çdo domain veçmas. Nëse keni vështirësi në zbatimin e pjesës klient MTA-STS (ndërsa protokolli nuk ka marrë mbështetje të gjerë, ato do të jenë ndoshta të pranishme), mund të rekomandohet një qasje të tillë:

1. Publikoni politikën MTA-STS dhe/ose regjistrat DANE (DANE ka kuptim të shtohet vetëm nëse për domenin tuaj është aktivizuar DNSSEC, ndërsa MTA-STS është gjithsesi i nevojshëm), kjo do të mbrojë trafikun në drejtimin tuaj dhe do të eliminojë nevojën për të kërkuar nga shërbimet e 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ërbimet e mëdha të postës, implementoni një "analog" të MTA-STS përmes cilësimeve të veçanta të transportit për çdo domain, që do të përcaktojë MX-në e përdorur për relen e postës dhe do të kërkojë verifikimin e detyrueshëm të certifikatës TLS për të. Nëse domainet tashmë publikojnë një politikë MTA-STS, kjo, me siguri, mund të bëhet pa probleme. Aktivizimi i TLS-it të detyruar për një domain pa caktimin e relen dhe verifikimin e certifikatës për të është efikasisht i pamjaftueshëm për qëllimet e sigurisë dhe nuk sjell asgjë të re në mekanizmat ekzistues të STARTTLS.

Burimi: habr.com