معرفی
سیستم‌های فیلتر محتوای شرکتی مدرن از تولیدکنندگان مشهوری مانند Cisco، BlueCoat، FireEye شباهت‌های زیادی با همتایان قدرتمندتر خود - سیستم‌های DPI دارند که به طور فعال در سطح ملی پیاده‌سازی می‌شوند. ماهیت کار هر دو بررسی ترافیک ورودی و خروجی اینترنت و تصمیم گیری برای ممنوعیت اتصال به اینترنت بر اساس لیست های سیاه/سفید است. و از آنجایی که هر دوی آنها در اصول کار خود بر اصول مشابهی تکیه می کنند، روش های دور زدن آنها نیز اشتراکات زیادی خواهد داشت.
یکی از فناوری‌هایی که به شما امکان می‌دهد به طور مؤثری هم سیستم‌های DPI و هم سیستم‌های شرکتی را دور بزنید، فناوری Domain Fronting است. ماهیت آن این است که ما به یک منبع مسدود شده می رویم، در پشت یک دامنه عمومی دیگر با شهرت خوب پنهان می شویم، که بدیهی است که توسط هیچ سیستمی، به عنوان مثال 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 انجام می‌شود و ما هنوز متوجه جایگزینی گواهی‌های https از Beeline نشده‌ایم؟ آیا او روشن بین است یا من تحت تعقیب هستم؟
بیایید سعی کنیم با نگاه کردن به ترافیک از طریق wireshark به این سوال پاسخ دهیم
اسکرین شات نشان می دهد که ابتدا مرورگر آدرس IP سرور را از طریق DNS بدست می آورد، سپس یک دست دادن استاندارد TCP با سرور مقصد رخ می دهد و سپس مرورگر سعی می کند یک اتصال SSL با سرور برقرار کند. برای انجام این کار، یک بسته SSL Client Hello را ارسال می کند که حاوی نام دامنه منبع به صورت متن واضح است. این فیلد توسط سرور frontend cloudflare برای مسیریابی صحیح اتصال مورد نیاز است. اینجاست که DPI ارائه‌دهنده ما را می‌گیرد و ارتباط ما را قطع می‌کند. در عین حال، ما هیچ خرده‌ای از ارائه‌دهنده دریافت نمی‌کنیم و خطای استاندارد مرورگر را می‌بینیم که گویی سایت غیرفعال است یا به سادگی کار نمی‌کند:
حالا بیایید مکانیزم eSNI را در مرورگر فعال کنیم، همانطور که در دستورالعمل ها نوشته شده است :
برای این کار صفحه تنظیمات فایرفاکس را باز می کنیم about: config را و تنظیمات زیر را فعال کنید:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
پس از این کار، بررسی می کنیم که آیا تنظیمات در وب سایت cloudflare به درستی کار می کنند. و بیایید این ترفند را با ردیاب تورنت خود دوباره امتحان کنیم.
Voila. ردیاب مورد علاقه ما بدون هیچ VPN یا سرور پروکسی باز شد. بیایید اکنون به تخلیه ترافیک در wireshark نگاه کنیم تا ببینیم چه اتفاقی افتاده است.
این بار، بسته ssl client hello به طور صریح شامل دامنه مقصد نیست، اما در عوض، یک فیلد جدید در بسته ظاهر شد - encrypted_server_name - اینجاست که مقدار rutracker.nl در آن قرار دارد و فقط سرور frontend cloudflare می تواند این را رمزگشایی کند. رشته. و اگر چنین است، DPI ارائه دهنده چاره ای جز شستن دست ها و اجازه چنین ترافیکی ندارد. هیچ گزینه دیگری با رمزگذاری وجود ندارد.
بنابراین، ما به نحوه عملکرد این فناوری در مرورگر نگاه کردیم. حالا بیایید سعی کنیم آن را در موارد خاص تر و جالب تر اعمال کنیم. و ابتدا به همان curl استفاده از eSNI برای کار با TLS 1.3 را آموزش می‌دهیم و در همان زمان می‌بینیم که چگونه جلوبندی دامنه مبتنی بر eSNI کار می‌کند.
فرانتینگ دامنه با eSNI
با توجه به اینکه curl از کتابخانه استاندارد openssl برای اتصال از طریق پروتکل https استفاده می کند، اول از همه باید پشتیبانی eSNI را در آنجا ارائه دهیم. هنوز هیچ پشتیبانی eSNI در شاخه های اصلی openssl وجود ندارد، بنابراین باید یک شاخه openssl ویژه را دانلود کرده، کامپایل و نصب کنیم.
ما مخزن را از GitHub کلون می کنیم و طبق معمول کامپایل می کنیم:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
در مرحله بعد، مخزن را با curl کلون می کنیم و کامپایل آن را با استفاده از کتابخانه کامپایل شده openssl خود پیکربندی می کنیم:
$ 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 فعال است اما EXPERIMENTAL علامت گذاری شده است. با احتیاط استفاده کنید!
$ makeپس از ساخت موفقیت آمیز بسته، از یک فایل bash ویژه از openssl برای پیکربندی و اجرای curl استفاده می کنیم. برای راحتی کار، بیایید آن را در دایرکتوری با curl کپی کنیم:
cp /opt/openssl/esnistuff/curl-esni و همزمان با ضبط همزمان بسته‌های DNS و TLS در Wireshark، یک درخواست https آزمایشی به سرور cloudflare انجام دهید.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/در پاسخ سرور، علاوه بر اطلاعات دیباگ زیاد از openssl و curl، یک پاسخ HTTP با کد 301 از cloudflare دریافت خواهیم کرد.
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/
که نشان می دهد درخواست ما با موفقیت به سرور مقصد تحویل داده شده، شنیده شده و پردازش شده است.
حالا بیایید به تخلیه ترافیک در wireshark نگاه کنیم، i.e. آنچه DPI ارائه دهنده در این مورد دید.
مشاهده می شود که کرل ابتدا برای یک کلید eSNI عمومی برای سرور cloudflare به سرور DNS روی آورد - یک درخواست TXT DNS به _esni.cloudflare.com (بسته شماره 13). سپس با استفاده از کتابخانه openssl، curl یک درخواست TLS 1.3 را به سرور cloudflare ارسال کرد که در آن فیلد SNI با کلید عمومی به دست آمده در مرحله قبل (بسته شماره 22) رمزگذاری شده بود. اما، علاوه بر فیلد eSNI، بسته SSL-hello یک فیلد با SNI معمولی - open را نیز شامل می‌شود که می‌توانیم آن را به هر ترتیبی مشخص کنیم (در این مورد - ).
این فیلد SNI باز به هیچ وجه هنگام پردازش توسط سرورهای cloudflare در نظر گرفته نشد و فقط به عنوان یک ماسک برای DPI ارائه دهنده عمل می کرد. سرور cloudflare بسته ssl-hello ما را دریافت کرد، eSNI را رمزگشایی کرد، SNI اصلی را از آنجا استخراج کرد و آن را طوری پردازش کرد که گویی هیچ اتفاقی نیفتاده است (هنگام توسعه eSNI همه چیز را دقیقاً طبق برنامه ریزی انجام داد).
تنها چیزی که در این مورد از نقطه نظر DPI قابل تشخیص است، درخواست DNS اولیه به _esni.cloudflare.com است. اما ما درخواست DNS را فقط برای نشان دادن نحوه عملکرد این مکانیسم از داخل باز کردیم.
برای اینکه در نهایت فرش را از زیر DPI بیرون بکشیم، از مکانیسم DNS-over-HTTPS که قبلا ذکر شد استفاده می کنیم. توضیح مختصری - DOH پروتکلی است که به شما امکان می دهد با ارسال یک درخواست DNS از طریق HTTPS در برابر حمله man-in-the-middle محافظت کنید.
بیایید دوباره درخواست را اجرا کنیم، اما این بار کلیدهای عمومی eSNI را از طریق پروتکل https دریافت خواهیم کرد، نه از طریق DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/تخلیه ترافیک درخواست در تصویر زیر نشان داده شده است:
مشاهده می شود که کرل ابتدا از طریق پروتکل DoH (اتصال https به سرور 104.16.249.249) به سرور mozilla.cloudflare-dns.com دسترسی پیدا می کند تا مقادیر کلیدهای عمومی برای رمزگذاری 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
در این مورد، با استفاده از dns.google به سرور مسدود شده rutracker.nl روی آوردیم (اینجا اشتباه تایپی وجود ندارد، اکنون شرکت معروف دامنه سطح اول خود را دارد) و خود را با دامنه دیگری پوشش دادیم که کاملاً این است. مسدود کردن همه DPIها در صورت درد مرگ ممنوع است. بر اساس پاسخ دریافتی، می توانید متوجه شوید که درخواست ما با موفقیت پردازش شد.
به عنوان یک بررسی اضافی که DPI ارائه‌دهنده به SNI باز پاسخ می‌دهد، که ما آن را به عنوان پوشش ارسال می‌کنیم، می‌توانیم به عنوان یک منبع ممنوعه دیگر، به عنوان مثال، یک ردیاب تورنت «خوب» دیگر، از rutracker.nl درخواست کنیم:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/ما پاسخی از سرور دریافت نخواهیم کرد، زیرا ... درخواست ما توسط سیستم DPI مسدود خواهد شد.
نتیجه گیری کوتاه از قسمت اول
بنابراین، ما توانستیم عملکرد eSNI را با استفاده از openssl و curl نشان دهیم و عملکرد دامنه را بر اساس eSNI آزمایش کنیم. به همین ترتیب، می‌توانیم ابزارهای مورد علاقه خود را که از کتابخانه openssl استفاده می‌کنند، برای کار کردن «تحت پوشش» دامنه‌های دیگر تطبیق دهیم. جزئیات بیشتر در مورد این در مقالات بعدی ما.
منبع: www.habr.com