ProHoster > Π‘Π»ΠΎΠ³ > Administrasi > Mail.ru mail wiwit ngetrapake kabijakan MTA-STS ing mode test

Mail.ru mail wiwit ngetrapake kabijakan MTA-STS ing mode test

Mail.ru mail wiwit ngetrapake kabijakan MTA-STS ing mode test

Ing cendhak, MTA-STS minangka cara kanggo nglindhungi email luwih saka interception (yaiku, serangan man-in-the-middle alias MitM) nalika ditularake antarane server mail. Iki sebagian ngatasi masalah arsitektur warisan protokol email lan diterangake ing standar RFC 8461 sing relatif anyar. Mail.ru minangka layanan surat utama pisanan ing RuNet sing ngetrapake standar iki. Lan diterangake kanthi luwih rinci ing sangisore potong.

Masalah apa sing diatasi MTA-STS?

Sacara historis, protokol email (SMTP, POP3, IMAP) ngirimake informasi ing teks sing cetha, sing ndadekake bisa nyegat, contone, nalika ngakses saluran komunikasi.

Kepiye mekanisme ngirim layang saka pangguna menyang pangguna liyane:

Mail.ru mail wiwit ngetrapake kabijakan MTA-STS ing mode test

Secara historis, serangan MitM bisa ditindakake ing kabeh panggonan sing nyebarake surat.

RFC 8314 mbutuhake panggunaan TLS antarane aplikasi pangguna mail (MUA) lan server mail. Yen server lan aplikasi mail sing sampeyan gunakake tundhuk karo RFC 8314, sampeyan wis (akehe) ngilangi kemungkinan serangan Man-in-the-Middle antarane pangguna lan server mail.

Nderek praktik sing umume ditampa (standar RFC 8314) ngilangi serangan ing cedhak pangguna:

Mail.ru mail wiwit ngetrapake kabijakan MTA-STS ing mode test

Server mail Mail.ru tundhuk karo RFC 8314 sanajan sadurunge standar kasebut diadopsi; nyatane, iku mung njupuk praktik sing wis ditampa, lan kita ora kudu ngatur apa-apa tambahan. Nanging, yen server email sampeyan isih ngidini pangguna nggunakake protokol sing ora aman, priksa manawa sampeyan ngetrapake rekomendasi standar iki, amarga Paling kamungkinan, paling ora sawetara pangguna sampeyan bisa nganggo email tanpa enkripsi, sanajan sampeyan ndhukung.

Klien mail tansah dianggo karo server mail sing padha saka organisasi sing padha. Lan sampeyan bisa meksa kabeh pangguna kanggo nyambung kanthi aman, banjur nggawe teknis ora bisa nyambungake pangguna sing ora aman (iki pancen dibutuhake RFC 8314). Iki kadhangkala angel, nanging bisa ditindakake. Lalu lintas antarane server mail isih luwih rumit. Server kagungane organisasi beda lan asring digunakake ing mode "nyetel lan lali", kang ndadekake iku mokal kanggo ngalih menyang protokol aman bebarengan tanpa break panyambungan. SMTP wis suwe nyedhiyakake ekstensi STARTTLS, sing ngidini server sing ndhukung enkripsi bisa ngalih menyang TLS. Nanging panyerang sing nduweni kemampuan kanggo pengaruhe lalu lintas bisa "ngethok" informasi babagan dhukungan kanggo printah iki lan meksa server kanggo komunikasi nggunakake protokol teks biasa (sing diarani serangan downgrade). Kanggo alasan sing padha, STARTTLS biasane ora mriksa kesahihan sertifikat kasebut (sertifikat sing ora dipercaya bisa nglindhungi serangan pasif, lan iki ora luwih elek tinimbang ngirim pesen kanthi teks sing jelas). Mulane, STARTTLS mung nglindhungi saka pasif eavesdropping.

MTA-STS sebagian ngilangi masalah nyegat huruf ing antarane server mail, nalika panyerang nduweni kemampuan kanggo pengaruhe lalu lintas kanthi aktif. Yen domain panampa nerbitakΓ© privasi MTA-STS lan server pangirim ndhukung MTA-STS, iku mung bakal ngirim email liwat sambungan TLS, mung kanggo server ditetepake dening kawicaksanan, lan mung karo verifikasi certificate server.

Kenapa sebagian? MTA-STS mung bisa digunakake yen loro pihak wis njupuk care saka ngleksanakake standar iki, lan MTA-STS ora ngreksa marang skenario kang panyerang bisa njupuk certificate domain bener saka salah siji saka CA umum.

Carane MTA-STS dianggo

Penerima

  1. Ngatur dhukungan STARTTLS kanthi sertifikat sing sah ing server mail. 
  2. Nerbitake kabijakan MTA-STS liwat HTTPS; domain mta-sts khusus lan jalur khusus sing kondhang digunakake kanggo publikasi, contone. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Kabijakan kasebut ngemot dhaptar server mail (mx) sing duwe hak nampa email kanggo domain iki.
  3. Nerbitake rekaman TXT khusus _mta-sts ing DNS kanthi versi kebijakan. Nalika kabijakan diganti, entri iki kudu dianyari (iki menehi tandha marang pangirim kanggo takon maneh kebijakan kasebut). Tuladhane, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Pangirim

Pangirim njaluk rekaman DNS _mta-sts, lan yen kasedhiya, nggawe panjalukan kebijakan liwat HTTPS (mriksa sertifikat). Kabijakan sing diasilake di-cache (yen ana panyerang ngalangi akses kasebut utawa ngapusi rekaman DNS).

Nalika ngirim surat, dipriksa manawa:

  • server sing dikirim mail ana ing kabijakan;
  • server nampa mail nggunakake TLS (STARTTLS) lan duwe certificate bener.

Kaluwihan saka MTA-STS

MTA-STS nggunakake teknologi sing wis diterapake ing umume organisasi (SMTP+STARTTLS, HTTPS, DNS). Kanggo implementasine ing sisih panampa, ora ana dhukungan piranti lunak khusus kanggo standar kasebut.

Kekurangan MTA-STS

Sampeyan kudu ngawasi validitas sertifikat server web lan mail, korespondensi jeneng, lan nganyari maneh pas wektune. Masalah karo sertifikat bakal nyebabake mail ora bisa dikirim.

Ing sisih pangirim, MTA kanthi dhukungan kanggo kabijakan MTA-STS dibutuhake; saiki, MTA-STS ora didhukung metu saka kothak ing MTA.

MTA-STS nggunakake dhaptar CA ROOT dipercaya.

MTA-STS ora nglindhungi saka serangan sing panyerang nggunakake sertifikat sing bener. Umume kasus, MitM cedhak server nuduhake kemampuan kanggo ngetokake sertifikat. Serangan kasebut bisa dideteksi nggunakake Transparansi Sertifikat. Mulane, ing umum, MTA-STS ngurangi, nanging ora rampung ngilangi, kemungkinan interception lalu lintas.

Rong poin pungkasan nggawe MTA-STS kurang aman tinimbang standar DANE saingan kanggo SMTP (RFC 7672), nanging luwih dipercaya sacara teknis, yaiku. kanggo MTA-STS ana kemungkinan kurang sing layang ora bakal dikirim amarga masalah technical disebabake implementasine saka standar.

Saingan standar - DANE

DANE nggunakake DNSSEC kanggo nerbitake informasi sertifikat lan ora mbutuhake kapercayan ing panguwasa sertifikat eksternal, sing luwih aman. Nanging panggunaan DNSSEC sacara signifikan luwih asring nyebabake kegagalan teknis, adhedhasar statistik sajrone sawetara taun panggunaan (sanajan umume ana tren positif babagan linuwih DNSSEC lan dhukungan teknis). Kanggo ngleksanakake DANE ing SMTP ing sisih panampa, anane DNSSEC kanggo zona DNS wajib, lan dhukungan sing bener kanggo NSEC / NSEC3 penting kanggo DANE, sing ana masalah sistemik ing DNSSEC.

Yen DNSSEC ora dikonfigurasi kanthi bener, bisa nyebabake gagal pangiriman email yen sisih ngirim ndhukung DANE, sanajan pihak sing nampa ora ngerti apa-apa. Mulane, senadyan kasunyatane DANE minangka standar sing luwih lawas lan luwih aman lan wis didhukung ing sawetara piranti lunak server ing sisih pangirim, nyatane penetrasi kasebut tetep ora pati penting, akeh organisasi sing ora siap ngleksanakake amarga kudu ngetrapake DNSSEC. iki wis Ngartekno kalem mudhun implementasine saka DANE kabeh taun sing standar wis ana.

DANE lan MTA-STS ora konflik karo saben liyane lan bisa digunakake bebarengan.

Apa karo dhukungan MTA-STS ing Mail.ru Mail?

Mail.ru wis nerbitake kabijakan MTA-STS kanggo kabeh domain utama kanggo sawetara wektu. Saiki kita ngetrapake bagean klien saka standar kasebut. Nalika nulis, kabijakan diterapake ing mode non-blocking (yen pangiriman diblokir dening kabijakan, surat kasebut bakal dikirim liwat server "cadangan" tanpa ngetrapake kabijakan), banjur mode pamblokiran bakal dipeksa kanggo bagean cilik. saka lalu lintas SMTP metu, mboko sithik kanggo 100% lalu lintas bakal Enforcement saka kawicaksanan didhukung.

Sapa maneh sing ndhukung standar kasebut?

Nganti saiki, kabijakan MTA-STS nerbitake kira-kira 0.05% domain aktif, nanging, nanging, dheweke wis nglindhungi lalu lintas surat sing akeh, amarga Standar kasebut didhukung dening pemain utama - Google, Comcast lan sebagian Verizon (AOL, Yahoo). Akeh layanan pos liyane wis ngumumake yen dhukungan kanggo standar kasebut bakal ditindakake ing mangsa ngarep.

Kepiye carane iki bakal mengaruhi aku?

Ora kajaba domain sampeyan nerbitake kabijakan MTA-STS. Yen sampeyan nerbitake kabijakan kasebut, email kanggo pangguna server email sampeyan bakal luwih dilindhungi saka intersepsi.

Kepiye cara ngetrapake MTA-STS?

Dhukungan MTA-STS ing sisih panampa

Cukup kanggo nerbitake kabijakan liwat HTTPS lan cathetan ing DNS, ngatur sertifikat sing sah saka salah sawijining CA sing dipercaya (Ayo enkripsi bisa) kanggo STARTTLS ing MTA (STARTTLS didhukung ing kabeh MTA modern), ora ana dhukungan khusus saka MTA dibutuhake.

Langkah demi langkah, katon kaya iki:

  1. Konfigurasi STARTTLS ing MTA sing sampeyan gunakake (postfix, exim, sendmail, Microsoft Exchange, lsp.).
  2. Priksa manawa sampeyan nggunakake sertifikat sing sah (ditanggepi dening CA sing dipercaya, ora kadaluwarsa, subyek sertifikat cocog karo rekaman MX sing ngirim email kanggo domain sampeyan).
  3. Konfigurasi rekaman TLS-RPT ing ngendi laporan aplikasi kebijakan bakal dikirim (dening layanan sing ndhukung ngirim laporan TLS). Entri conto (kanggo domain example.com): 
    smtp._tls.example.com. 300 IN TXT Β«v=TLSRPTv1;rua=mailto:[email protected]Β»

    Entri iki menehi pitunjuk marang pangirim email supaya ngirim laporan statistik babagan panggunaan TLS ing SMTP menyang [email protected].

    Ngawasi laporan sawetara dina kanggo mesthekake yen ora ana kesalahan.

  4. Nerbitake kabijakan MTA-STS liwat HTTPS. Kabijakan kasebut diterbitake minangka file teks kanthi terminator baris CRLF miturut lokasi. 
    https://mta-sts.example.com/.well-known/mta-sts.txt

    Tuladha kebijakan:

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

    Kolom versi ngemot versi kabijakan (saiki STSv1), Mode nyetel mode aplikasi kabijakan, nguji - mode test (kabijakan ora ditrapake), ngleksanakake - mode "pertempuran". Pisanan nerbitake kabijakan kanthi mode: testing, yen ora ana masalah karo kebijakan ing mode test, sawise sawetara wektu sampeyan bisa ngalih menyang mode: nglakokakΓ©.

    Ing mx, dhaptar kabeh server email sing bisa nampa email kanggo domain sampeyan ditemtokake (saben server kudu duwe sertifikat sing dikonfigurasi sing cocog karo jeneng sing ditemtokake ing mx). Max_age nemtokake wektu caching kabijakan kasebut (yen kabijakan sing dieling-eling bakal ditrapake sanajan panyerang ngalangi kiriman utawa ngrusak cathetan DNS sajrone wektu caching, sampeyan bisa menehi tandha manawa kudu njaluk kabijakan maneh kanthi ngganti mta-sts DNS. rekaman).

  5. Nerbitake rekaman TXT ing DNS:  
    _mta-sts.example.com. TXT β€œv=STS1; id=someid;”

    Pengenal kasepakatan (contone, cap wektu) bisa digunakake ing kolom id; nalika kabijakan diganti, kudu diganti, iki ngidini pangirim ngerti yen dheweke kudu njaluk maneh kebijakan sing di-cache (yen pengenal beda karo sing di-cache).

Dhukungan MTA-STS ing sisih pangirim

Nganti saiki ora apik karo dheweke, amarga ... standar seger.

Minangka tembung mburi babagan "TLS wajib"

Akhir-akhir iki, regulator wis menehi perhatian marang keamanan email (lan iku apik). Contone, DMARC wajib kanggo kabeh lembaga pemerintah ing Amerika Serikat lan tambah akeh dibutuhake ing sektor finansial, kanthi penetrasi standar tekan 90% ing wilayah sing diatur. Saiki sawetara regulator mbutuhake implementasine "TLS wajib" karo domain individu, nanging mekanisme kanggo mesthekake "TLS wajib" ora ditetepake lan ing praktik setelan iki asring dileksanakake kanthi cara sing ora malah minimal nglindhungi serangan nyata sing wis ana. kasedhiya ing mekanisme kayata DANE utawa MTA-STS.

Yen regulator mbutuhake implementasine "TLS wajib" kanthi domain sing kapisah, disaranake nimbang MTA-STS utawa analog parsial minangka mekanisme sing paling cocok, ngilangake kabutuhan kanggo nggawe setelan aman kanggo saben domain kanthi kapisah. Yen sampeyan duwe kesulitan ngleksanakake bagean klien MTA-STS (nganti protokol wis nampa dhukungan sing akeh, mesthine bakal), kita bisa menehi rekomendasi pendekatan iki:

  1. Nerbitake kabijakan MTA-STS lan/utawa cathetan DANE (DANE mung masuk akal yen DNSSEC wis diaktifake kanggo domain sampeyan, lan MTA-STS ing kasus apa wae), iki bakal nglindhungi lalu lintas menyang arah sampeyan lan ngilangi kabutuhan takon layanan email liyane kanggo ngatur TLS wajib kanggo domain sampeyan yen layanan mail wis ndhukung MTA-STS lan/utawa DANE.
  2. Kanggo layanan email gedhe, ngleksanakake "analog" MTA-STS liwat setelan transportasi sing kapisah kanggo saben domain, sing bakal ndandani MX sing digunakake kanggo ngirim surat lan mbutuhake verifikasi wajib sertifikat TLS. Yen domain wis nerbitake kabijakan MTA-STS, iki bisa uga ditindakake tanpa rasa lara. Kanthi dhewe, ngaktifake TLS wajib kanggo domain tanpa ndandani relay lan verifikasi sertifikat kasebut ora efektif saka sudut pandang keamanan lan ora nambah apa-apa ing mekanisme STARTTLS sing ana.

Source: www.habr.com

Add a comment