مختصراً، 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 سپورٹ کو کنفیگر کرتا ہے۔
MTA-STS پالیسی کو HTTPS کے ذریعے شائع کرتا ہے؛ اشاعت کے لیے ایک خاص 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 ٹریفک میں رکاوٹ کے امکان کو کم کرتا ہے، لیکن مکمل طور پر ختم نہیں کرتا ہے۔

آخری دو نکات MTA-STS کو SMTP (RFC 7672) کے مقابلہ کرنے والے DANE معیار سے کم محفوظ بناتے ہیں، لیکن تکنیکی اعتبار سے زیادہ قابل اعتماد، یعنی 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% فعال ڈومینز شائع کرتی ہیں، لیکن، اس کے باوجود، وہ پہلے سے ہی بڑی تعداد میں میل ٹریفک کی حفاظت کرتی ہیں، کیونکہ اس معیار کو بڑے پلیئرز - Google، Comcast اور جزوی طور پر Verizon (AOL، Yahoo) کی حمایت حاصل ہے۔ بہت سی دوسری پوسٹل سروسز نے اعلان کیا ہے کہ معیار کے لیے سپورٹ مستقبل قریب میں نافذ کیا جائے گا۔

اس کا مجھ پر کیا اثر پڑے گا؟

اس وقت تک نہیں جب تک کہ آپ کا ڈومین MTA-STS پالیسی شائع نہ کرے۔ اگر آپ پالیسی شائع کرتے ہیں، تو آپ کے میل سرور کے صارفین کے لیے ای میلز مداخلت سے بہتر طور پر محفوظ رہیں گی۔

میں MTA-STS کو کیسے نافذ کروں؟

وصول کنندہ کی طرف سے MTA-STS سپورٹ

یہ کافی ہے کہ پالیسی کو HTTPS کے ذریعے شائع کریں اور DNS میں ریکارڈ کریں، MTA میں STARTTLS کے لیے قابل اعتماد CAs میں سے ایک سے ایک درست سرٹیفکیٹ ترتیب دیں (آئیے انکرپٹ ممکن ہے) 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 - کوئی بلٹ ان سپورٹ نہیں، تھرڈ پارٹی اسکرپٹ ہے۔ https://github.com/Bobberty/MTASTS-EXIM-PERL
پوسٹ فکس - کوئی بلٹ ان سپورٹ نہیں ہے، ایک تھرڈ پارٹی اسکرپٹ ہے جسے Habré پر تفصیل سے بیان کیا گیا ہے۔ https://habr.com/en/post/424961/

"لازمی 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

Mail.ru میل ٹیسٹ موڈ میں MTA-STS پالیسیوں کو لاگو کرنا شروع کر دیتا ہے۔