په لنډه توګه، MTA-STS د مداخلې څخه د بریښنالیکونو د ساتنې لپاره یوه لاره ده (د بیلګې په توګه، د مینځني مینځني بریدونه عرف MitM) کله چې د میل سرورونو ترمینځ لیږدول کیږي. دا په جزوي توګه د بریښنالیک پروتوکولونو میراثي معمارۍ ستونزې حل کوي او په نسبتا وروستي معیاري RFC 8461 کې تشریح شوي. Mail.ru په RuNet کې لومړی لوی بریښنالیک خدمت دی چې دا معیار پلي کوي. او دا د کټ لاندې په ډیر تفصیل سره بیان شوی.
MTA-STS کومه ستونزه حل کوي؟
په تاریخي توګه، د بریښنالیک پروتوکولونه (SMTP، POP3، IMAP) معلومات په روښانه متن کې لیږدول، کوم چې د دې مداخله ممکنه کړې، د بیلګې په توګه، کله چې د ارتباطي چینل ته لاسرسی ومومي.
د یو کارونکي څخه بل ته د لیک لیږلو میکانیزم څه ډول ښکاري:
په تاریخي توګه، د MitM برید په ټولو ځایونو کې ممکنه وه چیرې چې بریښنالیک خپریږي.
RFC 8314 د بریښنالیک کارونکي غوښتنلیک (MUA) او میل سرور ترمینځ د TLS کارولو ته اړتیا لري. که ستاسو سرور او د بریښنالیک غوښتنلیکونه چې تاسو یې کاروئ د RFC 8314 سره مطابقت لري ، نو تاسو (په لویه کچه) د کارونکي او میل سرورونو ترمینځ د مینځني مینځني بریدونو احتمال له مینځه وړی.
په عمومي ډول منل شوي عملونه (د RFC 8314 لخوا معیاري شوي) د کارونکي سره نږدې برید له مینځه وړي:
د Mail.ru میل سرورونه د RFC 8314 سره مطابقت لري حتی مخکې له دې چې معیاري تصویب شي؛ په حقیقت کې، دا په ساده ډول دمخه منل شوي عملونه نیسي، او موږ اړتیا نه درلوده چې نور څه تنظیم کړو. مګر، که ستاسو د بریښنالیک سرور لاهم کاروونکو ته اجازه ورکوي چې ناامنه پروتوکولونه وکاروي، ډاډ ترلاسه کړئ چې د دې معیار سپارښتنې پلي کړئ، ځکه چې ډیری احتمال، لږترلږه ستاسو ځینې کاروونکي د کوډ کولو پرته د میل سره کار کوي، حتی که تاسو یې ملاتړ کوئ.
د بریښنالیک پیرودونکی تل د ورته سازمان د ورته میل سرور سره کار کوي. او تاسو کولی شئ ټول کاروونکي مجبور کړئ چې په خوندي ډول وصل شي، او بیا د غیر خوندي کاروونکو لپاره د تخنیکي پلوه ناممکن کړئ چې وصل شي (دا هغه څه دي چې RFC 8314 ته اړتیا لري). دا ځینې وختونه ستونزمن وي، مګر د ترسره کولو وړ وي. د میل سرورونو تر مینځ ترافیک لاهم پیچلی دی. سرورونه په مختلفو سازمانونو پورې اړه لري او ډیری وختونه په "سیټ او هیر" حالت کې کارول کیږي، کوم چې د ارتباط ماتولو پرته په یوځل کې خوندي پروتوکول ته لیږدول ناممکن کوي. SMTP د اوږدې مودې لپاره د STARTTLS توسیع چمتو کړی، کوم چې سرورونو ته اجازه ورکوي چې د کوډ کولو ملاتړ وکړي ترڅو TLS ته لاړ شي. مګر یو برید کونکی چې د ترافیک اغیزې کولو وړتیا لري کولی شي د دې قوماندې لپاره د ملاتړ په اړه معلومات "بشپړ کړي" او سرورونه دې ته اړ کړي چې د ساده متن پروتوکول (د تش په نامه ښکته برید) په کارولو سره اړیکه ونیسي. د ورته دلیل لپاره، STARTTLS معمولا د سند اعتبار نه ګوري (یو بې باوره سند کولی شي د غیر فعال بریدونو په وړاندې ساتنه وکړي، او دا په روښانه متن کې د پیغام لیږلو څخه بد نه دی). له همدې امله، STARTTLS یوازې د غیر فعال غوږ نیولو څخه ساتنه کوي.
MTA-STS په نسبي ډول د بریښنالیک سرورونو ترمینځ د لیکونو مداخلې ستونزه له مینځه وړي ، کله چې برید کونکی د دې وړتیا ولري چې په فعاله توګه ترافیک اغیزه وکړي. که د ترلاسه کونکي ډومین د MTA-STS پالیسي خپروي او د لیږونکي سرور د MTA-STS ملاتړ کوي، دا به یوازې د TLS اتصال له لارې بریښنالیک واستوي، یوازې د پالیسۍ لخوا تعریف شوي سرورونو ته، او یوازې د سرور سند تصدیق سره.
ولې په جزوي توګه؟ MTA-STS یوازې هغه وخت کار کوي چې دواړه خواوې د دې معیار پلي کولو ته پاملرنه وکړي، او MTA-STS د سناریوګانو په وړاندې ساتنه نه کوي په کوم کې چې یو برید کوونکی کولی شي د عامه CAs څخه د اعتبار وړ ډومین سند ترلاسه کړي.
MTA-STS څنګه کار کوي
ترلاسه کوونکی
- په میل سرور کې د یو باوري سند سره د STARTTLS ملاتړ تنظیموي.
- د HTTPS له لارې د MTA-STS پالیسي خپروي؛ یو ځانګړی mta-sts ډومین او یو ځانګړی پیژندل شوی لاره د خپرولو لپاره کارول کیږي، د بیلګې په توګه
https://mta-sts.mail.ru/.well-known/mta-sts.txt. پالیسي د میل سرورونو لیست لري (mx) چې د دې ډومین لپاره د بریښنالیک ترلاسه کولو حق لري. - د پالیسۍ نسخه سره په DNS کې د ځانګړي TXT ریکارډ _mta-sts خپروي. کله چې پالیسي بدله شي، دا ننوت باید تازه شي (دا د پالیسي بیاپوښتنې لپاره لیږونکي ته اشاره کوي). د مثال په ډول،
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
لیږونکی
لیږونکی د _mta-sts DNS ریکارډ غوښتنه کوي، او که دا شتون ولري، د HTTPS له لارې د پالیسۍ غوښتنه کوي (د سند چک کول). پایله پالیسي ساتل کیږي (په هغه صورت کې چې برید کونکی دې ته لاسرسی بند کړي یا د DNS ریکارډ غلا کړي).
کله چې بریښنالیک لیږل کیږي، دا چک کیږي چې:
- هغه سرور چې بریښنالیک ته لیږل کیږي په پالیسۍ کې دی؛
- سرور د TLS (STARTTLS) په کارولو سره بریښنالیک مني او یو معتبر سند لري.
د MTA-STS ګټې
MTA-STS هغه ټیکنالوژي کاروي چې دمخه په ډیری سازمانونو کې پلي شوي (SMTP+STARTTLS, HTTPS, DNS). د ترلاسه کونکي اړخ پلي کولو لپاره ، د معیار لپاره کوم ځانګړي سافټویر ملاتړ ته اړتیا نشته.
د MTA-STS زیانونه
دا اړینه ده چې د ویب او میل سرور سند اعتبار وڅارئ، د نومونو مطابقت، او په وخت سره نوي کول. د سند سره ستونزې به د بریښنالیک رسولو توان ونلري.
د لیږونکي لوري ته، د MTA-STS پالیسیو لپاره د ملاتړ سره MTA ته اړتیا ده؛ اوس مهال، MTA-STS په MTA کې د بکس څخه بهر نه ملاتړ کیږي.
MTA-STS د باوري روټ CAs لیست کاروي.
MTA-STS د بریدونو په وړاندې ساتنه نه کوي په کوم کې چې برید کوونکی یو باوري سند کاروي. په ډیری مواردو کې، سرور ته نږدې MitM د سند صادرولو وړتیا معنی لري. دا ډول برید د سند شفافیت په کارولو سره کشف کیدی شي. له همدې امله، په عموم کې، MTA-STS کموي، مګر په بشپړه توګه له منځه نه ځي، د ټرافيکي مداخلې احتمال.
وروستي دوه ټکي د SMTP (RFC 7672) لپاره د سیالۍ کونکي DANE معیار په پرتله MTA-STS لږ خوندي کوي، مګر ډیر تخنیکي اعتبار لري، د بیلګې په توګه. د MTA-STS لپاره لږ احتمال شتون لري چې لیک به د معیاري پلي کولو له امله رامینځته شوي تخنیکي ستونزو له امله ونه سپارل شي.
د سیالۍ معیار - DANE
DANE د سند معلوماتو خپرولو لپاره DNSSEC کاروي او د بهرني سند چارواکو باور ته اړتیا نلري ، کوم چې خورا خوندي دی. مګر د DNSSEC کارول د پام وړ ډیر ځله د تخنیکي ناکامیو لامل کیږي ، د څو کلونو کارولو احصایو پراساس (که څه هم د DNSSEC اعتبار او د هغې تخنیکي ملاتړ کې عموما مثبت رجحان شتون لري). د ترلاسه کونکي لوري په SMTP کې د DANE پلي کولو لپاره، د DNS زون لپاره د DNSSEC شتون لازمي دی، او د NSEC/NSEC3 لپاره سم ملاتړ د DANE لپاره اړین دی، چې په DNSSEC کې سیسټمیک ستونزې شتون لري.
که DNSSEC په سمه توګه تنظیم شوی نه وي، دا د بریښنالیک رسولو ناکامۍ پایله کیدی شي که چیرې د لیږلو اړخ د DANE مالتړ وکړي، حتی که ترلاسه کونکي اړخ پدې اړه هیڅ نه پوهیږي. له همدې امله ، د دې حقیقت سره سره چې DANE یو زوړ او ډیر خوندي معیار دی او دمخه د لیږونکي اړخ کې په ځینې سرور سافټویر کې ملاتړ شوی ، په حقیقت کې د هغې نفوذ خورا مهم دی ، ډیری سازمانونه د DNSSEC پلي کولو اړتیا له امله پلي کولو ته چمتو ندي ، دې ټولو هغو کلونو کې د DANE پلي کول د پام وړ ورو کړي چې معیار یې شتون درلود.
DANE او MTA-STS له یو بل سره شخړه نه کوي او یوځای کارول کیدی شي.
په Mail.ru میل کې د MTA-STS ملاتړ سره څه شی دی؟
Mail.ru له څه مودې راهیسې د ټولو لویو ډومینونو لپاره د MTA-STS پالیسي خپروي. موږ اوس مهال د معیاري پیرودونکي برخه پلي کوو. د لیکلو په وخت کې ، پالیسۍ په غیر بلاک کولو حالت کې پلي کیږي (که تحویلي د پالیسۍ لخوا بنده شوې وي ، لیک به د پالیسیو پلي کولو پرته د "اضافي" سرور له لارې تحویل شي) ، نو د بلاک کولو حالت به د یوې کوچنۍ برخې لپاره مجبور شي. د وتلو SMTP ټرافیک، په تدریجي ډول د 100٪ ټرافیک لپاره دا به د پالیسیو پلي کول ملاتړ کیږي.
نور څوک د معیار ملاتړ کوي؟
تر اوسه پورې، د MTA-STS پالیسۍ نږدې 0.05٪ فعال ډومینونه خپروي، مګر، سره له دې، دوی دمخه د بریښنالیک ټرافیک لوی مقدار خوندي کوي، ځکه چې معیار د لوی لوبغاړو لخوا ملاتړ کیږي - ګوګل، کامکاسټ او یو څه ویریزون (AOL، Yahoo). ډیری نورو پوستي خدماتو اعلان کړی چې د معیاري ملاتړ ملاتړ به په نږدې راتلونکي کې پلي شي.
دا به په ما څه اغیزه وکړي؟
نه تر هغه چې ستاسو ډومین د MTA-STS پالیسي خپروي. که تاسو پالیسي خپره کړئ، ستاسو د بریښنالیک سرور کاروونکو لپاره بریښنالیکونه به د مداخلې څخه ښه خوندي وي.
زه څنګه MTA-STS پلي کړم؟
د ترلاسه کونکي اړخ کې د MTA-STS ملاتړ
دا کافي ده چې پالیسي د HTTPS له لارې خپره کړئ او په DNS کې ریکارډونه وکړئ، په MTA کې د STARTTLS لپاره د یو باوري CAs څخه یو باوري سند ترتیب کړئ (راځئ چې کوډ کول ممکن وي) په MTA کې (STARTTLS په ټولو عصري MTAs کې ملاتړ کیږي)، له کوم ځانګړي ملاتړ څخه MTA ته اړتیا ده.
ګام په ګام، دا داسې ښکاري:
- په MTA کې د STARTTLS ترتیب کړئ چې تاسو یې کاروئ (پوسټ فکس، ایکسیم، سینډ میل، مایکروسافټ ایکسچینج، او نور).
- ډاډ ترلاسه کړئ چې تاسو یو باوري سند کاروئ (د باور وړ CA لخوا صادر شوی، نه ختم شوی، د سند موضوع د MX ریکارډ سره سمون لري چې ستاسو د ډومین لپاره بریښنالیک وړاندې کوي).
- د TLS-RPT ریکارډ ترتیب کړئ چې له لارې به یې د پالیسۍ غوښتنلیک راپورونه وړاندې شي (د هغو خدماتو لخوا چې د TLS راپورونو لیږلو ملاتړ کوي). د مثال داخلول (د example.com ډومین لپاره):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»دا ننوتل د بریښنالیک لیږونکو ته لارښوونه کوي چې په SMTP کې د TLS کارولو په اړه احصایوي راپورونه واستوي
[email protected].راپورونه د څو ورځو لپاره وڅارئ ترڅو ډاډ ترلاسه کړئ چې هیڅ غلطی شتون نلري.
- د HTTPS په اړه د MTA-STS پالیسي خپره کړئ. پالیسي د ځای له مخې د CRLF لاین ټرمینیټرونو سره د متن فایل په توګه خپره شوې.
https://mta-sts.example.com/.well-known/mta-sts.txtد پالیسۍ بېلګه:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400د نسخې ساحه د پالیسۍ نسخه لري (اوس مهال
STSv1)، حالت د پالیسي غوښتنلیک حالت، د ازموینې - ازموینې حالت (پالیسي نه پلي کیږي)، پلي کول - "جګړه" حالت ټاکي. لومړی د موډ سره پالیسي خپره کړئ: ازموینه، که چیرې د ازموینې حالت کې د پالیسۍ سره کومه ستونزه شتون ونلري، یو څه وروسته تاسو کولی شئ موډ ته لاړ شئ: تطبیق.په mx کې، د ټولو میل سرورونو لیست چې کولی شي ستاسو د ډومین لپاره بریښنالیک ومني (هر سرور باید یو سند ولري چې په mx کې مشخص شوي نوم سره سمون ولري). Max_age د پالیسي د کیچ کولو وخت مشخص کوي (یوځل چې یادونه شوې پالیسي به پلي شي حتی که برید کونکی د دې تحویل مخه ونیسي یا د کیچ کولو وخت په جریان کې د DNS ریکارډونه فاسد کړي ، تاسو کولی شئ د mta-sts DNS بدلولو سره بیا د پالیسۍ غوښتنه کولو اړتیا ته اشاره وکړئ. ریکارډ).
- په DNS کې د TXT ریکارډ خپور کړئ:
_mta-sts.example.com. TXT “v=STS1; id=someid;”یو خپلسري پیژندونکی (د مثال په توګه، د مهال ویش) د ID په ساحه کې کارول کیدی شي؛ کله چې پالیسي بدله شي، دا باید بدلون ومومي، دا لیږونکي ته اجازه ورکوي چې پوه شي چې دوی د زیرمه شوي پالیسي بیا غوښتنه کولو ته اړتیا لري (که چیرې پیژندونکی د پیژندنې څخه توپیر ولري. زیرمه شوی یو).
د لیږونکي اړخ کې د MTA-STS ملاتړ
تر دې دمه د هغې سره خراب دی ، ځکه چې ... تازه معیار
- Exim - هیڅ جوړ شوی ملاتړ نشته، د دریمې ډلې سکریپټ شتون لري
- پوسټ فکس - هیڅ جوړ شوی ملاتړ شتون نلري ، د دریمې ډلې سکریپټ شتون لري چې په هابري کې په تفصیل سره بیان شوی
د "لازمي TLS" په اړه د وروسته کلمې په توګه
په دې وروستیو کې، تنظیم کونکي د بریښنالیک امنیت ته پاملرنه کوي (او دا یو ښه شی دی). د مثال په توګه، DMARC په متحده ایالاتو کې د ټولو دولتي ادارو لپاره لازمي دی او په مالي سکټور کې په زیاتیدونکي توګه اړین دی، په منظمو سیمو کې د 90٪ معیار ته رسیدو سره. اوس ځینې تنظیم کونکي د انفرادي ډومینونو سره د "لازمي TLS" پلي کولو ته اړتیا لري ، مګر د "لازمي TLS" ډاډ ترلاسه کولو میکانیزم ندی تعریف شوی او په عمل کې دا ترتیب اکثرا په داسې طریقه پلي کیږي چې حتی لږترلږه د اصلي بریدونو پروړاندې محافظت نه کوي چې دمخه شتون لري. د میکانیزمونو لپاره چمتو شوي لکه DANE یا MTA-STS.
که تنظیم کوونکی د جلا ډومینونو سره د "لازمي TLS" پلي کولو ته اړتیا ولري، موږ وړاندیز کوو چې د MTA-STS یا د هغې جزوی انلاګ د خورا مناسب میکانیزم په توګه په پام کې ونیسئ، دا د هر ډومین لپاره په جلا توګه د خوندي ترتیباتو جوړولو اړتیا له منځه وړي. که تاسو د MTA-STS د پیرودونکي برخې پلي کولو کې ستونزې لرئ (تر هغه چې پروتوکول پراخه ملاتړ ترلاسه کړي، دوی به ډیر احتمال ولري)، موږ کولی شو دا طریقه وړاندیز وکړو:
- د MTA-STS پالیسي او/یا د DANE ریکارډونه خپاره کړئ (DANE یوازې هغه وخت معنی لري چې DNSSEC دمخه ستاسو د ډومین لپاره فعال شوی وي، او MTA-STS په هر حالت کې)، دا به ستاسو په لور د ټرافيکو ساتنه وکړي او د نورو بریښنالیک خدماتو غوښتنه کولو اړتیا له منځه یوسي. د خپل ډومین لپاره لازمي TLS تنظیم کول که چیرې د بریښنالیک خدمت دمخه د MTA-STS او/یا DANE ملاتړ کوي.
- د لوی بریښنالیک خدماتو لپاره، د هر ډومین لپاره د جلا ترانسپورت ترتیباتو له لارې د MTA-STS "انالوګ" پلي کړئ، کوم چې به د میل ریلینګ لپاره کارول شوي MX حل کړي او د دې لپاره به د TLS سند لازمي تصدیق ته اړتیا ولري. که چیرې ډومینونه دمخه د MTA-STS پالیسي خپروي، نو دا ممکن په بې درده توګه ترسره شي. پخپله، د ډومین لپاره د لازمي TLS فعالول پرته له دې چې ریل حل کړي او د دې لپاره سند تصدیق کړي د امنیت له نظره غیر موثر دی او د اوسني STARTTLS میکانیزمونو کې هیڅ شی نه اضافه کوي.
سرچینه: www.habr.com