ProHoster > Blog > Administrasi > Mail.ru mail mimiti nerapkeun kawijakan MTA-STS dina modeu test

Mail.ru mail mimiti nerapkeun kawijakan MTA-STS dina modeu test

Mail.ru mail mimiti nerapkeun kawijakan MTA-STS dina modeu test

Pondokna, MTA-STS mangrupakeun cara jang meberkeun ngajaga surelek tina interception (ie, man-in-the-middle attacks alias MitM) nalika dikirimkeun antara server mail. Ieu sawaréh ngarengsekeun masalah arsitéktur warisan protokol email sareng dijelaskeun dina standar RFC 8461 anu kawilang anyar. Mail.ru mangrupikeun jasa surat utama munggaran dina RuNet pikeun nerapkeun standar ieu. Sarta eta dijelaskeun dina leuwih jéntré handapeun cut.

Masalah naon anu direngsekeun ku MTA-STS?

Dina sajarahna, protokol email (SMTP, POP3, IMAP) ngirimkeun inpormasi dina téks anu jelas, anu ngamungkinkeun pikeun nyegat éta, contona, nalika ngaksés saluran komunikasi.

Kumaha mékanisme pikeun ngirim surat ti hiji pangguna ka pangguna anu sanés sapertos kieu:

Mail.ru mail mimiti nerapkeun kawijakan MTA-STS dina modeu test

Dina sajarahna, serangan MitM mungkin di sadaya tempat dimana surat medar.

RFC 8314 merlukeun pamakéan TLS antara aplikasi pamaké surat (MUA) jeung server mail. Upami server anjeun sareng aplikasi surat anu anjeun anggo saluyu sareng RFC 8314, maka anjeun parantos (sabagian ageung) ngaleungitkeun kamungkinan serangan Man-in-the-Middle antara pangguna sareng server surat.

Nuturkeun prakték anu ditarima sacara umum (dibakukeun ku RFC 8314) ngaleungitkeun serangan di deukeut pamaké:

Mail.ru mail mimiti nerapkeun kawijakan MTA-STS dina modeu test

Pangladén mail Mail.ru matuh RFC 8314 bahkan sateuacan standar diadopsi; kanyataanna, éta ngan saukur nyandak prakték anu parantos ditampi, sareng kami henteu kedah ngonpigurasikeun naon waé tambahan. Tapi, upami pangladén surat anjeun masih ngamungkinkeun pangguna nganggo protokol anu teu aman, pastikeun pikeun nerapkeun saran standar ieu, sabab Paling dipikaresep, sahenteuna sababaraha pamaké anjeun damel sareng surat tanpa énkripsi, sanaos anjeun ngadukung éta.

Klién surat salawasna dianggo sareng pangladén surat anu sami dina organisasi anu sami. Sareng anjeun tiasa maksa sadaya pangguna pikeun nyambung dina cara anu aman, teras ngajantenkeun téknisna teu mungkin pikeun pangguna anu henteu aman pikeun nyambungkeun (ieu mangrupikeun kabutuhan RFC 8314). Ieu kadang hese, tapi bisa dipigawé. Lalu lintas antara server mail masih leuwih pajeulit. Server milik organisasi béda jeung mindeng dipaké dina mode "nyetél jeung poho", nu ngajadikeun eta teu mungkin mun pindah ka protokol aman sakaligus tanpa megatkeun konektipitas. SMTP geus lila nyadiakeun extension STARTTLS, nu ngidinan server nu ngarojong enkripsi pindah ka TLS. Tapi panyerang anu gaduh kamampuan mangaruhan lalu lintas tiasa "motong" inpormasi ngeunaan dukungan pikeun paréntah ieu sareng maksakeun server komunikasi nganggo protokol téks biasa (anu disebut serangan downgrade). Pikeun alesan anu sami, STARTTLS biasana henteu pariksa validitas sertipikat (sertipikat anu teu dipercaya tiasa ngajagi tina serangan pasip, sareng ieu henteu langkung parah tibatan ngirim pesen dina téks anu jelas). Ku alatan éta, STARTTLS ngan ngajaga tina eavesdropping pasip.

MTA-STS sawaréh ngaleungitkeun masalah intercepting hurup antara server mail, nalika panyerang miboga kamampuh aktip pangaruh lalulintas. Upami domain panarima nyebarkeun kawijakan MTA-STS sareng server pangirim ngadukung MTA-STS, éta ngan ukur ngirim email dina sambungan TLS, ngan ka server anu ditetepkeun ku kawijakan, sareng ngan ukur ku verifikasi sertipikat server.

Naha sawaréh? MTA-STS ngan ukur tiasa dianggo upami dua pihak parantos ngalaksanakeun standar ieu, sareng MTA-STS henteu ngajagaan tina skenario dimana panyerang tiasa nampi sertipikat domain anu valid ti salah sahiji CA umum.

Kumaha MTA-STS jalan

nu narima

  1. Ngonpigurasikeun pangrojong STARTTLS sareng sertipikat anu valid dina pangladén surat. 
  2. Nerbitkeun kawijakan MTA-STS via HTTPS; domain mta-sts khusus sareng jalur khusus anu terkenal dianggo pikeun publikasi, contona. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Kabijakan éta ngandung daptar pangladén surat (mx) anu ngagaduhan hak nampi surat pikeun domain ieu.
  3. Nyebarkeun catetan TXT khusus _mta-sts dina DNS sareng versi kawijakan. Lamun kawijakan robah, entri ieu kudu diropéa (ieu sinyal pangirim ka ulang query kawijakan). Salaku conto, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Pangirim

Pangirimna nyuhunkeun rékaman DNS _mta-sts, sareng upami sayogi, ngadamel pamundut kawijakan via HTTPS (mariksa sertipikat). Kabijakan anu hasilna di-cache (upami panyerang ngablokir aksés kana éta atanapi ngabocorkeun catetan DNS).

Nalika ngirim surat, éta dipariksa yén:

  • server nu mail anu dikirimkeun aya dina kawijakan;
  • server narima surat maké TLS (STARTTLS) sarta ngabogaan sertipikat valid.

Kaunggulan tina MTA-STS

MTA-STS nganggo téknologi anu parantos dilaksanakeun di kalolobaan organisasi (SMTP+STARTTLS, HTTPS, DNS). Pikeun palaksanaan di sisi panarima, euweuh rojongan software husus pikeun standar anu diperlukeun.

Kakurangan MTA-STS

Perlu ngawas validitas sertipikat wéb sareng mail server, korespondensi nami, sareng pembaharuan tepat waktu. Masalah sareng sertipikat bakal nyababkeun surat teu tiasa dikirimkeun.

Di sisi pangirim, hiji MTA kalayan rojongan pikeun kawijakan MTA-STS diperlukeun; ayeuna, MTA-STS teu dirojong out of the box di MTA.

MTA-STS ngagunakeun daptar CA akar dipercaya.

MTA-STS henteu ngajagi tina serangan dimana panyerang ngagunakeun sertipikat anu sah. Dina kalolobaan kasus, MitM deukeut server ngakibatkeun kamampuhan pikeun ngaluarkeun sertipikat. Serangan sapertos kitu tiasa dideteksi nganggo Transparansi Sertipikat. Ku alatan éta, sacara umum, MTA-STS mitigates, tapi teu sagemblengna ngaleungitkeun, kamungkinan interception lalulintas.

Dua titik panungtungan ngajadikeun MTA-STS kirang aman ti competing standar DANE pikeun SMTP (RFC 7672), tapi leuwih teknis dipercaya, i.e. pikeun MTA-STS aya kamungkinan low yén surat moal dikirimkeun alatan masalah teknis disababkeun ku palaksanaan standar.

Standar bersaing - DANE

DANE nganggo DNSSEC pikeun nyebarkeun inpormasi sertipikat sareng henteu meryogikeun kapercayaan ka otoritas sertipikat éksternal, anu langkung aman. Tapi pamakean DNSSEC sacara signifikan langkung sering nyababkeun kagagalan téknis, dumasar kana statistik salami sababaraha taun pamakean (sanaos umumna aya tren anu positif dina réliabilitas DNSSEC sareng dukungan téknisna). Pikeun ngalaksanakeun DANE di SMTP di sisi panarima, ayana DNSSEC pikeun zona DNS wajib, sareng dukungan anu leres pikeun NSEC / NSEC3 penting pisan pikeun DANE, dimana aya masalah sistemik dina DNSSEC.

Mun DNSSEC teu ngonpigurasi leres, eta bisa ngakibatkeun gagalna pangiriman mail lamun sisi ngirim ngarojong DANE, sanajan sisi panarima weruh nanaon ngeunaan eta. Kukituna, sanaos kanyataan yén DANE mangrupikeun standar anu langkung lami sareng langkung aman sareng parantos dirojong dina sababaraha parangkat lunak server dina sisi pangirim, nyatana penetrasina tetep teu pati penting, seueur organisasi anu henteu siap pikeun nerapkeun éta kusabab kabutuhan pikeun nerapkeun DNSSEC. ieu sacara signifikan ngalambatkeun palaksanaan DANE salami sababaraha taun yén standarna parantos aya.

DANE sareng MTA-STS henteu saling bertentangan sareng tiasa dianggo babarengan.

Naon sareng dukungan MTA-STS dina Mail.ru Mail?

Mail.ru parantos medarkeun kabijakan MTA-STS pikeun sadaya domain utama salami lami. Kami ayeuna ngalaksanakeun bagian klien tina standar. Dina waktos nyerat, kawijakan diterapkeun dina mode non-blocking (upami pangiriman diblokir ku kawijakan, surat bakal dikirimkeun ngaliwatan "cadang" server tanpa nerapkeun kawijakan), lajeng mode blocking bakal dipaksa pikeun sabagian leutik. tina lalulintas SMTP kaluar, laun pikeun 100% lalulintas eta bakal Penegak kawijakan dirojong.

Saha deui anu ngadukung standar?

Sajauh ieu, kawijakan MTA-STS nyebarkeun kira-kira 0.05% tina domain aktip, tapi, Tapi, aranjeunna geus ngajaga volume badag lalulintas mail, sabab Standar ieu dirojong ku pamaén utama - Google, Comcast sarta sabagean Verizon (AOL, Yahoo). Seueur jasa pos anu sanés ngumumkeun yén dukungan pikeun standar bakal dilaksanakeun dina waktos anu caket.

Kumaha ieu bakal mangaruhan kuring?

Teu iwal domain anjeun publishes kawijakan MTA-STS. Upami anjeun nyebarkeun kawijakan, email pikeun pangguna pangladén surat anjeun bakal langkung saé dijagi tina interception.

Kumaha kuring nerapkeun MTA-STS?

rojongan MTA-STS di sisi panarima

Cukup nyebarkeun kawijakan via HTTPS sareng rékaman dina DNS, ngonpigurasikeun sertipikat anu sah ti salah sahiji CA anu dipercaya (Hayu urang énkripsi mungkin) pikeun STARTTLS di MTA (STARTTLS dirojong dina sadaya MTA modern), teu aya dukungan khusus ti MTA diperlukeun.

Step by step, sigana kieu:

  1. Konpigurasikeun STARTTLS dina MTA nu Anjeun pake (postfix, exim, sendmail, Microsoft Exchange, jsb).
  2. Pastikeun yén anjeun ngagunakeun sertipikat valid (dikaluarkeun ku CA dipercaya, teu kadaluwarsa, subyek sertipikat cocog catetan MX nu delivers mail pikeun domain anjeun).
  3. Konpigurasikeun rékaman TLS-RPT dimana laporan aplikasi kawijakan bakal dikirimkeun (ku jasa anu ngadukung ngirim laporan TLS). Éntri conto (pikeun domain example.com): 
    smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

    Éntri ieu maréntahkeun pangirim surat ngirim laporan statistik ngeunaan pamakean TLS di SMTP ka [email protected].

    Pantau laporan sababaraha dinten pikeun mastikeun teu aya kasalahan.

  4. Nyebarkeun kawijakan MTA-STS ngaliwatan HTTPS. Kawijakan ieu diterbitkeun salaku file téks sareng terminator garis CRLF dumasar lokasi. 
    https://mta-sts.example.com/.well-known/mta-sts.txt

    Conto kawijakan:

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

    Widang versi ngandung versi kawijakan (ayeuna STSv1), Mode nyetél mode aplikasi kawijakan, nguji - mode test (kabijakan teu dilarapkeun), ngalaksanakeun - mode "tempur". Kahiji nyebarkeun kawijakan kalawan mode: nguji, lamun euweuh masalah jeung kawijakan dina modeu test, sanggeus bari anjeun bisa pindah ka modeu: ngalaksanakeun.

    Dina mx, daptar sadaya pangladén surat anu tiasa nampi surat pikeun domain anjeun ditangtukeun (unggal server kedah gaduh sertipikat anu dikonpigurasi anu cocog sareng nami anu ditunjuk dina mx). Max_age netepkeun waktos caching kawijakan (sakali kawijakan anu émut bakal diterapkeun sanaos panyerang meungpeuk pangirimanna atanapi ngaruksak rékaman DNS salami waktos caching, anjeun tiasa nunjukkeun kedah nyuhunkeun kawijakan deui ku ngarobih mta-sts DNS. rékaman).

  5. Nyebarkeun rékaman TXT dina DNS:  
    _mta-sts.example.com. TXT “v=STS1; id=someid;”

    Identifier sawenang-wenang (contona, timestamp) tiasa dianggo dina widang id; nalika kawijakan robih, éta kedah robih, hal ieu ngamungkinkeun pangirim ngartos yén aranjeunna kedah naroskeun deui kawijakan anu di-cache (upami identifierna béda ti hiji cache).

Rojongan MTA-STS di sisi pangirim

Sajauh ieu goréng kalayan anjeunna, sabab ... baku seger.

Salaku afterword ngeunaan "wajib TLS"

Akhir-akhir ieu, régulator parantos nengetan kaamanan email (sareng éta mangrupikeun hal anu saé). Salaku conto, DMARC wajib pikeun sadaya instansi pamaréntah di Amérika Serikat sareng beuki diperyogikeun dina séktor kauangan, kalayan penetrasi standar ngahontal 90% di daérah anu diatur. Ayeuna sababaraha régulator merlukeun palaksanaan "wajib TLS" kalawan domain individu, tapi mékanisme pikeun mastikeun "wajib TLS" teu ditetepkeun sarta dina praktekna setelan ieu mindeng dilaksanakeun dina cara nu malah teu minimally ngajaga ngalawan serangan nyata nu geus. disayogikeun dina mékanisme sapertos DANE atanapi MTA-STS.

Lamun regulator merlukeun palaksanaan "wajib TLS" kalawan domain misah, kami nyarankeun mertimbangkeun MTA-STS atawa analog parsial na salaku mékanisme paling merenah, éta eliminates kudu nyieun setélan aman pikeun tiap domain nyalira. Upami anjeun sesah ngalaksanakeun bagian klien tina MTA-STS (dugi ka protokol parantos nampi dukungan umum, aranjeunna paling dipikaresep bakal), kami tiasa nyarankeun pendekatan ieu:

  1. Nyebarkeun kawijakan MTA-STS jeung/atawa rékaman DANE (DANE asup akal ngan lamun DNSSEC geus diaktipkeun pikeun domain anjeun, sarta MTA-STS dina sagala hal), ieu bakal ngajaga lalulintas arah anjeun sarta ngaleungitkeun kabutuhan nanya jasa mail séjén. pikeun ngonpigurasikeun TLS wajib pikeun domain anjeun lamun layanan mail geus ngarojong MTA-STS jeung/atawa DANE.
  2. Pikeun jasa email ageung, laksanakeun "analog" MTA-STS ngaliwatan setélan angkutan anu misah pikeun tiap domain, anu bakal ngalereskeun MX anu dianggo pikeun ngirim surat sareng ngabutuhkeun verifikasi wajib sertipikat TLS pikeun éta. Upami domain parantos nyebarkeun kawijakan MTA-STS, ieu sigana tiasa dilakukeun tanpa aya rasa nyeri. Ku sorangan, ngamungkinkeun TLS wajib pikeun domain tanpa ngalereskeun relay sareng pariksa sertipikat pikeun éta henteu efektif tina sudut pandang kaamanan sareng henteu nambihan nanaon kana mékanisme STARTTLS anu tos aya.

sumber: www.habr.com

Tambahkeun komentar