تعارف
Cisco, BlueCoat, FireEye جیسے معروف مینوفیکچررز کے جدید کارپوریٹ مواد فلٹرنگ سسٹمز ان کے زیادہ طاقتور ہم منصبوں - DPI سسٹمز کے ساتھ کافی حد تک مماثلت رکھتے ہیں، جو قومی سطح پر فعال طور پر لاگو کیے جا رہے ہیں۔ دونوں کے کام کا نچوڑ یہ ہے کہ آنے والے اور جانے والے انٹرنیٹ ٹریفک کا معائنہ کریں اور بلیک/وائٹ لسٹ کی بنیاد پر، انٹرنیٹ کنکشن پر پابندی لگانے کا فیصلہ کریں۔ اور چونکہ یہ دونوں اپنے کام کی بنیادی باتوں میں یکساں اصولوں پر انحصار کرتے ہیں، اس لیے ان کو روکنے کے طریقوں میں بھی بہت کچھ مشترک ہوگا۔
ان ٹیکنالوجیز میں سے ایک جو آپ کو DPI اور کارپوریٹ سسٹم دونوں کو مؤثر طریقے سے نظرانداز کرنے کی اجازت دیتی ہے وہ ہے ڈومین فرنٹنگ ٹیکنالوجی۔ اس کا خلاصہ یہ ہے کہ ہم ایک بلاک شدہ وسائل پر جاتے ہیں، دوسرے کے پیچھے چھپتے ہوئے، اچھی شہرت کے ساتھ عوامی ڈومین، جو ظاہر ہے کہ کسی بھی سسٹم کے ذریعے بلاک نہیں کیا جائے گا، مثال کے طور پر google.com۔
اس ٹیکنالوجی کے بارے میں پہلے ہی کافی مضامین لکھے جا چکے ہیں اور بہت سی مثالیں دی جا چکی ہیں۔ تاہم، مقبول اور حال ہی میں زیر بحث DNS-over-HTTPS اور انکرپٹڈ-SNI ٹیکنالوجیز کے ساتھ ساتھ TLS 1.3 پروٹوکول کا نیا ورژن، ڈومین فرنٹنگ کے لیے ایک اور آپشن پر غور کرنا ممکن بناتا ہے۔
ٹیکنالوجی کو سمجھنا
سب سے پہلے، آئیے ایک چھوٹے سے بنیادی تصورات کی وضاحت کرتے ہیں تاکہ ہر ایک کو یہ سمجھ آجائے کہ کون ہے اور اس سب کی ضرورت کیوں ہے۔ ہم نے eSNI میکانزم کا ذکر کیا، جس کے آپریشن پر مزید بات کی جائے گی۔ eSNI (انکرپٹڈ سرور نیم اشارہ) میکانزم SNI کا ایک محفوظ ورژن ہے، جو صرف TLS 1.3 پروٹوکول کے لیے دستیاب ہے۔ بنیادی خیال یہ ہے کہ دوسری چیزوں کے علاوہ، معلومات کو خفیہ کرنا ہے کہ درخواست کس ڈومین کو بھیجی گئی ہے۔
اب دیکھتے ہیں کہ eSNI میکانزم عملی طور پر کیسے کام کرتا ہے۔
ہم کہتے ہیں کہ ہمارے پاس انٹرنیٹ کا ایک وسیلہ ہے جسے جدید DPI حل کے ذریعے بلاک کر دیا گیا ہے (مثال کے طور پر، مشہور ٹورینٹ ٹریکر rutracker.nl لیتے ہیں)۔ جب ہم ٹورینٹ ٹریکر کی ویب سائٹ تک رسائی حاصل کرنے کی کوشش کرتے ہیں، تو ہمیں فراہم کنندہ کا معیاری اسٹب نظر آتا ہے جو اس بات کی نشاندہی کرتا ہے کہ وسیلہ مسدود ہے:
RKN ویب سائٹ پر یہ ڈومین دراصل اسٹاپ لسٹ میں درج ہے:
جب آپ whois سے استفسار کرتے ہیں، تو آپ دیکھ سکتے ہیں کہ ڈومین خود کلاؤڈ فراہم کنندہ Cloudflare کے پیچھے "چھپا ہوا" ہے۔
لیکن RKN کے "ماہرین" کے برعکس، Beeline (یا ہمارے مشہور ریگولیٹر کے تلخ تجربے سے سکھائے گئے) کے زیادہ تکنیکی طور پر جاننے والے ملازمین نے IP ایڈریس کے ذریعے سائٹ پر احمقانہ پابندی نہیں لگائی، بلکہ ڈومین نام کو اسٹاپ لسٹ میں شامل کر دیا۔ آپ آسانی سے اس کی تصدیق کر سکتے ہیں اگر آپ دیکھتے ہیں کہ اسی IP ایڈریس کے پیچھے کون سے دوسرے ڈومینز چھپے ہوئے ہیں، ان میں سے کسی ایک پر جائیں اور دیکھیں کہ رسائی مسدود نہیں ہے:
یہ کیسے ہوتا ہے؟ فراہم کنندہ کا DPI کیسے جانتا ہے کہ میرا براؤزر کس ڈومین پر ہے، کیونکہ تمام مواصلات https پروٹوکول کے ذریعے ہوتے ہیں، اور ہم نے ابھی تک Beeline سے https سرٹیفکیٹس کے متبادل کو نہیں دیکھا؟ کیا وہ دعویدار ہے یا میری پیروی کی جا رہی ہے؟
آئیے وائر شارک کے ذریعے ٹریفک کو دیکھ کر اس سوال کا جواب دینے کی کوشش کرتے ہیں۔
اسکرین شاٹ سے پتہ چلتا ہے کہ پہلے براؤزر سرور کا IP ایڈریس DNS کے ذریعے حاصل کرتا ہے، پھر منزل کے سرور کے ساتھ معیاری TCP ہینڈ شیک ہوتا ہے، اور پھر براؤزر سرور کے ساتھ SSL کنکشن قائم کرنے کی کوشش کرتا ہے۔ ایسا کرنے کے لیے، یہ ایک SSL کلائنٹ ہیلو پیکٹ بھیجتا ہے، جس میں سورس ڈومین کا نام واضح متن میں ہوتا ہے۔ کنکشن کو درست طریقے سے روٹ کرنے کے لیے کلاؤڈ فلیئر فرنٹ اینڈ سرور کو یہ فیلڈ درکار ہے۔ یہ وہ جگہ ہے جہاں فراہم کنندہ DPI ہمیں پکڑتا ہے، ہمارا کنکشن توڑتا ہے۔ ایک ہی وقت میں، ہمیں فراہم کنندہ کی طرف سے کوئی سٹب موصول نہیں ہوتا ہے، اور ہمیں براؤزر کی معیاری خرابی اس طرح نظر آتی ہے جیسے کہ سائٹ غیر فعال ہے یا صرف کام نہیں کرتی ہے۔
اب آئیے براؤزر میں eSNI میکانزم کو فعال کرتے ہیں، جیسا کہ ہدایات میں لکھا گیا ہے۔ :
ایسا کرنے کے لیے ہم فائر فاکس کنفیگریشن کا صفحہ کھولتے ہیں۔ کے بارے میں: config اور درج ذیل سیٹنگز کو فعال کریں:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
اس کے بعد، ہم چیک کریں گے کہ کلاؤڈ فلیئر ویب سائٹ پر سیٹنگز صحیح طریقے سے کام کر رہی ہیں۔ اور آئیے اپنے ٹورینٹ ٹریکر کے ساتھ اس چال کو دوبارہ آزماتے ہیں۔
Voila. ہمارا پسندیدہ ٹریکر بغیر کسی VPN یا پراکسی سرور کے کھلا۔ آئیے اب وائر شارک میں ٹریفک ڈمپ کو دیکھتے ہیں کہ کیا ہوا ہے۔
اس بار، ssl کلائنٹ ہیلو پیکیج میں واضح طور پر منزل کا ڈومین شامل نہیں ہے، لیکن اس کے بجائے، پیکیج میں ایک نیا فیلڈ نمودار ہوا ہے - encrypted_server_name - یہ وہ جگہ ہے جہاں rutracker.nl کی قدر موجود ہے، اور صرف کلاؤڈ فلیئر فرنٹ اینڈ سرور اسے ڈکرپٹ کرسکتا ہے۔ میدان اور اگر ایسا ہے تو پھر فراہم کنندہ DPI کے پاس اس کے سوا کوئی چارہ نہیں ہے کہ وہ ہاتھ دھوئے اور اس طرح کی ٹریفک کی اجازت دے۔ خفیہ کاری کے ساتھ کوئی دوسرا آپشن نہیں ہے۔
لہذا، ہم نے دیکھا کہ ٹیکنالوجی براؤزر میں کیسے کام کرتی ہے۔ اب آئیے اسے مزید مخصوص اور دلچسپ چیزوں پر لاگو کرنے کی کوشش کرتے ہیں۔ اور پہلے، ہم اسی curl کو TLS 1.3 کے ساتھ کام کرنے کے لیے eSNI استعمال کرنا سکھائیں گے، اور ساتھ ہی ہم دیکھیں گے کہ eSNI پر مبنی ڈومین فرنٹنگ خود کیسے کام کرتی ہے۔
eSNI کے ساتھ ڈومین فرنٹنگ
اس حقیقت کی وجہ سے کہ curl https پروٹوکول کے ذریعے جڑنے کے لیے معیاری openssl لائبریری کا استعمال کرتا ہے، سب سے پہلے ہمیں وہاں eSNI سپورٹ فراہم کرنے کی ضرورت ہے۔ اوپن ایس ایل ماسٹر برانچز میں ابھی تک کوئی ای ایس این آئی سپورٹ نہیں ہے، اس لیے ہمیں ایک خصوصی اوپن ایس ایل برانچ ڈاؤن لوڈ کرنے، اسے کمپائل اور انسٹال کرنے کی ضرورت ہے۔
ہم GitHub سے ذخیرہ کلون کرتے ہیں اور حسب معمول مرتب کرتے ہیں:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
اگلا، ہم ریپوزٹری کو curl کے ساتھ کلون کرتے ہیں اور اپنی مرتب شدہ اوپن ایس ایل لائبریری کا استعمال کرتے ہوئے اس کی تالیف کو ترتیب دیتے ہیں:
$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni
$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug
یہاں یہ ضروری ہے کہ ان تمام ڈائریکٹریوں کو درست طریقے سے بیان کیا جائے جہاں openssl واقع ہے (ہمارے معاملے میں، یہ ہے /opt/openssl/) اور اس بات کو یقینی بنائیں کہ کنفیگریشن کا عمل بغیر کسی غلطی کے گزرے۔
اگر ترتیب کامیاب ہے، تو ہم لائن دیکھیں گے:
انتباہ: esni ESNI فعال ہے لیکن تجرباتی نشان زد ہے۔ احتیاط کے ساتھ استعمال کریں!
$ makeپیکیج کو کامیابی کے ساتھ بنانے کے بعد، ہم curl کو ترتیب دینے اور چلانے کے لیے openssl سے ایک خصوصی bash فائل استعمال کریں گے۔ آئیے سہولت کے لیے اسے ڈائرکٹری میں curl کے ساتھ کاپی کریں:
cp /opt/openssl/esnistuff/curl-esni اور کلاؤڈ فلیئر سرور سے ایک ٹیسٹ https کی درخواست کریں، جبکہ Wireshark میں بیک وقت DNS اور TLS پیکٹ ریکارڈ کر رہے ہوں۔
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/سرور کے جواب میں، openssl اور curl سے بہت ساری ڈیبگنگ معلومات کے علاوہ، ہمیں کلاؤڈ فلیئر سے کوڈ 301 کے ساتھ ایک HTTP جواب موصول ہوگا۔
HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/
جو اس بات کی نشاندہی کرتا ہے کہ ہماری درخواست کو کامیابی کے ساتھ منزل کے سرور تک پہنچا دیا گیا، سنا اور اس پر کارروائی کی گئی۔
اب آئیے وائر شارک میں ٹریفک ڈمپ کو دیکھتے ہیں، یعنی فراہم کنندہ DPI نے اس معاملے میں کیا دیکھا۔
یہ دیکھا جا سکتا ہے کہ curl نے سب سے پہلے کلاؤڈ فلیئر سرور کے لیے عوامی eSNI کلید کے لیے DNS سرور کی طرف رجوع کیا - _esni.cloudflare.com پر ایک TXT DNS درخواست (پیکیج نمبر 13)۔ پھر، openssl لائبریری کا استعمال کرتے ہوئے، curl نے کلاؤڈ فلیئر سرور کو TLS 1.3 کی درخواست بھیجی جس میں SNI فیلڈ کو پچھلے مرحلے میں حاصل کردہ عوامی کلید کے ساتھ خفیہ کیا گیا تھا (پیکٹ #22)۔ لیکن، eSNI فیلڈ کے علاوہ، SSL-hello پیکٹ میں معمول کے ساتھ ایک فیلڈ بھی شامل ہے - اوپن SNI، جسے ہم کسی بھی ترتیب میں بیان کر سکتے ہیں (اس معاملے میں - ).
کلاؤڈ فلیئر سرورز کے ذریعے کارروائی کرتے وقت اس کھلے SNI فیلڈ کو کسی بھی طرح سے ذہن میں نہیں رکھا گیا تھا اور صرف فراہم کنندہ DPI کے لیے ایک ماسک کے طور پر کام کیا گیا تھا۔ کلاؤڈ فلیئر سرور کو ہمارا ssl-hello پیکٹ موصول ہوا، eSNI کو ڈکرپٹ کیا، وہاں سے اصل SNI نکالا اور اس پر اس طرح کارروائی کی جیسے کچھ ہوا ہی نہیں تھا (اس نے eSNI تیار کرتے وقت منصوبہ بندی کے مطابق سب کچھ کیا)۔
DPI نقطہ نظر سے اس معاملے میں صرف ایک چیز پکڑی جا سکتی ہے وہ ہے _esni.cloudflare.com پر بنیادی DNS درخواست۔ لیکن ہم نے DNS درخواست کو صرف یہ دکھانے کے لیے کھولا کہ یہ طریقہ کار اندر سے کیسے کام کرتا ہے۔
آخر کار DPI کے نیچے سے قالین نکالنے کے لیے، ہم پہلے سے ذکر کردہ DNS-over-HTTPS میکانزم کا استعمال کرتے ہیں۔ ایک چھوٹی سی وضاحت - DOH ایک پروٹوکول ہے جو آپ کو HTTPS پر DNS درخواست بھیج کر درمیانی درجے کے حملے سے بچانے کی اجازت دیتا ہے۔
آئیے دوبارہ درخواست پر عمل کریں، لیکن اس بار ہمیں https پروٹوکول کے ذریعے عوامی eSNI کیز موصول ہوں گی، DNS کے ذریعے نہیں:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/درخواست ٹریفک ڈمپ ذیل میں اسکرین شاٹ میں دکھایا گیا ہے:
یہ دیکھا جا سکتا ہے کہ curl پہلے mozilla.cloudflare-dns.com سرور تک DoH پروٹوکول (سرور 104.16.249.249 سے https کنکشن) کے ذریعے رسائی حاصل کرتا ہے تاکہ ان سے SNI انکرپشن کے لیے عوامی کلیدوں کی قدریں حاصل کی جا سکیں، اور پھر منزل تک سرور، ڈومین کے پیچھے چھپا ہوا ہے۔ .
مندرجہ بالا DoH ریزولور mozilla.cloudflare-dns.com کے علاوہ، ہم دیگر مشہور DoH سروسز استعمال کر سکتے ہیں، مثال کے طور پر، مشہور بری کارپوریشن سے۔
آئیے درج ذیل استفسار کو چلائیں:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/اور ہمیں جواب ملتا ہے:
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH
اس معاملے میں، ہم نے DoH ریزولور dns.google کا استعمال کرتے ہوئے بلاک شدہ rutracker.nl سرور کا رخ کیا (یہاں کوئی ٹائپنگ نہیں ہے، اب مشہور کارپوریشن کا اپنا فرسٹ لیول ڈومین ہے) اور اپنے آپ کو ایک اور ڈومین سے ڈھانپ لیا، جو کہ سختی سے تمام DPIs کے لیے موت کے درد کے تحت بلاک کرنا ممنوع ہے۔ موصول ہونے والے جواب کی بنیاد پر، آپ سمجھ سکتے ہیں کہ ہماری درخواست پر کامیابی سے کارروائی کی گئی تھی۔
ایک اضافی چیک کے طور پر کہ فراہم کنندہ کا DPI کھلے SNI کا جواب دیتا ہے، جسے ہم ایک کور کے طور پر منتقل کرتے ہیں، ہم کسی دوسرے ممنوعہ وسائل کی آڑ میں rutracker.nl سے درخواست کر سکتے ہیں، مثال کے طور پر، ایک اور "اچھا" ٹورینٹ ٹریکر:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/ہمیں سرور سے کوئی جواب نہیں ملے گا، کیونکہ... ہماری درخواست کو DPI سسٹم کے ذریعے بلاک کر دیا جائے گا۔
پہلے حصے کا مختصر نتیجہ
لہذا، ہم openssl اور curl کا استعمال کرتے ہوئے eSNI کی فعالیت کا مظاہرہ کرنے اور eSNI کی بنیاد پر ڈومین فرنٹنگ کے آپریشن کی جانچ کرنے کے قابل تھے۔ اسی طرح، ہم اپنے پسندیدہ ٹولز کو ڈھال سکتے ہیں جو اوپن ایس ایل لائبریری کو دوسرے ڈومینز کی "آڑ میں" کام کرنے کے لیے استعمال کرتے ہیں۔ اس بارے میں مزید تفصیلات ہمارے اگلے مضامین میں۔
ماخذ: www.habr.com