مقدمة
تتشابه أنظمة تصفية محتوى الشركات الحديثة من الشركات المصنعة البارزة مثل Cisco و BlueCoat و FireEye مع نظرائهم الأكثر قوة - أنظمة DPI التي يتم تنفيذها بشكل مكثف على المستوى الوطني. جوهر عمل كلاهما هو البحث عن حركة المرور الواردة والصادرة عبر الإنترنت ، وعلى أساس القوائم السوداء / البيضاء ، اتخاذ قرار بحظر اتصال الإنترنت. وبما أن كلاهما يعتمد على مبادئ مماثلة في أساسيات عملهما ، فإن طرق التحايل عليهما سيكون لها الكثير من العوامل المشتركة.
واحدة من التقنيات التي تسمح بتجاوز كل من إدارة شؤون الإعلام وأنظمة الشركات بكفاءة عالية هي التكنولوجيا التي تواجه المجال. يكمن جوهرها في حقيقة أننا نذهب إلى مورد محظور ، مختبئين وراء مجال عام آخر ، يتمتع بسمعة طيبة ، ومن الواضح أنه لن يتم حظره بواسطة أي نظام ، على سبيل المثال google.com.
لقد تم بالفعل كتابة الكثير من المقالات حول هذه التكنولوجيا وتم تقديم أمثلة كثيرة عليها. ومع ذلك ، توفر تقنية DNS over-HTTPS وتقنيات SNI المشفرة ، بالإضافة إلى التقنيات التي تمت مناقشتها مؤخرًا ، بالإضافة إلى الإصدار الجديد من بروتوكول TLS 1.3 ، فرصة للنظر في متغير آخر من واجهة المجال.
نحن نتعامل مع التكنولوجيا
أولاً ، لنقرر قليلاً حول المفاهيم الأساسية ، بحيث يكون لدى كل شخص فهم من هو ولماذا كل هذا مطلوب. ذكرنا آلية eSNI ، التي سيتم مناقشتها في وقت لاحق. آلية eSNI (اسم خادم مشفر) هي نسخة آمنة من SNI ، وهي متاحة فقط لبروتوكول TLS 1.3. النقطة الرئيسية هي تشفير ، بما في ذلك معلومات حول المجال الذي يتم إرسال الطلب إليه.
الآن دعونا نلقي نظرة على كيفية عمل آلية eSNI في الممارسة العملية.
لنفترض أن لدينا مورد إنترنت تم حظره بواسطة حل DPI حديث (خذ على سبيل المثال ، تعقب سيل الشهير - rutracker.nl). عندما نحاول الوصول إلى موقع تعقب السيل ، نرى كعب الروتين القياسي للموفر الذي تم حظر المورد:
على موقع ILV ، يتم سرد هذا المجال بالفعل في قوائم التوقف:
عندما تستفسر عن whois ، يمكنك أن ترى أن المجال نفسه "مخفي" خلف الموفر السحابي Cloudflare.
ولكن على عكس "المتخصصين" من ILV ، فإن الموظفين الخطرين الأكثر تقنيًا (أو الذين تم تعليمهم من خلال التجربة المريرة لمنظمنا المشهور) لم يحظروا الموقع بغباء عنوان IP ، لكنهم أدخلوا اسم النطاق في قائمة التوقف. يسهل عليك التحقق مما إذا كنت تنظر إلى المجالات الأخرى التي تختبئ خلف عنوان IP نفسه ، وتفضل بزيارة أحدها وشاهد أن الوصول غير محظور:
ولكن كيف يحدث ذلك؟ كيف يكتشف موفر DPI أي من المجالات التي ينتقل إليها المستعرض الخاص بي ، لأن جميع الاتصالات تتم عبر بروتوكول https ، ولا يبدو أننا لاحظنا استبدال شهادات https من الخط المباشر حتى الآن؟ هل هو مستبصر أم أنه يتبعني؟
دعونا نحاول الإجابة على هذا السؤال من خلال النظر في حركة المرور من خلال wireshark
توضح لقطة الشاشة أن المستعرض أولاً يتلقى عنوان IP للخادم عبر DNS ، ثم هناك مصافحة TCP قياسية مع الخادم الوجهة ، ثم يحاول المستعرض تأسيس اتصال ssl بالخادم. للقيام بذلك ، يرسل الحزمة مرحبا عميل SSL ، الذي يحتوي على اسم المجال المصدر في نص واضح. هذا الحقل مطلوب بواسطة خادم الواجهة السحابية cloudflare من أجل توجيه الاتصال بشكل صحيح. هذا هو المكان الذي يمسكنا به DPI ، يقطع اتصالنا. في الوقت نفسه ، لا نتلقى أي روتين من الموفر ، ونرى خطأ مستعرضًا قياسيًا كما لو كان الموقع معطلاً أو ببساطة لا يعمل:
الآن ، لنقم بتمكين آلية eSNI في المتصفح ، كما هو موضح في تعليمات
Firefox :
للقيام بذلك ، نفتح صفحة تكوين Firefox
حول: تهيئة وتنشيط الإعدادات التالية:
network.trr.mode = 2; network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query network.security.esni.enabled = true
بعد ذلك ، سوف نتحقق من صحة الإعدادات على موقع cloudflare الإلكتروني باستخدام
الرابط ونحاول التركيز من خلال تعقب السيل لدينا مرة أخرى.
فويلا. تم فتح برنامج التتبع المفضل لدينا بدون أي شبكات VPN أو وكلاء. دعونا الآن نلقي نظرة على تفريغ حركة المرور في wireshark ، ماذا حدث.
هذه المرة ، لا تحتوي حزمة hello client ssl على المجال الوجهة بشكل صريح ، ولكن بدلاً من ذلك ، ظهر حقل جديد في الحزمة - encrypted_server_name - حيث يتم احتواء قيمة rutracker.nl ، ولا يستطيع خادم cloudflare للجهة الأمامية فك تشفير هذا الحقل. وإذا كان الأمر كذلك ، فليس لدى موفر DPI أي خيار سوى غسل أيديهم والسماح بمثل هذه الحركة. ولكن لا توجد خيارات أخرى مع التشفير.
لذلك ، كيف تعمل التكنولوجيا في المتصفح - نظرنا. الآن دعونا نحاول تطبيقه على أشياء أكثر تحديدًا وإثارة للاهتمام. وبالنسبة للمبتدئين ، سوف نعلم نفس الضفيرة لاستخدام eSNI للعمل مع TLS 1.3 ، وفي نفس الوقت سنرى كيف يعمل مجال الواجهة الأمامية المستند إلى eSNI نفسه.
واجهة المجال الأمامية مع eSNI
نظرًا لحقيقة أن curl يستخدم مكتبة opensl القياسية للاتصال عبر https ، أولاً وقبل كل شيء ، نحن بحاجة إلى توفير دعم eSNI هناك. لا يوجد أي دعم لـ eSNI في فروع opensl الرئيسية حتى الآن ، لذلك نحن بحاجة إلى تنزيل فرع opensl الخاص ، وتجميعه وتثبيته.
نحن استنساخ مستودع من جيثب وتجميع كالمعتاد:
$ git clone https://github.com/sftcd/openssl $ cd openssl $ ./config $ make $ cd esnistuff $ make
بعد ذلك ، نقوم باستنساخ المستودع باستخدام curl وتكوين تجميعه باستخدام مكتبة opensl المجمعة لدينا:
$ 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
من المهم الإشارة بشكل صحيح إلى جميع الأدلة التي يوجد فيها opensl (في حالتنا ، يكون / opt / openssl /) والتأكد من أن عملية التكوين تمر دون أخطاء.
في حالة التكوين الناجح ، سنرى السطر:
تحذير: تم تمكين esni ESNI ولكن تم وضع علامة تجريبية عليه. استخدم بحذر! $ make
بعد بناء الحزمة بنجاح ، سوف نستخدم ملف bash openssl الخاص لتكوين وتشغيل الضفيرة. انسخها إلى الدليل مع حليقة للراحة:
cp /opt/openssl/esnistuff/curl-esni
وتنفيذ طلب https للاختبار على خادم cloudflare ، أثناء كتابة حزم DNS و TLS في وقت واحد إلى Wireshark.
$ 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 ، أي ما رأى DPI مزود في هذه الحالة.
يمكن ملاحظة أن أول حليقة تحولت إلى خادم DNS للحصول على مفتاح eSNI عام لخادم cloudflare - طلب TXT DNS إلى _esni.cloudflare.com (الحزمة رقم 13). ثم ، باستخدام مكتبة openssl ، أرسل curl طلب TLS 1.3 إلى خادم cloudflare حيث تم تشفير حقل SNI بالمفتاح العمومي الذي تم الحصول عليه في الخطوة السابقة (الحزمة رقم 22).
ولكن ، بالإضافة إلى حقل eSNI ، كجزء من حزمة SSL-hello ، تم أيضًا إدخال حقل مع SNI مفتوح - المعتاد ، والذي يمكننا تحديده بأي ترتيب (في هذه الحالة - www.hello-rkn.ru ).لم يتم أخذ هذا الحقل من SNI المفتوح في الاعتبار عند المعالجة بواسطة خوادم cloudflare وكان مجرد تمويه لموفر DPI. تلقى خادم cloudflare حزمة ssl-hello الخاصة بنا وفك تشفير eSNI واستخرج SNI الأصلي من هناك وعالجها كما لو لم يحدث شيء (لقد فعل كل شيء كما هو مخطط له أثناء تطوير eSNI).
الشيء الوحيد في هذه الحالة ، يمكنك التشبث من حيث DPI - استعلام DNS الأساسي في _esni.cloudflare.com. لكننا جعلنا استعلام DNS مفتوحًا فقط لإظهار كيف تعمل هذه الآلية من الداخل.
للتخلص أخيرًا من التربة من تحت إدارة شؤون الإعلام ، نستخدم آلية HTTPS لنظام DNS المذكورة أعلاه. شرح صغير - DOH - بروتوكول يسمح لك بحماية نفسك من رجل في منتصف الهجوم عن طريق إرسال استعلام DNS عبر HTTPS.
سننفذ الطلب مرة أخرى ، لكن هذه المرة سنحصل على مفاتيح eSNI العامة باستخدام بروتوكول https ، وليس DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/
يتم عرض تفريغ حركة المرور في لقطة الشاشة أدناه:
يتبين أن التجعيد الأول يصل إلى خادم mozilla.cloudflare-dns.com باستخدام بروتوكول DoH (اتصال https إلى الخادم 104.16.249.249) للحصول على قيم المفتاح العام لتشفير SNI منها ، ثم إلى الخادم الوجهة ، للاختباء تحت المجال
www.hello-rkn.ru .
بالإضافة إلى mozilla.cloudflare-dns.com محلل DoH المحدد أعلاه ، يمكننا استخدام خدمات 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
في هذه الحالة ، لجأنا إلى rutracker.nl للخادم المحظور ، باستخدام dns.google DoH solutionver (لا يوجد خطأ مطبعي ، والآن لدى الشركة الشهيرة نطاق المستوى الأول الخاص بها) وقمنا بتغطية أنفسنا بمجال آخر ، وهو أمر محظور تمامًا من قبل إدارة شؤون الإعلام منعه في خوف من عقوبة الإعدام. وفقًا للإجابة ، يمكنك فهم أن طلبنا قد تمت معالجته بنجاح.
وكتحقق إضافي من استجابة الموفر DPI إلى SNI مفتوح ، والذي نمرره كغطاء - يمكننا تنفيذ طلب إلى rutracker.nl وراء بعض المصادر الممنوعة الأخرى ، على سبيل المثال ، تعقب سيل "جيد" آخر:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/
لن نتلقى ردًا من الخادم ، مثل سيتم حظر طلبنا من قبل نظام DPI.
خاتمة صغيرة للجزء الأول
لذلك ، تمكنا من إظهار صحة eSNI باستخدام openssl وحليقة واختبار تشغيل الواجهة الأمامية المستندة إلى المجال على أساس eSNI. بنفس الطريقة ، يمكننا تكييف أدواتنا المفضلة باستخدام مكتبة openssl للعمل "تحت غطاء" المجالات الأخرى. المزيد عن هذا في مقالاتنا القادمة.