امنیت سایبری ۱۰۱ ویژه فعالان حقوق بشر، فعالان مدنی، فعالان سیاسی، روزنامه نگاران و براندازان: تکنیک Domain Fronting گلوله نقره‌ای دور زدن هرگونه فیلترینگ آتی اینترنت توسط جمهوری اسلامی

Domain Fronting

Domain Fronting

بسیار خب. اجازه می‌خواهم پیش از پرداختن به گلوله نقره‌ای یا برگ آس براندازان در دور زدن فیلترینگ اینترنت (مشابه آنچه که در خیزش آبان‌ماه ۹۸ مشاهده شد) یعنی تکنیک Domain Fronting، به مفهومی تحت عنوان Collateral Freedom بپردازم:

Collateral freedom is an anti-censorship strategy that attempts to make it economically prohibitive for censors to block content on the Internet. This is achieved by hosting content on cloud services that are considered by censors to be “too important to block,” and then using encryption to prevent censors from identifying requests for censored information that is hosted among other content, forcing censors to either allow access to the censored information or take down entire services.

Collateral Freedom، یک استراتژی ضد سانسور است که سعی می‌نماید بلوکه نمودن محتوا بر روی اینترنت برای سانسورچی‌ها را از منظر اقتصادی بسیار پرهزینه و یا غیرقابل جبران نماید. این امر با میزبانی مطالب در سرویس‌های ابری که توسط سانسورچی‌ها “بسیار مهم و غیرقابل بلاک تلقی می‌شود”، و سپس استفاده از رمزگذاری به منظور ممانعت از شناسایی درخواست‌های دسترسی به اطلاعات سانسور شده توسط سانسورچی‌ها، که در میان سایر محتواها میزبانی می‌شوند، میسر می‌شود، که سانسورچی‌ها را مجبور می‌نماید یا اجازه دسترسی به اطلاعات سانسور شده را صادر نموده و یا سرویس‌های متعددی را کاملا از کار بیاندازند.

در واقع Domain Fronting تکنیکی جهت پیاده‌سازی Collateral Freedom می‌باشد که در ادامه مطلب بدان خواهیم پرداخت.

سلب مسئولیت

شما با ادامه مطالعه این مطلب، موافقت کامل خود با این توافق نامه را اعلام می‌نمایید:

تمامی محتویات این وب سایت تحت مجوز (CC BY-SA 3.0) Creative Commons Attribution-ShareAlike 3.0 Unported License منتشر شده است. همچنین، تمامی سورس کدهای منتشر شده در این وب سایت تحت لیسانس MIT License منتشر شده است، مگر آن که به صراحت ذکر شده باشد. تمامی محتویات ارائه شده صرفا جنبه آموزشی و اطلاعاتی داشته و فاقد هرگونه ضمانت، تعهد یا شرایطی از هر نوع می باشد. بایستی توجه نمود که اطلاعات عرضه شده حتی ممکن است دقیق و یا بروز نباشد. هرگونه اطمینان به و یا استفاده از محتویات یا منابع منتشر شده در این وب سایت با مسئولیت مخاطب بوده و نگارنده یا نگارندگان هیچ گونه مسئولیتی در مورد عواقب آن را نخواهند پذیرفت.

پروتکل TLS چیست؟

پروتکل TLS، جانشین پروتکل قدیمی‌تر SSL (که با استادندارهای امروزی نا‌امن می‌باشد)، یک پروتکل رمزنگاری است که به منظور برقراری یکپارچگی و حفظ حریم خصوصی بین برنامه ها طراحی شده است. متداول ترین کاربرد TLS در HTTPS است که همان HTTP از طریق TLS (یا SSL) می‌باشد. با استفاده از TLS، دو دستگاه کامپیوتر یا موبایل می توانند ارتباطاتی ایمن را از طریق اینترنت برقرار نمایند. این پروتکل مانع از مشاهده، اصلاح یا جعل پیام های بین آنها، توسط نفوذگرها یا استراق‌سمع‌کنندگان می‌شود.

همچنین پروتکل TLS در پروتکل شبکه QUIC که در سال 2012 توسط گوگل طراحی شده و هنوز در دست توسعه می‌باشد، مورد استفاده قرار می گیرد. این پروتکل قرار است جایگزین پروتکل‌های HTTP/HTTPS شود. QUIC به جای استفاده از TCP، از UDP بعنوان لایه انتقال داده استفاده می‌نماید.

آخرین نسخه پروتکل TLS نسخه 1.3 می‌باشد که در سال 2018 تصویب شده است. TLSv1.3 شامل تغییرات بسیار مهمی است که مهمترین آن‌ها حذف الگوریتم‌های رمزنگاری قدیمی، مستهلک و ناامنی است که نباید در سال 2018 مورد استفاده قرار بگیرند. از دیگر ویژگی‌های این نسخه، سرعت بخشیدن ارتباطات امن از طریق TLS False Start و 0-RTT می‌باشد.

از دیگر تغییرات آخرین نسخه TLS، اجباری نمودن افزونه SNI می‌باشد.

SNI چیست؟

افزونه SNI و یا Server Name Indication، یکی از افزونه‌های پیشنهادی تحت RFC4366 برای پروتکل امنیتی لایه انتقال می‌باشد که در سال 2006 پیشنهاد شده است.

با پروتکل HTTP/1.0، یک سرور وب تنها قادر به ارائه یک وب سایت بر روی هر آدرس IP بود زیرا راهی برای شناخت نام میزبان استفاده شده برای درخواست سایت نداشت. پروتکل HTTP/1.1 مفهوم هدر Host یا “میزبان” را معرفی نمود که امکان میزبانی چندین وب‌سایت را تحت عنوان Virtual Host یا میزبان مجازی بر روی یک سرور وب میسر می‌نماید.

در واقع SNI استانداردی معادل همین مفهوم در HTTP/1.1، به منظور میزبانی چندین وب‌سایت با گواهینامه‌های SSL متفاوت بر روی یک سرور وب در پروتکل HTTPS می‌باشد. با استفاده از آن یک کلاینت در ابتدای فرآیند اتصال به سرور نام دامین مدنظر خود را که بر روی یک سرور اشتراکی میزبانی می‌شود را تعیین می‌نماید. این امر به سرور اجازه می دهد تا چندین گواهینامه را بر روی همان آدرس IP و شماره پورت TCP یکسان ارائه دهد و از این رو اجازه می دهد تا چندین وب سایت ایمن HTTPS (یا هر سرویس دیگری از طریق TLS) توسط همان آدرس IP، بدون مجبور نمودن تمامی وب‌سایت‌ها به استفاده از یک گواهینامه، ارائه شود.

متاسفانه ایراد امنیتی SNI (که در واقع از اساس یک ضعف امنیتی در پروتکل TLS است) نشت نام هاست (دامین/وب‌سایت) مورد درخواست می‌باشد. این امر بدان دلیل است که رد و بدل نام دامین در SNI به شکل غیررمزگذاری شده یا به اصطلاح امر Plaintext صورت می‌پذیرد که به استراق‌سمع‌کننده اجازه شنود نام هاست درخواستی توسط کاربر را می‌دهد. لذا، چنین آسیب‌پذیری امکان توسعه و اجرای فیلترینگ اینترنت به شکل بسیار کارآمد را در اختیار دولت‌ها قرار می‌دهد.

دلایل واقعی و محکمی جهت اجباری نمودن SNI در آخرین نسخه پروتکل TLS وجود دارد اما از آنجایی که SNI در ایجاد هر اتصال TLSv1.3 نام میزبان را نشت می دهد، نگاهی به پیش نویس شماره ۰۷ بررسی تکنیک های سانسور در سراسر جهان بوضوح از نقش آن به عنوان پاشنه آشیل TLS پرده‌برداری می‌نماید.

نمونه‌ای از شنود درخواست مبتنی بر پروتکل TLS نسخه 1.2 توسط نرم‌افزار Wireshark که بخوبی نام هاست درخواستی کاربر یعنی fa.babaei.net را آشکار می‌سازد

نمونه‌ای از شنود درخواست مبتنی بر پروتکل TLS نسخه 1.2 توسط نرم‌افزار Wireshark که بخوبی نام هاست درخواستی کاربر یعنی fa.babaei.net را آشکار می‌سازد

بدلیل آسیب‌پذیری فوق‌الذکر، یک بروزرسانی تحت عنوان ESNI سرنام عبارت Encrypted SNI یا SNI رمزگذاری شده، مطرح شده است که در حال حاضر در مرحله آزمایشی به سر می‌برد. نتیجه هرچه که باشد، پیاده‌سازی کامل آن بر روی بستر وب بدلیل آنکه چندین سال طول می‌کشد تا تمامی دستگاه‌های کاربران اینترنت از نسخه‌های جدیدتر پروتکل‌ها پشتیبانی نمایند، عملا میسر نمی‌باشد. برای مثال TLSv1.2 در سال ۲۰۰۸ منتشر شده است در حالیکه نسخه نهایی TLVSv1.3 در سال ۲۰۱۸ منتشر شده است. لذا بعنوان نمونه مرورگرها یا دستگاه‌های موبایل قدیمی که پیش از این تاریخ عرضه شده‌ و دیگر بروزرسانی نمی‌شوند امکان استفاده از وب‌سایت‌های فعال با نسخه TLSv1.2 را نخواهند داشت. بنابراین تمامی وب‌سایت‌ها بدلیل سازگار ماندن با کاربران قدیمی‌تر، هنوز به پروتکل TLVSv1.3 کوچ ننموده‌اند. پس نمی توان انتظار داشت که به محض عرضه ESNI سریعا تمامی سرورهای وب آنرا به شکل پیش‌فرض فعال نمایند و یا حتی توسط تمامی کاربران قابل استفاده باشد.

بسیار خب، با این اوصاف راه حل چیست؟ پاسخ این است: تکنیکی آزموده شده تحت عنوان Domain Fronting!

تکنیک Domain Fronting چیست؟

اجازه دهید تشریح تکنیک Domain Fronting را جهت درک بهتر با مثالی ساده شده از دنیای واقعی شروع نمایم.

فرض کنید در شهر یا روستای کوچکی یک خوابگاه دانشجویی وجود داشته باشد که تعدادی دانشجو در آن زندگی می‌نمایند. دست بر قضا مامور پست با یکی از این دانشجویان خصومت شخصی دارد و نامه‌ها یا بسته‌هایی که برای وی ارسال می‌شود و نام او بر روی آن‌ها ذکر شده است را به جای تحویل به آن شخص، دور بیاندازد. البته مامور پست بدلیل آنکه بسته در صندوقچه امنی قرار گرفته امکان گشودن بسته را ندارد اما به جهت انتقام آن را سر به نیست می‌کند که امری امکان‌پذیر و ساده‌تر می‌نماید.

خب راه حل دور زدن این مامور پست چیست؟

ساده‌ترین راه‌حل ممکن که در ذهن تداعی می‌شود، نوشتن نام دانشجوی دیگری بر روی بسته پستی می‌باشد. مامور پست با نگاه به نام روی بسته هرگز متوجه نخواهد شد که مقصد بسته دانشجوی مدنظر ما خواهد بود. لذا بسته مثلا به دانشجوی هم‌اتاقی دانشجوی هدف تحویل خواهد شد و می‌توان با یادداشتی در درون بسته که مامور پست از آن اطلاعی ندارد یا هماهنگی قبلی در نهایت بسته را به دست دانشجوی مورد‌نظر رساند.

در واقع Domain Fronting از مفهومی مشابه مثال فوق جهت ارسال موفقیت‌آمیز درخواست‌ها به وب‌سایت سانسور شده استفاده می‌نماید.

تکنیک Domain Fronting به منظور مبهم‌نمودن فیلد SNI در یک اتصال TLS کاربرد دارد که به طور بسیار موثری در هنگام آغاز اتصال به یک سرور، قادر به پنهان سازی نام دامنه هدف می‌باشد. این امر نیازمند یافتن یک ارائه دهنده خدمات میزبانی یا CDN (مخفف Content Delivery Network یا شبکه تحویل محتوا) می‌باشد كه دارای گواهینامه‌ای است كه از چندین دامنه هدف (معروف به SAN سرنام واژه فنی Subject Alternative Names) پشتیبانی نموده و حداقل یکی از دامنه‌های آن فیلتر نباشد. چنانچه دامنه یا وب‌سایت تحت سانسور خود را بر روی سرور و یا شبکه تحویل محتوای آن‌ها قرار دهید، قادر خواهید بود که در زمان برقراری اتصال با دستکاری نمودن و تغییر فیلد SNI درخواست مبتنی بر HTTPS خود، وانمود نمایید که می‌خواهید به یکی از دامین‌های فیلترنشده دسترسی نمایید در حالیکه که در بدنه آن درخواست، درست مشابه مثال خوابگاه دانشجویی، درخواست را به دامین هدف ارسال می‌نمایید!! بله، مانند رونالدینیو سمت چپ را نگاه می‌کنید ولی پاس را به سمت راست ارسال می‌کنید!

گواهینامه SSL شرکت گوگل - جهت مشاهده این گواهینامه به آدرس https://appengine.google.com در مرورگر خود مراجعه و قسمت SAN این گواهینامه را بررسی نمایید

گواهینامه SSL شرکت گوگل - جهت مشاهده این گواهینامه به آدرس https://appengine.google.com در مرورگر خود مراجعه و قسمت SAN این گواهینامه را بررسی نمایید

باور کنید یا نه، این روش بخوبی از پس دور زدن هر نوع فیلترینگ احتمالی در ایران از جنس آنچه که در خیزش آبان‌ماه ۹۸ مشاهده نمودیم برخواهد آمد. در واقع Domain Fronting یک ایده نو نمی‌باشد بلکه سال‌هاست از آن در دور زدن فیلترینگ در کشورهایی نظیر چین، روسیه، مصر، عمان، قطر، و امارت متحده عربی استفاده شده است. حتی بدلیل پشتیبانی از ویژگی تحت عنوان Pluggable Transports در شبکه و نرم‌افزار Tor یک به اصطلاح PT برای آن به منظور دور زدن فیلترینگ با استفاده از تکنیک Domain Fronting تحت عنوان meek توسعه داده شده است.

علاوه بر این‌ها پیام‌رسان بسیار امن سیگنال بمدت یک‌سال و نیم از این تکنیک جهت دور زدن فیلترینگ این پیام‌رسان در کشورهای مصر، عمان، قطر، و امارت متحده عربی استفاده نموده است. این در حالیست که این کار به هیچ تنظیم و یا عملی از سوی کاربران نیاز نداشته است. آنها به راحتی می توانسته‌اند برنامه را نصب نموده و از آن به طور عادی استفاده نمایند.

سیگنال برای انجام این مهم از سرویس‌های Amazon Cloudfront و Google App Engine استفاده نموده است. متاسفانه بدلیل تفسیر نادرست کمپانی گوگل از تحریم‌های وضع شده در مورد ایران، آن‌ها تمامی آدرس‌های IP از ایران را بلاک نموده‌اند. لذا با وجود این‌که درخواست‌ها با کمک تکنیک Domain Fronting از فیلترینگ ایران رد می‌شده است، بدلیل بلاک شدن آن‌ها توسط گوگل امکان سرویس‌دهی این پیام‌رسان به شکل مستقیم به کاربران ایرانی مهیا نشده است. علی‌رغم فشارهای وارده بر گوگل و شکست خوردن تلاش‌های لابی‌گرانه برای ارائه این قابلیت به کاربران ایرانی، شرکت گوگل تصمیم به از کارانداختن کامل ویژگی Domain Fronting در سرورهای Google App Engine می‌نماید. لذا توسعه‌دهندگان سیگنال تصیمیم به سوییچ به سرورهای Amazon Cloudfront می‌گیرند.

از آنجایی که سیگنال یک پروژه متن‌باز یا Open Source می‌باشد و کد آن در وب‌سایت GitHub میزبانی می‌شود، فردی کامیت تغییرات در کد سیگنال را در گیت‌هاب این شرکت مشاهده نموده و با ارسال آن به وب‌سایت Hacker News باعث محبوب شدن پست توسط کاربران، رسیدن آن به صفحه آغازین HN و دیده شدن آن توسط مسئولان شرکت آمازون می‌شود. علی‌رغم آنکه Domain Fronting عملی برخلاف توافقنامه استفاده از سرویس کلادفرانت نمی‌باشد، آمازون با بهانه نمودن این موضوع اقدام به از کارانداختن این ویژگی در سرویس‌های خود می‌نماید.

تمامی این جزییات در مطلبی در وبلاگ رسمی پیام‌رسان سیگنال مطرح شده‌اند.

خاطرنشان می‌شود از سوی دیگر بسیاری از جمله The Verge، FastCompany، و Bloomberg معتقدند که این تلاش‌ها از سوی گوگل و آمازون به منظور غیر‌فعال نمودن Domain Fronting تا حدود زیادی ناشی از فشار دولت روسیه بر فعالیت دامنه تلگرام با استفاده از خدمات ابری هر دو شرکت بوده است. در برهه‌ای از زمان دولت روسیه اقدام به بلوکه نمودن بیش از ۱۶ میلیون آدرس IP متعلق به گوگل و آمازون نمود. حاصل این اقدامات از کارافتادن سرویس بازی ایکس‌باکس مایکروسافت، اپلیکیشن یادداشت برداری Evernote، پیام‌رسان وایبر، شبکه اجتماعی روسی Odnoklassniki، وب‌سایت ایستگاه رادیویی Govorit Moskva، سرویس تحویل غذای Ptichka و بسیاری سرویس‌های دیگر بود (Collateral Freedom و خسارت تحمیلی ناشی از آن بر سانسورچی که Collateral Damage نامیده می‌شود، در ذهن تداعی می‌شود).

اما آیا این به این معنی است که Domain Fronting بلااستفاده شده و دیگر کاربردی ندارد؟

همانطور که در ادامه خواهیم دید، پاسخ به این سوال خیر است. چرا که آمازون و گوگل تنها شرکت‌های عمده عرضه CDN و خدمات میزبانی نمی‌باشند. بلکه، سرویس‌های دیگر و بسیار مشهور نظیر Microsoft Azure، Akamai، Fastly، Level 3، Netlify، CDN77، و … از این ویژگی پشتیبانی می‌نمایند. البته برخی از این سرویس‌ها در شرایط استفاده خود صراحتا استفاده از Domain Fronting را تخلف از سرویس‌های خود تلقی نموده‌اند و برخی دیگر خیر. در ادامه مطلب در قسمت جزییات فنی جزییات بیشتری از این سرویس‌ها را مورد بررسی قرار خواهیم داد.

اما سوال اساسی اینجاست که مگر جمهوری اسلامی در شرایط بحران بطور معمول اقدام به قطع نمودن کامل اینترنت خارج از کشور و یا ایزوله نمودن کامل اینترنت داخلی از خارجی نمی‌نماید؟

پاسخ به این سوال منفی است! اینترنت هرگز در ایران بطور کامل قطع نبوده است. بعنوان مثال، قبلا در مطلبی به یکی از روش‌های وصل شدن به اینترنت در آن زمان اشاره نموده بودم. در واقع اینترنت از دسترس بخش عمده‌ای از جامعه ایران بدلیل غافلگیری و نیازمندی به دانش پیچیده فنی خارج شد، در حالی‌که کاربران فنی‌تر داخل کشور سریعا راهکارهای متعددی برای اتصال به اینترنت را در آن شرایط پیدا نمودند. شنیده‌ها حاکی از آن است که حتی ظرف همان چند روز مافیای اینترنت در ایران شکل گرفته بود و مانند نصاب‌های ماهواره، افرادی تحت عنوان نصاب‌های اینترنت آزاد، در ازای مبالغی از ۲۵‌هزارتومان تا مبالغ گزافی در حدود ۱.۵ میلیون تومان در ماه، به درخواست شهروندان تهرانی، برای نصب و راه‌اندازی اینترنت آزاد به درب منازل مراجعه می‌نموده‌اند.

یکی از روش‌های دسترسی به اینترنت در خلال قطعی اینترنت در اعتراضات سراسری مردمی و ضدحکومتی آبان‌ماه ۱۳۹۸ ایران

یکی از روش‌های دسترسی به اینترنت در خلال قطعی اینترنت در اعتراضات سراسری مردمی و ضدحکومتی آبان‌ماه ۱۳۹۸ ایران

باید توجه داشت که آن چیزی که مدنظر رهبران جمهوری اسلامی است، تاکنون تنها در کشور کره شمالی انجام شده است و تحت عنوان Kwangmyong و یا کوانگیمونگ شناخته می‌شود. این نوع از تفکیک و جداسازی شبکه اینترنت و اینترانت در سطح وسیع حتی در روسیه، چین، کوبا، و یا میانمار نیز اجرا نشده است.

علی‌رغم این‌که جمهوری اسلامی از سال ۲۰۰۶ که لیست دشمنان اینترنت توسط گزارشگران بدون مرز تهیه می‌شده است، همواره پای ثابت این لیست بوده است، خوشبختانه به شکل بلندمدت هرگز توانایی پیاده‌سازی راهکار عملی و موفقیت‌آمیزی جهت کره‌شمالی‌سازی اینترنت ایران نداشته است. شکی نیست که آن‌ها همیشه آرزوی آنرا در سر پرورانده‌ و حتی سعی هم نموده‌اند، اما هرگز موفق نبوده‌اند.

دلیل این امر چیست؟ یعنی واقعا جمهوری اسلامی توانایی قطع نمودن کامل اینترنت را نداشته یا ندارد؟

مطمئن هستم که بسیاری از افراد دست به دست شدن گزارشی از میزان خسارت ۳۷۰ میلیون دلاری ناشی از قطعی اینترنت ایران در یک روز توسط نت‌بلاکز را در شبکه‌های اجتماعی به خاطر دارند (این محاسبه هزینه‌ها از طریق وب‌سایت این موسسه در دسترس بود که گویا هم‌اکنون از دسترس خارج شده است):

خسارت ناشی از قطعی اینترنت ایران در یک روز به گزارش نت‌بلاکز

خسارت ناشی از قطعی اینترنت ایران در یک روز به گزارش نت‌بلاکز

باید اذعان داشت که پیش از وابستگی حکومت، مردم، نهادها و سازمان‌های دولتی، آموزشی، کسب و کارها و … به اینترنت و تکنولوژی شاید امکان کره‌شمالیزه اینترنت نمودن ایران وجود می‌داشت اما امروز بدلایل متعدد این امر میسر نیست. لحظه‌ای را تصور نمایید که:

  • هیچ تلفنی اندرویدی یا iOS بروزرسانی نمی‌شود
  • ویندوز بر روی کامپیوترها یا لپ‌تاپ‌ها بروزرسانی نمی‌شود
  • سرور‌های کسب و کارها، بانک‌ها یا ادارات و ارگان‌ها جهت رفع آسیب‌پذیری بروزرسانی نمی‌شوند؛ هک نمودن آن‌ها دیگر سخت نخواهد بود
  • هیچ آنتی‌ویروسی کار نخواهد کرد و لیسانس بسیاری از محصولات امنیتی از کار خواهد افتاد
  • سرویس دهنده‌های ایمیل چطور؟
  • میلیون‌ها کاربر ایرانی در دسترسی به حساب‌های خود در سرویس‌های داخلی و خارجی بدلیل عدم دسترسی به سرویس‌‌دهندهای ایمیل خود دچار مشکل خواهند شد
  • امکان بوکینگ هتل و پرواز خارجی وجود ندارد
  • امکان صحبت با بستگان، دوستان و عزیزان از طریق اینترنت وجود نداشته باشد
  • صرافی‌ها امکان نقل و انتقال پول را ندارند
  • امکان استفاده از اینستاگرام و سایر شبکه‌های اجتماعی وجود نخواهد داشت
  • دانشجویان و اساتید دانشگاه‌ها به مقالات علمی و بروز دسترسی نخواهند داشت
  • امکان اپلای نمودن برای دانشگاه‌ها و مقاطع تحصیلی بالاتر در خارج از کشور وجود نخواهد داشت
  • بسیاری از شرکت‌های نرم‌افزاری جهت توسعه نرم‌افزار‌ها که موردنیاز دولت و بخش خصوصی و مردم باشد به اینترنت دسترسی نداشته باشند
  • و بسیاری موارد دیگر

در واقع اگر آن‌ها می‌توانستند این کار را انجام دهند تا حالا انجام داده بودند! نه نشد! بگذارید دوباره جمله‌بندی کنم! آنها می توانند، اما آیا آنها این کار را انجام می دهند؟

آیا بدنه دولت شامل وزیران، معاونت‌ها، کارمندان، نیروهای نظامی و انتظامی و خانواده‌هایشان خود به جمع مخالفان نخواهند پیوست؟ مرزبندی بین خودی با دسترسی به اینترنت آزاد و غیر‌خودی با دسترسی به اینترانت دقیقا کجاست؟

خلاصه کلام آنکه بزعم من اینترنت محدودتر خواهد شد ولی هرگز قطع نخواهد شد؛ حتی به شکل مقطعی آن. اینترنت آزادتر از دسترس افراد عادی‌تر خارج خواهد شد ولی فنی‌ترها و افراد دور و بر آن‌ها کماکان به اینترنت دسترسی خواهند داشت. یقین دارم روزی که قطعی اینترنت به شکل کامل اتفاق بیافتد، روز آخر حکومت جمهوری اسلامی و آخرین تقلا برای ماندن در مسند قدرت خواهد بود. اگر چین و روسیه نتوانسته‌اند مدل کره‌شمالی اینترنت را پیاده‌سازی کنند یقین داشته باشید که جمهوری اسلامی هم بدلایل متعدد از جمله هزینه‌های تحمیلی، عدم در اختیار داشتن نیروی متخصص کافی و دانش لازمه هرگز توانایی پیاده‌سازی بلندمدت آنرا نخواهد داشت (آیا جمهوری اسلامی مثلا توانایی تولید سیستم‌عاملی جایگزین برای اندروید، iOS، ویندوز و … را خواهد داشت؟ به عنوان نمونه به تخمین Open Hub بر اساس مدل COCOMO، توسعه سیستم‌عاملی مانند اندروید ۵,۲۰۸ سال طول خواهد کشید! این تنها کلاینت اندروید می‌باشد و سرویس‌های آنلاین جانبی آن نظیر نقشه، لیست‌تماس‌ها، تقویم، ایمیل، بروزرسانی و … را شامل نمی‌شود).

بسیاری از سرویس‌هایی که لیست فوق مبتنی بر آنها کار می‌کند، هر یک بگونه‌ای براساس یکی از سرویس‌دهنده‌های CDN توسعه یافته و کار میکنند. برای مثال فیس‌بوک و طبعا اینستاگرام علاوه بر دیتاسنتر فیس‌بوک، با توجه به قدمت و کیفیت آن، از Akamai جهت هاست نمودن تصاویر و سرعت بخشیدن به استریم این فایل‌ها استفاده می‌نمایند. آکامای به تنهایی ۱۵ تا ۳۰ درصد ترافیک وب را دراختیار دارد.

بعنوان مثال دیگر، ترافیک ۲۹ درصد از یک میلیون وب‌سایت برتر در لیست الکسا، از سرویس مشهور و همه‌گیر Cloudflare میگذرد. حتی بسیاری از وب‌سایت‌های ایرانی از کلادفلیر بدلیل مزایای امنیتی نظیر سرویس Anti-DDoS آن علاوه بر سایر مزایا از قبیل گواهینامه SSL رایگان، و یا تسریع وب‌سایت‌هایشان استفاده می‌نمایند. مژده آنکه دور زدن فیلترینگ با استفاده از Domain Fronting و ESNI از طریق کلادفلیر امکان‌پذیر می‌باشد.

تمامی این‌ها به کنار، بسیاری از وب‌سایت‌های ایرانی و خارجی از سرویس‌دهندهای کلاد برای میزبانی فایل‌های فونت، جاوااسکریپت و یا CSS مربوط به فریم‌ورک‌های مشهور وب و طراحی سایت نظیر jQuery و … استفاده می‌نمایند. شک نداشته باشید که میلیون‌ها صفحه وب با فیلترنمودن این کلاد‌ها از کار خواهند افتاد.

در واقع Domain Fronting، نه تنها یک روش کارا و موثر به منظور دور زدن فیلترینگ اینترنت می‌باشد، بلکه در کشورهایی که دسترسی به اینترنت به طرز وحشتناکی بلوکه است، چیزی کمتر از یک انقلاب نیست، به این دلیل که:

۱. ترافیک فیلترشکن را همانند ترافیک معمولی HTTPS جلوه میدهد.

۲. اثرات جانبی بلوکه کردن آن (قطع دسترسی به سرویس‌دهنده‌های کلاد و متعاقب آن سرویس‌های مبتنی بر آن‌ها) برای سانسورچی‌ها بسیار گران تمام خواهد شد. فی‌الواقع بلاک نمودن Akamai, Cloudflare و … به شکل جزیی یا کلی در یک کشور ۸۰ میلیونی عملی نیست که بتوان به سادگی از کنار آن گذشت و توسط شهروندان آن مورد توجه واقع نشود.

هنوز متقاعد نشده‌اید؟ یک‌بار دیگر شما را به خواندن مفهوم Collateral Freedom در ابتدای این مطلب دعوت می‌نمایم.

نکته‌ ظریفی که نباید از آن غافل شد این است که: در زمان قطعی اینترنت، بسیاری از کاربران با برپایی طوفان توییتری و امضای پتیشن از ایالات متحده خواستار اینترنت آزاد ماهواره شده بودند. در همان زمان مطلبی به رشته تحریر درآوردم که چرا اینترنت ماهواره‌ای به شکل گسترده و یا اینترنت چمدانی و بالونی و … خیال خام و رویای شیرینی بیش نیست. بایستی عرض نمایم که اگر قصد تهیه پتیشن، برپایی طوفان توییتری و … را دارید، بایستی در جهت راهکاری امکان پذیر و اثبات‌شده باشد که جواب خود را پس داده است. بزعم من Domain Fronting یک راهکار عالی خواهد بود. توجه داشته باشید که درخواست فعال نمودن ویژگی Domain Fronting برای کاربران ایرانی از دولت آمریکا، آمازون، گوگل و … و یا لابی‌گری با آن‌ها به مراتب شدنی‌تر و دست‌یافتنی‌تر از اینترنت چمدانی، بالونی یا ماهواره‌ای خواهد بود.

تشریح فنی Domain Fronting

بسیار خب، پس از آشنایی با مفهوم Domain Fronting، فکر می‌کنم که دیاگرام ذیل بخوبی جزییات فنی این تکنیک را تشریح نماید:

تشریح فنی Domain Fronting

تشریح فنی Domain Fronting

جهت تشریح عملی و آزمایش نحوه کارکرد تکنیک Domain Fronting می‌توان از ابزارهای خط فرمان نظیر wget, openssl, curl و … استفاده نمود. در ادامه این مطلب ما از ابزار curl به منظور تشریح Domain Fronting استفاده می‌نماییم.

بعنوان یک نمونه واقعی، دامین‌های fa.babaei.net و barandazstorm.com در حال حاضر بر روی یک سرور میزبانی می‌شوند. فرض کنید دامین barandazstorm.com فیلتر می‌باشد اما دامین babaei.net خیر. اگر به وب‌سایت fa.babaei.net مراجعه نمایید با وبلاگ فعلی مواجه خواهید شد، اما اگر به وب‌سایت barandazstorm.com مراجعه نمایید با صفحه‌ای حاوی یک انیمیشن با پیام در دست ساخت و عنوان صفحه Under Construction مواجه خواهید شد. حالا اجازه دهید درخواست دسترسی به وب‌سایت barandazstorm.com را با استفاده از وب‌سایت fa.babaei.net صادر نماییم:

$ curl -s -H "Host: www.barandazstorm.com" https://fa.babaei.net | grep '<title>'

خروجی دستور فوق به جای برگرداندن عنوان وب‌سایت fa.babaei.net، عنوان وب‌سایت barandazstorm.com خواهد بود:

        <title>Under Construction...</title>

دقت کنید که ما در مثال فوق سورس‌کد HTML صفحه را با استفاده از ابزار curl دانلود نموده‌ایم بنابراین اگر قسمت بعد از علامت pipe در یونیکس یعنی| که دستور grep می‌باشد را پاک نمایید بجای سورس HTML وب‌سایت fa.babaei.net با سورس barandazstorm.com مواجه خواهید شد.

اما با اجرای دستور فوق دقیقا چه اتفاقی افتاد؟ در دستور فوق به عنوان پارامتر -H ما نام دامین بلاک شده و مخفی را (در این مثال barandazstorm.com) در قسمت درخواست هدر HTTP به عنوان هدف واقعی تعیین نمودیم. سپس هدف جعلی را دامین fa.babaei.net که پشت آن مخفی می‌شویم، تعیین نمودیم. دستور curl در زمان ساخت و ارسال دریافت، نام هدف جعلی یعنی fa.babaei.net را در فیلد SNI درخواست HTTPS قرار خواهد داد. بنابراین:

۱. سانسورچی با نگاه به فیلد SNI و مشاهده نام دامنه fa.babaei.net اجازه عبور درخواست را خواهد داد.

۲. درخواست به سرور رسیده و نرم‌افزار سرور وب (مثلا Nginx یا Apache) با توجه به محتوای فیلد هاست در درخواست اصلی (دامنه barandazstorm.com) محتوای وب‌سایت barandazstorm.com را به عنوان پاسخ درخواست ما فراهم می‌نماید.

حالا اجازه دهید حالت دیگری را تست نماییم. از سرور bing.com متعلق به شرکت مایکروسافت، درخواست محتوای دامنه google.com را مطرح نماییم:

$ curl -s -H "Host: google.com" bing.com
<h2>Our services aren't available right now</h2><p>We're working to restore all services as soon as possible. Please check back soon.</p>06XZVXAAAAAD6lfm8665lRL+M0r8EuYmDTFRTRURHRTA1MTMARWRnZQ==

همانطور که مشاهده می‌نمایید، از آنجایی که وب‌سایت google.com توسط سرور bing.com میزبانی نمی‌شود، با یک پیغام خطا از سوی نرم‌افزار سرور وب شرکت مایکروسافت مواجه می‌شویم. بیایید این‌بار از سرور گوگل در انگلیس درخواست محتوای وب‌سایت گوگل در آلمان را مطرح نموده و محتوای آن را جهت بررسی در یک فایل .html ذخیره نماییم:

$ curl -H "host: www.google.de" www.google.co.uk -o ~/google-de.html

پس از بررسی فایل متوجه خواهید شد که محتوای صفحه آغازین گوگل به زبان آلمانی از سوی سرور گوگل در انگلیس، در پاسخ به درخواست شما ارسال شده است.

بسیار خب، پس از آشنایی عملی با تکنیک Domain Fronting، حالا می‌دانیم که در زمان بلاک گسترده اینترنت، می‌توان با استفاده از تکنیک Domain Fronting محتوای وب‌سایت‌هایی که لازم است عموم مردم آزادانه بدان دسترسی داشته باشند می‌توانند برای مثال بر روی سرویس مایکروسافت آژور قرار گرفته و با تکنیک دامین فرانتینگ در اختیار عموم در ایران قرار داد. یا حتی بهتر از آن سرورهای meek یا Cloak که در ادامه بدان‌ها خواهیم پرداخت را جهت دسترسی به کل اینترنت در این سرویس اجاره، تنظیم و در اختیار عموم مردم در ایران قرار داد. یک تست سریع نشان می‌دهد که سرویس Microsoft Azure در زمان نگارش این نوشتار بخوبی از Domain Fronting پشتیبانی می‌نماید:

$ curl -s -H "Host: meek.azureedge.net" https://ajax.aspnetcdn.com
I’m just a happy little web server.

جهت تست سایر سرویس‌دهنده‌های CDN، می‌توانید به صفحه مستندات meek در وب‌سایت پروژه Tor مراجعه نمایید.

پیش از خاتمه تشریح فنی تکنیک Domain Fronting ممکن است یک سوال در ذهن کاربران آشنا به پروتکل TLS و گواهینامه‌های SSL ایجاد شود که شفاف‌سازی آن را لازم می‌دانم. آیا عدم تطابق نام دامنه در گواهینامه‌های SSL دردسرساز نمی‌شود؟ آیا عدم تطابق نام دامنه‌ها در هدرها باعث دریافت هشدار عدم تطابق گواهینامه توسط نرم‌افزارها و سرور وب نمی‌شود؟

باید گفت سوال بسیار خوبی است و پاسخ کوتاه به آن: خیر!

برای دریافت پاسخ بلند‌تر نیاز به بررسی عمیق‌تر و بحث فنی‌تری داریم. در مثال اول، چنانچه قسمت SAN گواهینامه‌ وب‌سایت‌های fa.babaei.net و barandazstorm.com را مطالعه نماییم به خوبی به عدم تطابق گواهینامه این وب‌سایت‌ها پی می‌بریم:

گواهینامه SSL برای fa.babaei.net

گواهینامه SSL برای fa.babaei.net

گواهینامه SSL برای barandazstorm.com

گواهینامه SSL برای barandazstorm.com

اما چگونه curl یا سرور وب هیچ‌گونه خطا یا هشداری را مبنی بر عدم تطابق گواهینامه‌ها صادر ننمود؟

جهت بررسی عمیق‌تر بیایید دستور ذیل را با ابزار curl صادر نماییم:

$ curl -v -H "Host: www.barandazstorm.com" https://fa.babaei.net
*   Trying 199.48.133.134:443...
* TCP_NODELAY set
* Connected to fa.babaei.net (199.48.133.134) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=babaei.net
*  start date: Nov  6 21:08:06 2019 GMT
*  expire date: Feb  4 21:08:06 2020 GMT
*  subjectAltName: host "fa.babaei.net" matched cert's "fa.babaei.net"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: www.barandazstorm.com
> User-Agent: curl/7.67.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Date: Sun, 15 Dec 2019 16:43:51 GMT
< Content-Type: text/html
< Content-Length: 5401
< Last-Modified: Thu, 12 Sep 2019 17:20:24 GMT
< Connection: keep-alive
< Keep-Alive: timeout=16
< Vary: Accept-Encoding
< ETag: "5d7a7e58-1519"
< Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Accept-Ranges: bytes
< 
<html>
    <head>
        <title>Under Construction...</title>
        <style>
            body {
                background: #EEEEF4;
                color: #999;
                font-size: 18pt;
                font-family: Roboto;
            }
            h1 {
                font-weight: 105;
                font-size: 25pt;
                color: #3ec5fd;
            }
            p {
                font-weight: 700;
            }
            .warning-content {
                position: absolute;
                top: 25%;
                width: 100%;
                height: 300px;
                text-align: center;
                margin: 0;
            }
        </style>
    </head>
    <body>
        <div class="warning-content">
            <h1>Something really cool is coming very soon.</h1>
            <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="100.001px" height="70px" viewBox="0 0 100 68">
                <g id="large">
                    <g>
                        <path d="M55.777,38.473l6.221-1.133c0.017-1.791-0.123-3.573-0.41-5.324l-6.321-0.19c-0.438-2.053-1.135-4.048-2.076-5.931
                            l4.82-4.094c-0.868-1.552-1.874-3.028-3.005-4.417l-5.569,2.999c-1.385-1.54-2.98-2.921-4.771-4.099l2.124-5.954
                            c-0.759-0.452-1.543-0.878-2.357-1.269c-0.811-0.39-1.625-0.732-2.449-1.046l-3.325,5.381c-2.038-0.665-4.113-1.052-6.183-1.174
                            L31.34,6.002c-1.792-0.02-3.571,0.119-5.32,0.406l-0.191,6.32c-2.056,0.439-4.051,1.137-5.936,2.08l-4.097-4.82
                            c-1.546,0.872-3.022,1.875-4.407,3.006l2.996,5.566c-1.54,1.384-2.925,2.985-4.104,4.778c-2.16-0.771-4.196-1.498-5.953-2.127
                            c-0.449,0.765-0.875,1.544-1.265,2.354c-0.39,0.811-0.733,1.63-1.049,2.457c1.587,0.981,3.424,2.119,5.377,3.325
                            c-0.662,2.037-1.049,4.117-1.172,6.186l-6.218,1.136c-0.021,1.789,0.12,3.566,0.407,5.321l6.32,0.188
                            c0.442,2.06,1.143,4.057,2.082,5.937l-4.818,4.095c0.872,1.549,1.873,3.026,3.009,4.412l5.563-2.998
                            c1.392,1.54,2.989,2.92,4.777,4.099l-2.121,5.954c0.756,0.446,1.538,0.871,2.348,1.258c0.813,0.394,1.633,0.739,2.462,1.05
                            l3.326-5.375c2.033,0.662,4.109,1.05,6.175,1.17l1.137,6.221c1.791,0.019,3.569-0.123,5.323-0.407l0.194-6.324
                            c2.053-0.438,4.045-1.136,5.927-2.079l4.093,4.817c1.55-0.865,3.026-1.87,4.414-2.999l-2.995-5.572
                            c1.537-1.385,2.914-2.98,4.093-4.772l5.953,2.127c0.448-0.761,0.878-1.545,1.268-2.356c0.388-0.808,0.729-1.631,1.047-2.458
                            l-5.378-3.324C55.268,42.615,55.655,40.542,55.777,38.473z M42.302,42.435c-3.002,6.243-10.495,8.872-16.737,5.866
                            c-6.244-2.999-8.872-10.493-5.867-16.736c3.002-6.244,10.495-8.873,16.736-5.869C42.676,28.698,45.306,36.19,42.302,42.435z" fill="none" stroke="#3ec5fd"></path>
                        <animateTransform attributeName="transform" begin="0s" dur="3s" type="rotate" from="0 31 37" to="360 31 37" repeatCount="indefinite" <="" animatetransform="">
                        </animateTransform>
                    </g>
                    <g id="small">
                        <path d="M93.068,19.253L99,16.31c-0.371-1.651-0.934-3.257-1.679-4.776l-6.472,1.404c-0.902-1.436-2.051-2.735-3.42-3.819
                            l2.115-6.273c-0.706-0.448-1.443-0.867-2.213-1.238c-0.774-0.371-1.559-0.685-2.351-0.958l-3.584,5.567
                            c-1.701-0.39-3.432-0.479-5.118-0.284L73.335,0c-1.652,0.367-3.256,0.931-4.776,1.672l1.404,6.47
                            c-1.439,0.899-2.744,2.047-3.835,3.419c-2.208-0.746-4.38-1.476-6.273-2.114c-0.451,0.71-0.874,1.448-1.244,2.229
                            c-0.371,0.764-0.68,1.541-0.954,2.329c1.681,1.078,3.612,2.323,5.569,3.579c-0.399,1.711-0.486,3.449-0.291,5.145
                            c-2.086,1.034-4.143,2.055-5.936,2.945c0.368,1.648,0.929,3.25,1.67,4.769c1.954-0.426,4.193-0.912,6.468-1.405
                            c0.906,1.449,2.06,2.758,3.442,3.853l-2.117,6.27c0.708,0.449,1.439,0.865,2.218,1.236c0.767,0.371,1.551,0.685,2.338,0.96
                            c1.081-1.68,2.319-3.612,3.583-5.574c1.714,0.401,3.457,0.484,5.156,0.288L82.695,42c1.651-0.371,3.252-0.931,4.773-1.676
                            c-0.425-1.952-0.912-4.194-1.404-6.473c1.439-0.902,2.744-2.057,3.835-3.436l6.273,2.11c0.444-0.7,0.856-1.43,1.225-2.197
                            c0.372-0.777,0.691-1.569,0.963-2.361l-5.568-3.586C93.181,22.677,93.269,20.939,93.068,19.253z M84.365,24.062
                            c-1.693,3.513-5.908,4.991-9.418,3.302c-3.513-1.689-4.99-5.906-3.301-9.419c1.688-3.513,5.906-4.991,9.417-3.302
                            C84.573,16.331,86.05,20.549,84.365,24.062z" fill="none" stroke="#3ec5fd"></path>
                        <animateTransform attributeName="transform" begin="0s" dur="2s" type="rotate" from="0 78 21" to="-360 78 21" repeatCount="indefinite" <="" animatetransform="">
                        </animateTransform>
                    </g>
                </g>
            </svg>
            <p>
                <b>
                    Sit tight, we'll be back soon!
                </b>
            </p>
        </div>
    </body>
</html>
* Connection #0 to host fa.babaei.net left intact

مشخصا اطلاعات بسیار زیادی در درخواست و پاسخ فوق نهفته است. اما دو خط مهم در نمونه فوق این‌ها می‌باشند:

*  subject: CN=babaei.net
*  subjectAltName: host "fa.babaei.net" matched cert's "fa.babaei.net"

و پس از آن در درخواست HTTP/1.1، محتوای www.barandazstorm.com درخواست می‌شود:

> GET / HTTP/1.1
> Host: www.barandazstorm.com
> User-Agent: curl/7.67.0
> Accept: */*

در واقع با توجه به آزمایش فوق مشاهده می‌شود که در ابتدای برقراری تماس، اولین چیزی که راه‌اندازی و تنظیم می‌شود، اتصال شبکه است؛ اینجاست که TLS وارد می‌شود. بمحض برقراری اتصال TCP، رد و بدل TLS مبتنی بر نام دامنه‌ای که درخواست را شروع نموده، انجام می‌شود (در اینجا fa.babaei.net). هدر هاست (در اینجا با مقدار www.barandazstorm.com) در لایه اپلیکیشن قرار دارد، لذا تا زمانی که همه لایه های پایین‌تر (لایه پروتکل) ایجاد نشود ، هیچ‌کس به آن نگاهی نمی‌اندازد. در مثال فوق ارتباط TLS با استفاده از گواهینامه fa.babaei.net انجام شده و از آنجایی که همه چیز منطبق است هیچ‌گونه هشدار یا خطایی مبنی بر نامعتبر بودن گواهینامه صادر نمی‌شود. در واقع هیچ اشاره‌ای به نام www.barandazstorm.com تا زمان ارسال هدر هاست در درخواست HTTP صورت نخواهد پذیرفت. از آنجایی که در خواست HTTP پس از برقراری ارتباط TLS انجام می‌شود، هرگز این هشدار دریافت نخواهد شد.

meek ابزاری جهت پیاده‌سازی Domain Fronting در Tor

در دیاگرام ذیل نحوه کارکرد meek و توانایی پنهان‌سازی ترافیک شبکه Tor و جلوه دادن آن به عنوان ترافیک معمولی HTTPS با استفاده از تکنیک Domain Fronting را مشاهده می‌نمایید:

پیاده‌سازی Domain Fronting در Tor با استفاده از meek

پیاده‌سازی Domain Fronting در Tor با استفاده از meek

جهت دریافت جزییات بیشتر و آشنایی دقیق‌تر با این پروژه به مستندات رسمی میک در وب‌سایت پروژه تور مراجعه نمایید.

Cloak ابزاری جهت پیاده‌سازی Domain Fronting در OpenVPN, Shadowsocks و Tor

نرم‌افزار cbeuw/Cloak حاصل تحقیقات گسترده و تجربه‌های پیشین حاصل از کار بر روی شدوساکس نظیر ShadowsocksR، shadowsocks/simple-obfs، shadowsocks/v2ray-plugin و cbeuw/GoQuiet در جامعه کدباز می‌باشد.

این نرم‌افزار برخلاف پراکسی‌های سنتی هرگونه ردپا و اثرانگشتی از ارتباط از طریق فیلترشکن‌ها را محو و پنهان می‌سازد. همچنین امکان شناسایی کاربران متصل به فیلترشکن را از طریق تکنیک‌هایی نظیر Deep Packet Inspection برای دولت‌ها و آژانس‌های اطلاعاتی غیرممکن می‌سازد.

در دیاگرام ذیل نحوه کارکرد Cloak و توانایی پنهان‌سازی ترافیک OpenVPN، Shadowsocks، و Tor و جلوه دادن آن به عنوان ترافیک معمولی HTTPS با استفاده از تکنیک Domain Fronting را مشاهده می‌نمایید:

پیاده‌سازی Domain Fronting در OpenVPN, Shadowsocks و Tor با استفاده از Cloak

پیاده‌سازی Domain Fronting در OpenVPN, Shadowsocks و Tor با استفاده از Cloak

به شخصه ترکیب Cloak + Shadowsocks را در شبکه اینترنت ایران تست نموده‌ام و علی‌رغم آنکه باعث کاهش سرعت در مقایسه با ShadowsocksR می‌شود (حدودا تا یک پنجم سرعت ShadowsocksR) اما به خوبی قادر به پنهان‌سازی ترافیک Shadowsocks و عبور از فیلترینگ ایران می‌باشد. Cloak توانایی کار به شکل مستقل یا به عنوان پلاگین نرم‌افزار شدوساکز را دارد.

نحوه تنظیم و راه‌اندازی meek و یا Cloak را آموزش نخواهی داد؟

از آنجایی که این مطلب منحصرا در رابطه با اثبات مفهوم Collateral Freedom و Domain Fronting به رشته تحریر درآمده است، در مطالب آموزشی آتی ممکن است به نحوه تنظیم و راه‌اندازی meek و یا ترکیب Shadowsocks + Cloak بپردازم. تا آن‌زمان جهت آشنایی با Tor به این مطلب و جهت آشنایی با ShadowsocksR و FreeBSD به این مطلب مراجعه نمایید.