اقتراح لنوع جديد من أنفاق الوكيل HTTP يراعي المضيف
هذا اقتراح لحل “مشكلة الهوية المشتركة” في الاستخدام التقليدي لبروتوكول HTTP عبر I2P، من خلال إدخال نوع جديد من أنفاق وكيل HTTP. يتمتع هذا النوع من الأنفاق بسلوك إضافي يهدف إلى منع أو تقليل فائدة التتبع الذي قد تقوم به مشغلو خدمات مخفية عدائية، ضد وكلاء المستخدم (المتصفحات) وتطبيق عميل I2P نفسه.
ما هي “مشكلة الهوية المشتركة”؟
تحدث “مشكلة الهوية المشتركة” عندما يشترك وكيل مستخدم على شبكة تراكب ذات عنونة تشفيرية في هوية تشفيرية مع وكيل مستخدم آخر. يحدث هذا، على سبيل المثال، عندما يتم تهيئة كل من متصفح Firefox وأداة GNU Wget لاستخدام نفس وكيل HTTP.
في هذا السيناريو، يمكن للخادم جمع وتخزين العنوان التشفيري (الوجهة) المستخدم للرد على النشاط. ويمكنه التعامل مع هذا العنوان كـ"بصمة" تكون دائمًا فريدة بنسبة 100%، لأنها ناتجة عن تشفير. وهذا يعني أن الربطية التي تُلاحظ بسبب مشكلة الهوية المشتركة تكون مثالية.
لكن هل هي مشكلة؟ ^^^^^^^^^^^^^^^^^^^^
تُعد مشكلة الهوية المشتركة مشكلة عندما ترغب وكلاء المستخدم التي تتحدث نفس البروتوكول في عدم إمكانية الربط. تم ذكر هذه المشكلة لأول مرة في سياق HTTP ضمن هذا النقاش على Reddit ، مع توفر التعليقات المحذوفة بفضل pullpush.io . في ذلك الوقت كنتُ أحد أكثر المشاركين نشاطًا، وفي ذلك الوقت اعتقدتُ أن هذه المشكلة صغيرة. خلال السنوات الثماني الماضية، تغيرت الحالة ورأيي حولها، وأصبحت أعتقد أن التهديد الناتج عن الربط الخبيث للوجهات يزداد بشكل كبير كلما أصبحت المزيد من المواقع قادرة على “تكوين ملف تعريفي” لمستخدمين محددين.
تتمتع هذه الهجمة بعائق دخول منخفض جدًا. كل ما يتطلبه الأمر هو أن يشغل مشغل خدمة مخفية خدمات متعددة. بالنسبة للهجمات على الزيارات المعاصرة (زيارة مواقع متعددة في نفس الوقت)، هذا هو الشرط الوحيد. أما بالنسبة للربط غير المعاصر، فيجب أن تكون إحدى هذه الخدمات خدمة تستضيف “حسابات” تخص مستخدمًا واحدًا مستهدفًا للتتبع.
حاليًا، يمكن لأي مشغل خدمة يستضيف حسابات للمستخدمين أن يربطها بالنشاط عبر أي مواقع يتحكم بها، من خلال استغلال مشكلة الهوية المشتركة. يمكن أن تكون منصات مثل Mastodon أو Gitlab أو حتى منتديات بسيطة مهاجمين متنكرين، طالما أنها تشغّل أكثر من خدمة ولديها مصلحة في إنشاء ملف تعريفي لمستخدم. يمكن إجراء هذا المراقبة لأغراض المطاردة أو الكسب المالي أو لأسباب تتعلق بالاستخبارات. حاليًا توجد عشرات المشغلين الكبار الذين يمكنهم تنفيذ هذه الهجمة واستخلاص بيانات ذات معنى منها. نحن نثق بهم في الوقت الراهن بعدم القيام بذلك، لكن من السهل أن تظهر جهات لا تهتم بآرائنا.
هذا مرتبط مباشرةً بشكل أساسي من بناء الملفات التعريفية على الويب العادي، حيث يمكن للمنظمات ربط التفاعلات على موقعها بالتفاعلات على الشبكات التي تتحكم بها. في I2P، وبما أن الوجهة التشفيرية فريدة، يمكن أن تكون هذه التقنية في بعض الأحيان أكثر موثوقية، وإن كان بدون القوة الإضافية للموقع الجغرافي.
مشكلة الهوية المشتركة ليست مفيدة ضد مستخدم يستخدم I2P فقط لإخفاء موقعه الجغرافي. ولا يمكن استخدامها لكسر توجيه I2P. إنها مشكلة تتعلق فقط بإدارة الهوية السياقية.
- من المستحيل استخدام مشكلة الهوية المشتركة لتحديد موقع مستخدم I2P جغرافيًا.
- من المستحيل استخدام مشكلة الهوية المشتركة لربط جلسات I2P إذا لم تكن معاصرة.
ومع ذلك، من الممكن استخدامها لتقليل إخفاء الهوية لمستخدم I2P في ظروف من المحتمل أن تكون شائعة جدًا. إحدى الأسباب التي تجعلها شائعة هي أننا نشجع على استخدام Firefox، وهو متصفح ويب يدعم التشغيل “بالعلامات التبويبية”.
- من الممكن دائمًا إنتاج بصمة من مشكلة الهوية المشتركة في أي متصفح ويب يدعم طلب موارد طرف ثالث.
- لا يؤدي تعطيل جافا سكريبت إلى أي شيء ضد مشكلة الهوية المشتركة.
- إذا أمكن إقامة رابط بين جلسات غير معاصرة، مثلًا باستخدام “بصمة المتصفح التقليدية”، فيمكن تطبيق الهوية المشتركة بشكل انتقالي، مما قد يمكّن من استراتيجية ربط غير معاصرة.
- إذا أمكن إقامة رابط بين نشاط على الإنترنت العادي وهوية I2P، على سبيل المثال، إذا كان الهدف مسجّل الدخول إلى موقع ما باستخدام وجود على I2P وعلى الإنترنت العادي من الجانبين، فيمكن تطبيق الهوية المشتركة بشكل انتقالي، مما قد يؤدي إلى إزالة إخفاء الهوية بالكامل.
كيف تنظر إلى خطورة مشكلة الهوية المشتركة فيما يتعلق بوكيل HTTP في I2P يعتمد على مكان توقعك (أو بشكل أدق، توقع “مستخدم” قد يكون غير مدرك) لوجود “الهوية السياقية” للتطبيق. هناك عدة احتمالات:
- HTTP هو كل من التطبيق والهوية السياقية - وهذا ما يحدث حاليًا. جميع تطبيقات HTTP تشترك في هوية واحدة.
- العملية هي التطبيق والهوية السياقية - وهذا ما يحدث عندما يستخدم تطبيق واجهة برمجة تطبيقات مثل SAMv3 أو I2CP، حيث ينشئ التطبيق هويته ويتحكم في عمرها.
- HTTP هو التطبيق، ولكن المضيف هو الهوية السياقية - وهذا هو هدف هذا الاقتراح، الذي يعامل كل مضيف كـ"تطبيق ويب" محتمل ويتعامل مع سطح التهديد على هذا الأساس.
هل يمكن حلها؟ ^^^^^^^^^^^^^^^
من المحتمل أنه لا يمكن إنشاء وكيل يستجيب بذكاء لكل حالة ممكنة قد يضعف فيها تشغيله إخفاء هوية تطبيق ما. ومع ذلك، من الممكن بناء وكيل يستجيب بذكاء لتطبيق محدد يتصرف بطريقة يمكن التنبؤ بها. على سبيل المثال، في المتصفحات الحديثة، من المتوقع أن يفتح المستخدمون علامات تبويب متعددة، حيث سيتفاعلون مع مواقع ويب متعددة، يتم التمييز بينها من خلال اسم المضيف.
هذا يسمح لنا بتحسين سلوك وكيل HTTP لهذا النوع من وكلاء المستخدم HTTP من خلال جعل سلوك الوكيل يتطابق مع سلوك وكيل المستخدم، من خلال منح كل مضيف وجهته الخاصة عند استخدامه مع وكيل HTTP. يجعل هذا التغيير من المستحيل استخدام مشكلة الهوية المشتركة لاستخلاص بصمة يمكن استخدامها لربط نشاط العميل مع مضيفين، لأن المضيفين لن يشتركا في هوية الرجوع بعد الآن.
الوصف: ^^^^^^^^^^^^
سيتم إنشاء وكيل HTTP جديد وإضافته إلى مدير الخدمات المخفية (I2PTunnel). سيُشغل الوكيل الجديد كـ"مُضاعِف" لوحدات I2PSocketManager. لا يمتلك المضاعِف نفسه وجهة. لكل وحدة I2PSocketManager فردية تصبح جزءًا من التضمين وجهتها المحلية الخاصة وحوض أنفاقها الخاص. يتم إنشاء وحدات I2PSocketManager عند الطلب بواسطة المضاعِف، حيث يكون “الطلب” هو الزيارة الأولى إلى مضيف جديد. من الممكن تحسين إنشاء وحدات I2PSocketManager قبل إدراجها في المضاعِف من خلال إنشاء واحدة أو أكثر مسبقًا وتخزينها خارج المضاعِف. قد يؤدي ذلك إلى تحسين الأداء.
تُنشأ وحدة I2PSocketManager إضافية، مع وجهتها الخاصة، كناقل لـ"Outproxy" لأي موقع لا يمتلك وجهة I2P، على سبيل المثال أي موقع على الإنترنت العادي. هذا يجعل استخدام Outproxy كله هوية سياقية واحدة، مع التحفظ أن تهيئة Outproxies متعددة للنفق سيؤدي إلى تدوير “ثابت” عادي لـoutproxy، حيث يحصل كل outproxy فقط على طلبات لموقع واحد. هذا يشبه تقريبًا السلوك المكافئ لعزل أنفاق HTTP-over-I2P حسب الوجهة، على الإنترنت العادي.
اعتبارات الموارد: ’’’’’’’’’’’’’’’’’’’’’’''
يتطلب وكيل HTTP الجديد موارد إضافية مقارنة بالوكيل الحالي. سيؤدي ذلك إلى:
- بناء عدد أكبر من الأنفاق ووحدات I2PSocketManager
- بناء الأنفاق بشكل أكثر تكرارًا
يتطلب كل من هذه العناصر:
- موارد حوسبة محلية
- موارد شبكة من الأقران
الإعدادات: ’’’’’’’''
من أجل تقليل تأثير زيادة استخدام الموارد، يجب تهيئة الوكيل لاستخدام أقل قدر ممكن. يجب تهيئة الأنفاق التي تكون جزءًا من المضاعِف (وليس الوكيل الأصلي) لـ:
- بناء وحدات I2PSocketManager المضاعَفة لأنفاق دخول واحدة، وأنفاق خروج واحدة في أحواض أنفاقها
- استخدام وحدات I2PSocketManager المضاعَفة 3 قفزات افتراضيًا
- إغلاق المقابس بعد 10 دقائق من عدم النشاط
- تشترك وحدات I2PSocketManager التي يبدأها المضاعِف في عمر المضاعِف. لا يتم “تدمير” الأنفاق المضاعَفة حتى يتم إيقاف المضاعِف الأصلي.
الرسوم التوضيحية: ^^^^^^^^^
الرسم التوضيحي أدناه يمثل التشغيل الحالي لوكيل HTTP، والذي يتوافق مع “الاحتمال 1.” في قسم “هل هي مشكلة؟”. كما ترى، يتفاعل وكيل HTTP مع مواقع I2P مباشرة باستخدام وجهة واحدة فقط. في هذا السيناريو، HTTP هو كل من التطبيق والهوية السياقية.
**الوضع الحالي: HTTP هو التطبيق، HTTP هو الهوية السياقية**
__-> Outproxy <-> i2pgit.org
/
Browser <-> HTTP Proxy(one Destination)<->I2PSocketManager <---> idk.i2p
\__-> translate.idk.i2p
\__-> git.idk.i2p
الرسم التوضيحي أدناه يمثل تشغيل وكيل HTTP يراعي المضيف، والذي يتوافق مع “الاحتمال 3.” في قسم “هل هي مشكلة؟”. في هذا السيناريو، HTTP هو التطبيق، ولكن المضيف يحدد الهوية السياقية، حيث يتفاعل كل موقع I2P مع وكيل HTTP مختلف بوجهة فريدة لكل مضيف. هذا يمنع مشغلي المواقع المتعددة من التمييز بين زيارة نفس الشخص لمواقع متعددة يمتلكونها.
**بعد التغيير: HTTP هو التطبيق، المضيف هو الهوية السياقية**
__-> I2PSocketManager(Destination A - Outproxies Only) <--> i2pgit.org
/
Browser <-> HTTP Proxy Multiplexer(No Destination) <---> I2PSocketManager(Destination B) <--> idk.i2p
\__-> I2PSocketManager(Destination C) <--> translate.idk.i2p
\__-> I2PSocketManager(Destination C) <--> git.idk.i2p
الحالة: ^^^^^^^
توجد تنفيذة عملية بلغة Java لوكيل يراعي المضيف تتوافق مع إصدار أقدم من هذا الاقتراح، متوفرة في نسخة idk الفرعية تحت الفرع: i2p.i2p.2.6.0-browser-proxy-post-keepalive رابط في المراجع. تخضع حاليًا لمراجعة مكثفة، من أجل تقسيم التغييرات إلى أقسام أصغر.
تم كتابة تنفيذات ذات قدرات متفاوتة بلغة Go باستخدام مكتبة SAMv3، وقد تكون مفيدة للدمج في تطبيقات Go أخرى أو لـgo-i2p، لكنها غير مناسبة لـI2P بلغة Java. بالإضافة إلى ذلك، تفتقر هذه التنفيذات إلى دعم جيد للعمل التفاعلي مع LeaseSets المشفرة.
الإضافة: i2psocks
من الممكن تنفيذ نهج بسيط قائم على التطبيق لعزل أنواع أخرى من العملاء دون تنفيذ نوع نفق جديد أو تغيير كود I2P الحالي، من خلال دمج أدوات I2PTunnel الحالية التي توجد بالفعل وتُستخدم على نطاق واسع ومختبرة في مجتمع الخصوصية. ومع ذلك، يتطلب هذا النهج افتراضًا صعبًا لا ينطبق على HTTP ولا على العديد من أنواع عملاء I2P المحتملين الآخرين.
تقريبًا، سيؤدي النص التالي إلى إنتاج وكيل SOCKS5 يراعي التطبيق وتشغيل الأمر الأساسي عبره:
#! /bin/sh
command_to_proxy="$@"
java -jar ~/i2p/lib/i2ptunnel.jar -wait -e 'sockstunnel 7695'
torsocks --port 7695 $command_to_proxy
الإضافة: مثال تنفيذ الهجوم
مثال تنفيذ لهجوم الهوية المشتركة على وكلاء HTTP
موجود منذ عدة سنوات. يوجد مثال إضافي في الدليل الفرعي simple-colluder من مستودع prop166 الخاص بـidk
. تم تصميم هذه الأمثلة بشكل متعمد لإظهار أن الهجوم يعمل، وستتطلب تعديلات (إن كانت طفيفة) لتحويلها إلى هجوم حقيقي.