واجهة المجال على أساس TLS 1.3

مقدمة

تشترك أنظمة ترشيح محتوى الشركات الحديثة من الشركات المصنعة البارزة مثل Cisco و BlueCoat و FireEye في الكثير من القواسم المشتركة مع نظيراتها الأكثر قوة - أنظمة 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 ، ولم نلاحظ استبدال شهادات https من الخط المباشر حتى الآن؟ هل هو عراف أم تتم ملاحقتي؟

دعنا نحاول الإجابة على هذا السؤال من خلال النظر إلى حركة المرور من خلال wireshark

توضح لقطة الشاشة أن المتصفح يحصل أولاً على عنوان IP الخاص بالخادم عبر DNS ، ثم هناك اتصال TCP قياسي مع الخادم الوجهة ، ثم يحاول المستعرض إنشاء اتصال ssl بالخادم. للقيام بذلك ، يرسل حزمة SSL Client Hello التي تحتوي على اسم المجال المصدر بنص واضح. هذا الحقل مطلوب من قبل خادم الواجهة الأمامية cloudflare لتوجيه الاتصال بشكل صحيح. هذا هو المكان الذي يمسك بنا DPI الخاص بالمزود ، مما يؤدي إلى قطع اتصالنا. في الوقت نفسه ، لا نتلقى أي كعب من الموفر ، ونرى خطأ متصفح قياسي كما لو كان الموقع معطلاً أو ببساطة لا يعمل:

لنقم الآن بتمكين آلية eSNI في المتصفح ، كما هو مكتوب في التعليمات الخاصة بـ برنامج فايرفوكس :
للقيام بذلك ، نفتح صفحة تكوين 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 يستخدم مكتبة openssl القياسية للاتصال عبر بروتوكول https ، نحتاج أولاً وقبل كل شيء إلى توفير دعم eSNI هناك. لا يوجد دعم لـ eSNI في الفروع الرئيسية opensl حتى الآن ، لذلك نحن بحاجة إلى تنزيل فرع openssl خاص وتجميعه وتثبيته.

نقوم باستنساخ المستودع من جيثب وتجميعه كالمعتاد:

$ 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

من المهم هنا تحديد جميع الدلائل التي يوجد بها openssl بشكل صحيح (في حالتنا ، هذا هو / opt / openssl /) والتأكد من أن عملية التكوين تسير بدون أخطاء.

في حالة التكوين الناجح ، سنرى السطر:

تحذير: تم تمكين esni ESNI ولكن تم وضع علامة EXPERIMENTAL عليه. استخدم بحذر!

$ make

بعد بناء الحزمة بنجاح ، سنستخدم ملف bash خاصًا من openssl لتكوين curl وتشغيله. انسخه إلى الدليل باستخدام curl للراحة:

cp /opt/openssl/esnistuff/curl-esni 

وتنفيذ طلب اختبار https إلى خادم cloudflare ، وكتابة حزم DNS و TLS في نفس الوقت إلى Wireshark.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

في استجابة الخادم ، بالإضافة إلى الكثير من معلومات التصحيح من opensl و 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 في هذه الحالة.

يمكن ملاحظة أنه في البداية ، تحول curl إلى خادم 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 مفتوحًا فقط لإظهار كيفية عمل هذه الآلية من الداخل.

لإخراج الأرض أخيرًا من إطار DPI ، نستخدم آلية DNS-over-HTTPS التي سبق ذكرها. شرح بسيط - 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/

يظهر طلب تفريغ حركة المرور في لقطة الشاشة أدناه:

يمكن ملاحظة أن curl يصل أولاً إلى خادم mozilla.cloudflare-dns.com باستخدام بروتوكول DoH (اتصال https بالخادم 104.16.249.249) من أجل الحصول على قيم المفتاح العام لتشفير SNI منها ، ثم إلى الخادم الوجهة ، مختبئًا خلف المجال www.hello-rkn.ru.

بالإضافة إلى محلل 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

في هذه الحالة ، لجأنا إلى خادم rutracker.nl المحظور ، باستخدام محلل dns.google DoH (لا يوجد خطأ مطبعي هنا ، والآن تمتلك الشركة الشهيرة نطاق المستوى الأول الخاص بها) وقمنا بتغطية أنفسنا بنطاق آخر ، وهو بدقة يحظر حظره من قبل جميع DPI تحت وطأة الموت. من الرد المستلم ، يمكننا أن نفهم أنه تمت معالجة طلبنا بنجاح.

كتحقق إضافي من أن DPI الخاص بالموفر يستجيب لـ SNI المفتوح الذي نمرره كغطاء ، يمكننا تقديم طلب إلى rutracker.nl خلف بعض الموارد الأخرى المحظورة ، على سبيل المثال ، متتبع تورنت "جيد" آخر:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

لن نتلقى ردًا من الخادم لأن سيتم حظر طلبنا بواسطة نظام DPI.

استنتاج بسيط للجزء الأول

لذلك ، تمكنا من إثبات أداء eSNI باستخدام opensl و curl واختبار تشغيل واجهة المجال المستندة إلى eSNI. وبنفس الطريقة ، يمكننا تكييف أدواتنا المفضلة التي تستخدم مكتبة openssl للعمل "تحت ستار" المجالات الأخرى. المزيد عن هذا في مقالاتنا القادمة.

المصدر: www.habr.com